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/09/02. 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.
[Bug #20693] Dir.tmpdir should perform a real access check before warning about writability
A minor paper-cut, but I ran into this while running Ruby's tests in an unprivileged Docker container
File::Stat#writable? is really just guessing; to really know if a directory is writable, you need to ask the OS (through a call to File.writable?)
There's a broader question about whether we should deprecate File::Stat#writable? and File::Stat#readable? altogether, since they can't possibly be correct in 100% of cases. But I'm happy just to fix this one case in Dir.tmpdir for now.
[Feature #20707] Move Time#xmlschema (AKA iso8601) into core (byroot)
Usability wise, this is such a common format that I'd expect to have it without needing to require anything.
On a more general point, require 'time' is always a bit surprising because Time is a core Class. So the case could be made for other methods perhaps?
Bringing it in core would allow to write it without relying on strftime, and a quick prototype I did shows it can be 5x faster.
Given Ruby is used a lot for JSON APIs, and often contains Time fields (e.g. updated_at), this happen to a non-negligeable hotspot in many Ruby deployments.