Ruby

In this case the update is automated and ready to be merged by the repo maintainer: https://github.com/ruby/setup-ruby/pull/844

If I may, the issue to me seems more to be like many Ruby owned projects, it's mostly a one person show, so if the maintainer is away for a bit, then we can't do anything other than wait.

So I think there a more general issue of moving away from "single maintainer" repos, as it's not healthy.

https://github.com/ruby/setup-ruby/pull/844 got merged the same day, what would you expect?

Concretely I currently merge setup-ruby PRs and I have told @hsbt (Hiroshi SHIBATA) in the past he can merge (+ release) for new added versions.
More people could be allowed, like release managers.

So I think this is something to add to the post-release checklist:

• Merge the ruby-build PR (e.g. https://github.com/rbenv/ruby-build/pull/2592)
• Run this workflow: https://github.com/ruby/ruby-builder/actions/workflows/check-new-releases.yml
• Wait for the automated setup-ruby PR, CI and merge it
• When RubyInstaller2 has a new release, run https://github.com/ruby/ruby-builder/actions/workflows/check-new-windows-versions.yml
• Wait for the automated setup-ruby PR, CI and merge it

Maybe it'd make sense and possibly safe enough to automatically merge PRs by ruby-builder-bot, after they pass CI of course.
I'm not sure how feasible that is (e.g. is there a GHA event triggered when CI has passed?), but if someone is interested, please make a PR to setup-ruby.

https://github.com/ruby/setup-ruby/pull/844 got merged the same day, what would you expect?

A counter-example, though, is that the PR for windows support (https://github.com/ruby/setup-ruby/pull/847) took 3 days to get merged.

I think @koic's original point is valid -- setup-ruby is an important foundational project depended upon by many (all?) downstream Ruby projects. A delay in releasing support in setup-ruby for new Rubies will cascade and multiply delays down the dependency chain in ways that are painful for other maintainers and users.

In my case, because the Windows PR had not been merged, I was blocked from shipping Ruby-4-compatible native gems for sqlite3 and nokogiri. I eventually managed to ship these gems in a timely manner by forking setup-ruby and doing the work myself (see https://github.com/ruby/setup-ruby/pull/846). It wasn't hard work, but it's work that's needlessly being imposed upon downstream maintainers. The community as a whole will benefit from faster turnaround time.

Maybe it'd make sense and possibly safe enough to automatically merge PRs by ruby-builder-bot, after they pass CI of course ... if someone is interested, please make a PR to setup-ruby.

I will take a look.

Maybe it'd make sense and possibly safe enough to automatically merge PRs by ruby-builder-bot, after they pass CI of course ... if someone is interested, please make a PR to setup-ruby.

I've opened https://github.com/ruby/setup-ruby/pull/848.

However, I don't think that it's a good idea to auto-merge on a project so critical in the Ruby supply chain. For a foundational action that runs across thousands of CI pipelines, the blast radius of a bad merge is huge.

Auto-merge might be reasonable, but only if it’s tightly scoped to low-risk, mechanically generated changes with strong guardrails (which this PR has tried to do); but if ruby-builder-bot gets compromised then it's game over for the Ruby supply chain.

Would a more appropriate response simply be to empower a couple of people to review and merge bot PRs in the setup-ruby repository?

I don't really see the point of automerging PRs when someone still has to create the release manually. Merging the PRs is not much effort, someone just needs to do it.

Having this happen as part of release management sounds reasonable to me.

But I think the bigger issue here is that windows builds are not first-party. So even if the release process gets adapted, issues like what @mdalessio (Mike Dalessio) wrote above will not be solved.

Someone else handles the windows builds and that doesn't happen at the same time the release does, so there will always be some kind of delay (2 days this time I think, ignoring time to merge the PR)

That said, for those that don't use windows in CI, changing something would still help.

Earlopain (Earlopain _) wrote in #note-6:

I don't really see the point of automerging PRs when someone still has to create the release manually. Merging the PRs is not much effort, someone just needs to do it.

I meant the release would also be automated after such a PR is automerged.
(Otherwise indeed there is no point)

Eregon (Benoit Daloze) wrote in #note-2:

So I think this is something to add to the post-release checklist:

@hsbt (Hiroshi SHIBATA) Would you be willing to do those steps when releasing a new version? Is there a public release checklist somewhere?
Other X.Y Ruby releases are released by other release managers though: https://github.com/ruby/ruby/wiki/Release-Engineering,
so we'd need @nagachika (Tomoyuki Chikanaga) and @k0kubun (Takashi Kokubun) to do it too (and give them permission for it), or @hsbt (Hiroshi SHIBATA) to volunteer to do it for all releases.

FWIW ruby-build updates are automated:
https://github.com/rbenv/ruby-build/commit/ff530f6f77af68d081812643f0c16250287a6e7b
https://github.com/rbenv/ruby-build/pull/2430

Earlopain (Earlopain _) wrote in #note-6:

But I think the bigger issue here is that windows builds are not first-party. So even if the release process gets adapted, issues like what @mdalessio (Mike Dalessio) wrote above will not be solved.

Yeah, that's a good point, so then we'd need to e.g. give permission to @larskanis (Lars Kanis) to merge & release setup-ruby then, since he does the RubyInstaller releases.

I'd be OK with that, but it starts to be quite a few people and easy to forget, so currently I'm thinking the auto-merge + auto-release approach with appropriate guardrails is better and avoids adding even more work for Ruby releasers and myself, and I'm sure they are already very busy.

I left some thoughts in the PR, but will post here to keep discussion in one place.

Thanks for taking the time to open this PR to move the discussion forward, even though you’re understandably skeptical of the approach. I share your concerns.

For context, I’m a lead maintainer for Homebrew, where we make extensive use of automerging across our repositories, but only with significant guardrails. Our merge process is more complex than setup-ruby, but automerge is never fully hands-off. It only occurs after explicit human review and approval.

Given the critical role setup-ruby plays in the Ruby supply chain, I think a better path forward is increasing the number of people involved in release management, rather than further reducing human oversight. Adding release managers, as @Eregon (Benoit Daloze) suggested on the bug tracker, seems like a safer and more sustainable solution.

Eregon (Benoit Daloze) wrote in #note-9:

I'd be OK with that, but it starts to be quite a few people and easy to forget, so currently I'm thinking the auto-merge + auto-release approach with appropriate guardrails is better and avoids adding even more work for Ruby releasers and myself, and I'm sure they are already very busy.

Would CODEOWNERS or a ping from the bot when a PR is opened not suffice for the 'easy to forget' portion? If the plan is to merge a PR, and then cut a release, this could be automated in GitHub Actions so that maintainers will only need to put eyes on a change, merge it, and be on their way.

If people care about getting an answer from release maintainers, they can add this ticket to the dev meeting.

mdalessio (Mike Dalessio) wrote in #note-4:

A counter-example, though, is that the PR for windows support (https://github.com/ruby/setup-ruby/pull/847) took 3 days to get merged.

Windows got released on Dec 27 though, do you expect OSS maintainers to work through the winter holiday break to check PRs every day? (that's tricky, e.g. I'm typically abroad and without a computer at that period)
I think one fundamental issue here is CRuby is doing feature releases at probably the worst time of the year.
It would be fine if people don't have expectations of anything happening e.g. until the new year, but that's clearly not the case.

#844 got merged the same day, what would you expect?

A counter-example, though, is that the PR for windows support (#847) took 3 days to get merged.

... do you expect OSS maintainers to work through the winter holiday break to check PRs every day

Of course not. I can see that you're feeling attacked here, and that was not my intention, and I apologize. I'm thankful for all the work that you do.

But the fact of the matter is that the setup-ruby project is critical path for much of the community, and the lack of a release holds up people who are working on open source over the holidays.

I have no expectation that you personally should be responsible for cutting these releases at an inconvenient time. But since you're the maintainer of the repository, I do hope you would be involved to answer the question, "Should cutting a setup-ruby release be part of the ruby core release process?" and if the answer is yes, "How can that be done in a sustainable way?"

I'm only getting involved here because I do tend to work on Ruby over the holidays, my projects depend on setup-ruby for proper testing, and I'm willing to help (as I've already tried to do in https://github.com/ruby/setup-ruby/pull/846 and https://github.com/ruby/setup-ruby/pull/847).

You can add me as a ruby-setup releaser, if that helps. I did some PRs already and know roughly how it works for Windows releases.

But the RubyInstaller releases will not come out earlier. It's a project I care about, but it's still a spare time project. When a new ruby release comes out, I suddenly remember that there are several open issues, that the CI is broken and sometimes I notice some issues with the new release or other components. I'm not part of the ruby release process, so the RubyInstaller will always take a few days to follow. But I don't want to be part of the Ruby release process either, because my inability to do things in time would otherwise delay the release for all users.

While I don't like requests with no reaction within half a year, everything within some days is OK for me. There is a mechanism to force a particular commit before release, which helps to overcome a pending release. That mechanism maybe could be described in the README.

To be honest, I like the Christmas release date of Ruby. Over the holidays I can make all my open source projects compatible to the new ruby version and in the first week of January, I do the same at all the closed source code at work. Some co-workers wait urgent to work with the new release and others are telling me that my code doesn't run properly on RUBY-2.4! Yes really 2.4!

In contrast, ruby-build is maintained by the rbenv organization and tends to become available shortly after a Ruby release. This makes it easier to start using new Ruby versions immediately.

This is by my effort. However, I don't think anyone can do this, and I'm only doing it because it happens to be a workday. If the release date is a holiday in Japan, ruby-build will also be 2-3 days later.

I don't want to add extra manual work to release workflow. I would like to only support to build automated workflow includes ruby-build for this request.

Releasing a new Ruby version around Christmas is certainly done with some intention in mind — it's nice to let people who enjoy OSS during the holidays try out the latest Ruby right away and have some fun with it. So I do understand the desire to get setup-ruby updates to everyone quickly.

That said, Ruby releases are work that quite a few people in the past have found really challenging and eventually stepped away from.
When I took it on, my guiding principle has been to keep the ongoing, routine tasks as sustainable and low-stress as possible.
For that reason, I'd really prefer not to add any new steps to the process even something that seems as straightforward as just pressing one button.

Also, I don't want to make people who prefer to spend Christmas on non-OSS things feel pressured to work on it.

With these kinds of constraints in mind, improving the process becomes quite a technical and thoughtful challenge.
I agree that we should discuss about "How can that be done in a sustainable way?"
I'd really appreciate it if koic-san, who opened this ticket, could also consider it from this perspective.