Please comment your favorite ticket numbers you want to ask to discuss with your SHORT comment or summary.
(your summary/comment will help us because we don't need to read all of ticket comments)
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 log about discussion to a 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 is scheduled according to when/where we can reserve Matz's time.
Please comment your favorite ticket we need to discuss with the following format.
* [Ticket ref] Ticket title (your name)
* your comment why you want to put this ticket here if you want to add.
Your comment is very important if you are no attendee because we can not ask why you want to discuss about it.
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 about this feature.
We don't guarantee to put tickets in agenda if the comment violate the format (because it is hard to copy&paste).
[Feature #14736] Thread selector for flexible cooperative fiber based concurrency
Is it something we want to move forward with?
Extend hooks for wait_one_pid and Kernel::sleep. Are there other areas to hook into?
Add some default implementation using IO.select, e.g. IO::Selector, similar to test spec. Should IO.select accept raw file descriptors?
Should IO be non-block by default? Should we adjust behaviour dynamically based on context? How to handle File.read which doesn't give opportunity to assign to nonblock.
[Feature #15778] Expose an API to pry-open the stack frames in Ruby
Several points were made in favor of Ruby API. Can we make it so this API is clearly marked as "should only be used for debugging"? Are there other concerns?
What can we do about this? The current situation is confusing for everyone, the API sounds "blessed" by being in core but it's actually experimental and unstable.
Can we document it as clearly as possible when this API should be used?
Could we improve the API so it's less fragile to parser changes and could be reasonably implemented on other Ruby implementations?