Dev meeting IS NOT a decision-making place. All decisions should be done at the bug tracker.
Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly.
Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue).
We will write a record of the discussion in the file or to each ticket in English.
All activities are best-effort (keep in mind that most of us are volunteer developers).
The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time.
If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format:
* [Ticket ref] Ticket title (your name)
* Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.)
Example:
* [Feature #14609] `Kernel#p` without args shows the receiver (ko1)
* I feel this feature is very useful and some people say :+1: so let discuss this feature.
It is recommended to add a comment by 2026/05/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting.
Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion.
Note: This is the ticket for the meeting scheduled after the dev meeting co-located with RubyKaigi (2026-04-21). Until then, please list agenda items on https://bugs.ruby-lang.org/issues/21916.
[Feature #21981] Remove CREF rewriting for methods on cloned classes/modules
Current behaviour is inconsistent with all other constant references being lexically scoped (inheritance, mixins, define_method). Only Class#{dup,clone} has weird dynamic behaviour.
I think it's rarely used, however it's a breaking change.
[Bug #22058] {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope (jeremyevans0)
I found semantic issues with #super_method for refined methods.
For the current class, it uses refinements activated at the time the Method/InstanceMethod was created.
For ancestors, it uses refinements activated in the scope calling #super_method.
Can we define the expected semantics for #super_method for refined methods?
shugo: The current behaviour of super seems to have a bug; if it's fixed, super_method need not to search refinements.
[Feature #22056] Add zero-copy String constructor backed by an arbitrary Ruby object
Propose adding rb_enc_str_new_external (and variants, names tentative): creates a String referencing existing memory without copying, with the GC keeping an arbitrary parent object alive
To fully satisfy the use case described in #22056, this proposal alone is insufficient. Two additional concerns raised in that ticket also need to be addressed:
RSTRING_PTR null-termination invariant (https://bugs.ruby-lang.org/issues/22056#note-12): The new API risks violating the existing guarantee that RSTRING_PTR() always returns a null-terminated string, which existing C extensions silently rely on.
Should these two concerns be resolved before evaluating the merits of this proposal, or is it acceptable to discuss all three in parallel?
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by