Misc #21777: DevMeeting-2026-01-14

• Status: Closed
• Assignee: -

[mame (Yusuke Endoh)]

The next dev meeting

Date: 2026/01/14 13:00-17:00 (JST)
Log: https://github.com/ruby/dev-meeting-log/blob/master/2026/DevMeeting-2026-01-14.md

• 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.
• DO NOT discuss then on this ticket, please.

Call for agenda items

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/01/11. We hold a preparatory meeting to create an agenda a few days before the dev-meeting.
• The format is strict. We'll use this script to automatically create an markdown-style agenda. We may ignore a comment that does not follow the format.
• 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.

[mame (Yusuke Endoh)]

• Related to Misc #14770: [META] DevelopersMeeting added

[zverok (Victor Shepelev)]

• [Bug #21780] Change the default size of Enumerator.produce back to infinity (zverok)
  • While the new argument is a good addition to the API, I argue that Float::INFINITY would be a more friendly default, corresponding to the most straightforward usage

[shioimm (Misaki Shioi)]

• [Bug #21803] Addrinfo#connect_internal should raise IO::TimeoutError on user-specified timeouts
  • I’d like to make Socket.tcp consistently raise IO::TimeoutError when a user-specified timeout occurs, rather than raising Errno::ETIMEDOUT in some cases.

[Eregon (Benoit Daloze)]

• [Feature #8948] Frozen regex (eregon)
  • Can we merge it now for 4.1? Then there is plenty of time for the few gems that rely on mutable Regexp to adapt.
  • We can also revert it if it turns out to be too disrupting.

[byroot (Jean Boussier)]

• [Feature #21800] Dir.foreach and Dir.each_child to optionally yield File::Stat object alongside the children name (byroot)
  • It's common for development tools to need to recursively scan the file system, but it's slower than it should be in Ruby because the API impose N+1 stat syscalls.
  • By providing File::Stat alongside the entry name we can leverage readdir's d_type and avoid a stat(2) call in most cases.
  • This would benefit many popular gems such as Zeitwerk, rubocop, etc.
• [Feature #21788] Promote Thread::Monitor to a core class (byroot)
  • Monitor is about as useful as Mutex and yet one is a core class and the other is a "stdlib" extension.
  • Bringing it into core allow to make is about as fast as mutex, while it is currently ~20% slower.
  • I don't personally think MonitorMixin should be made core though. It can remain in monitor.rb.
• [Feature #21821] Add Stack and SizedStack classes. (byroot)
  • Identical to Queue and SizedQueue but LIFO ordering.
  • Should they be namespaced under Thread:: like Queue or is it just historical?

[jeremyevans0 (Jeremy Evans)]

• [Feature #21264] Extract Date library from Ruby repo in the future (jeremyevans0)
  • Do we want to extract date to bundled gems?
  • I'm fine keeping it as stdlib, and if it needs a maintainer, I volunteer to maintain it.
  • If we want to move Date to bundled gems, I think we should move a subset of Date to core.
    • A brief outline of my idea for this: https://bugs.ruby-lang.org/issues/21264#note-10

[mame (Yusuke Endoh)]

• [Feature #6012] Proc#source_location also return the column (mame)
  • Quite a few gems are using the idiom source_location.last.
  • The idiom will return a column number (of the end of the code range) instead of a line number.
  • This incompacibility actually affected rspec and pry (though they are already fixed).
  • Is this incompatibility really ok? I feel it is disproportionately incompatible for unclear use cases.

[mame (Yusuke Endoh)]

• [Feature #13683] Add strict Enumerable#single (mame)
  • ActiveSupport now has Enumerable#sole. https://github.com/rails/rails/pull/40914
  • I want this on the core too. It's good that the intention of having only one is explicitly stated in the code.

[Eregon (Benoit Daloze)]

• [Feature #21795] Methods for retrieving ASTs (eregon)
  • This seems very useful and convenient, and abstract over implementation details like node_id (which I think make little sense to expose to users).
  • To address @mame's concern about not working for eval code, how about keeping eval code in memory by default?
  • TruffleRuby would implement this using source byte offset+length and not node_id. I can even prototype an implementation if useful.

[Eregon (Benoit Daloze)]

• [Feature #21826] Deprecating RubyVM::AbstractSyntaxTree (eregon)
  • OK to deprecate now/for 4.1? If not, when?
  • And maybe remove it in 4.2?
• [Feature #21827] Deprecating Ripper (eregon)
  • Removing Ripper would remove a significant maintenance overhead, for all Ruby implementations.
  • It is however an established/public API, even though Ripper.sexp is still marked experimental and it hasn't been very stable.
  • So how about deprecating it in 4.1?

[Eregon (Benoit Daloze)]

I plan to attend this meeting, though I will only be able to join from 15:30PM JST (= 7:30AM CET).
Would it possible to discuss the topics I added, as well as #6012 (https://bugs.ruby-lang.org/issues/21777#note-7) after that time so I can participate in their discussion?
Maybe by simply putting these topics at the end of the list of topics when creating the agenda.

[Eregon (Benoit Daloze)]

• [Misc #21804] Getting setup-ruby Earlier (eregon)
  • To get it out earlier, we need release managers (@hsbt (Hiroshi SHIBATA) @nagachika (Tomoyuki Chikanaga) @k0kubun (Takashi Kokubun)) to also run the relevant steps for setup-ruby: https://github.com/ruby/setup-ruby/pull/848#issuecomment-3728626978
  • Are they OK to do that? If not it will decrease security (or delay adoption of new releases in CI).
  • For JRuby and for RubyInstaller, Charles Nutter and Lars Kanis are already OK with it. So it's just missing CRuby release managers now.

[mame (Yusuke Endoh)]

• Description updated (diff)
• Status changed from Open to Closed