Project

General

Profile

Actions

Misc #19357

closed

DevMeeting-2023-02-09

Added by mame (Yusuke Endoh) about 1 year ago. Updated about 1 year ago.

Status:
Closed
Assignee:
-
[ruby-core:111926]

Description

The next dev meeting

Date: 2023/02/09 13:00-17:00 (JST)
Log: https://github.com/ruby/dev-meeting-log/blob/master/2023/DevMeeting-2023-02-09.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 2023/02/06. 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.

Related issues 1 (1 open0 closed)

Related to Ruby master - Misc #14770: [META] DevelopersMeetingOpenActions
Actions #1

Updated by mame (Yusuke Endoh) about 1 year ago

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

Updated by hsbt (Hiroshi SHIBATA) about 1 year ago

  • [Feature #19351] Promote bundled gems at Ruby 3.3
    • How about the list of first proposal?
    • Do you have opinion for "Additional Works"?

Updated by zverok (Victor Shepelev) about 1 year ago

Sorry for a long list, I'll try to give the informative description to each

  • [Feature #18368] Range#step semantics for non-Numeric ranges (zverok)
    • It seems that nobody is in principle against it, Matz's doubts are addressed with detailed explanations.
  • [Feature #19061] Proposal: make a concept of "consuming enumerator" explicit (zverok)
    • Questions are addressed, is it possible to move forward with it?
  • [Feature #19272] Hash#merge: smarter protocol depending on passed block arity (zverok)
    • A novel proposal to use block arity analysis for more friendly API, allowing hash1.merge(hash2, &:+) without losing backward compatibility
  • [Misc #19304] Kernel vs Object documentation (zverok)
    • The question is probably only documentation-related, but I believe it is important to the general understanding of Ruby and would like to hear the core team consensus
  • [Feature #19324] Enumerator.product => Enumerable#product (zverok)
    • For consistency with other methods "promoted" from Array
    • The question of necessity of "standalone" method concept was raised, too

Updated by jeremyevans0 (Jeremy Evans) about 1 year ago

  • [Bug #11230] Should rb_struct_s_members() be public API? (jeremyevans0)
    • This C function was previous decided to be removed from the public API after Ruby 3.2.
    • The function is still exported as it is needed by marshal.c.
    • One stated reason for removal is that rb_struct_s_members returns a hidden Array. rb_struct_members appears to return the same Array.
    • Should we consider removing rb_struct_members from the public API as well?
  • [Feature #19347] Add Dir.fchdir (jeremyevans0)
    • This was discussed last developer meeting, with 4 possible approaches.
    • I've given comments for each approach. Can we decide on an approach?
  • [Feature #19388] Deprecate SecurityError (jeremyevans0)
    • SecurityError was used historically for $SAFE violations. It hasn't been used since Ruby 3.0.
    • I think we should deprecate SecurityError in Ruby 3.3 and remove it Ruby 3.4. Is this OK?

Updated by k0kubun (Takashi Kokubun) about 1 year ago

  • [Feature #19420] Simplify MJIT implementation (k0kubun)
    • Is it okay to move forward with that idea? I'd like to get early feedback before going too far with it.

Updated by sawa (Tsuyoshi Sawada) about 1 year ago

  • [Feature #10343] Postfix notations for when and else inside case statement (sawa)
    • Allow foo when condition within case-statements.
    • Has not received feedback for eight years.
Actions #7

Updated by mame (Yusuke Endoh) about 1 year ago

  • Description updated (diff)
Actions #8

Updated by mame (Yusuke Endoh) about 1 year ago

  • Status changed from Open to Closed
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0