Project

General

Profile

Actions

Misc #18975

closed

Propose Stan Lo (@st0012) as an IRB maintainer

Added by k0kubun (Takashi Kokubun) over 1 year ago. Updated over 1 year ago.

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

Description

Background

Looking at @aycabta (aycabta .) 's GitHub activity, he's been inactive on the Internet for 6~7 months, which means that IRB hasn't had the maintainer during that period of time. While I managed to sneak in some IRB changes when he was active, I personally have some more IRB changes that I want to make, but I'm not sure if we're gonna make it to Ruby 3.2 since we can't predict when he'll be back and there's nobody taking the ownership of the IRB design now.

However, I don't think the 2nd most active contributor (@nobu (Nobuyoshi Nakada)) is particularly interested in IRB, and the 3rd most active contributor (myself) currently doesn't have capacity to maintain anything new. So having a temporary maintainer from existing committers could also be hard.

Proposal

I propose to make Stan Lo (@st0012 (Stan Lo)) a new committer and a co-maintainer of IRB.

He's best known for being almost as active as @ko1 (Koichi Sasada) in recent debug.gem development and I think he deserves maintainership in the Ruby's debug tooling area in general. While he has fewer contributions to IRB, some modules of IRB (which I authored, so I should have a say) are used by debug.gem, so I believe IRB being maintained by him will also be useful for the success of debug.gem and Ruby 3 tooling.

Actions #1

Updated by k0kubun (Takashi Kokubun) over 1 year ago

  • Description updated (diff)
Actions #2

Updated by k0kubun (Takashi Kokubun) over 1 year ago

  • Description updated (diff)

Updated by st0012 (Stan Lo) over 1 year ago

It'll be my honor to help the team maintain IRB. Thank you for nominating me for this important role.

Actions #4

Updated by k0kubun (Takashi Kokubun) over 1 year ago

  • Description updated (diff)

Updated by k0kubun (Takashi Kokubun) over 1 year ago

  • Status changed from Open to Feedback

We discussed this at today's developers meeting. We recognize two different challenges here.

  1. @st0012 (Stan Lo) and @k0kubun (Takashi Kokubun) want to introduce IRB features that are relatively easy to maintain, such as adding or modifying IRB commands.
  2. We have no active IRB maintainer who is responsible for making technical decisions and maintaining IRB and Reline for a long term.

My primary interest in this ticket was to address (1), hopefully solving (2) as well. However, given the highly complicated nature of IRB around Reline, having a co-maintainer of IRB in the absence of the current maintainer could result in design decisions that conflict with @aycabta (aycabta .) 's vision, which might make the long-term maintenance hard. So we discussed an idea to address only (1) for now, waiting for @aycabta (aycabta .) about (2) in the meantime.

@naruse (Yui NARUSE) raised the following idea of partial maintainership and @matz (Yukihiro Matsumoto) approved it. (I got asked to post this summary myself first, which he may leave a confirmation comment on later.)

We'll revisit other discussions later, hopefully after @aycabta (aycabta .) is back.

Updated by matz (Yukihiro Matsumoto) over 1 year ago

Confirmed. Thank you for helping us @k0kubun (Takashi Kokubun) and @st0012 (Stan Lo).
If you have any concern, please tell us here.

Matz.

Updated by k0kubun (Takashi Kokubun) over 1 year ago

  • Status changed from Feedback to Closed

We discussed this again in the DevMeeting-2022-12-15. We agreed to make the following changes after the Ruby 3.2 release. Now that Ruby 3.2 is released, I'm publishing this update and making permission changes on the IRB repository.

Ruby 3.2

This year, Reline and IRB have been maintained as follows:

Ruby 3.3

We agreed to make the following changes from the Ruby 3.3 development.

Looking forward to making IRB and Reline better with you all :)

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0