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 2024/06/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: The next dev meeting in May will be held in person, co-located with RubyKaigi 2024 in Okinawa, Japan. @ko1 (Koichi Sasada) will create the ticket for that separately.
[Bug #20513] the feature of kwargs in index assignment has been removed without due consideration of utility, compatibility, consistency and logic (bughit)
it doesn't make sense to remove a feature because there are fixable edge-case bugs in its implementation
it doesn't make sense from a higher level language design perspective to allow kwargs in index but not in index assignment
instead of removal, index assignment should get proper/real kwargs and the multiple assignment problem should be fixed
[Misc #20407] Question about applying encoding modifier to an interpolated Regexp (andrykonchin)
The documentation states that a Regexp with only US-ASCII characters has US-ASCII encoding, otherwise a regular expression is assumed to use the source encoding. This can be overridden with encoding modifiers.
It isn't clear enough how a Regexp encoding (that Regexp#encoding method returns) is calculated in case an encoding modifier (e.g. u, e, etc) is specified for a Regexp with interpolation (e.g. /a #{ "b".encode("windows-1251") } c/e).
The encoding modifier is applied in some cases and isn't in other ones what seems confusing at first glance.
It seems result depends on a source encoding, characters of the Regexp literal fragments and encoding of Regexp interpolated fragments as well.
IO#read and similar methods when called with buffer argument preserve its encoding.
But IO#read doesn't do so in case the maxlen argument is nil.
[Bug #20319] Singleton class is being frozen lazily in some cases (andrykonchin)
When an object becomes frozen (with #freeze method call) only its own singleton class becomes frozen immediately.
Classes in the singleton classes chain become frozen only when they are returned to user with #singleton_class method call.
The object's singleton class' singleton class (and so on) doesn't become frozen even if it was already instantiated
This lazy freezing can be observed by a user when he gets a singleton class of the object's singleton class before freezing the object. After freezing the object the instantiated singleton class is still not frozen.
There might be several options (1) don't change anything, 2) freeze all the instantiated singleton classes in a chain immediately or 3) don't freeze singleton classes in a chain at all and stop freezing even an object's singleton class) and there is a PR with fix (https://github.com/ruby/ruby/pull/10245) but it's unclear what option is the best one.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by