Issue #21922 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) The comment in https://bugs.ruby-lang.org/issues/21922#note-4 accurately reflects the current status and the necessity of this restriction for the most part. However, to be more precise: historically, Ruby committers could freely merge changes (such as misc/doc or bug fixes) even into bundled gems repositories, provided they were previously default gems. I have since strictly revised these permissions across the board because we saw instances where massive rewrites were forced through without reaching any consensus. From my perspective as a release manager, we should not grant write access based on individual runtime needs. I want to avoid situations where such uncoordinated changes cause test failures right before a release or force us into unnecessary re-releases. I am supportive of this proposal if we form a "Legacy Gems Maintenance Team" consisting of experienced maintainers who already manage multiple gems, such as @@jeremyevans0 (tk, webrick), @kou (REXML, RSS, CSV), @st0012 (irb, rdoc), and myself (Rake, syck). This team should specifically handle repositories only where the primary maintainer is absent. ---------------------------------------- Misc #21922: Permissions for committers for ex-default/bundled/unbundled gems repositories https://bugs.ruby-lang.org/issues/21922#change-117056 * Author: Eregon (Benoit Daloze) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I noticed recently that the team `ruby-committers` on GitHub no longer has write access to at least: * https://github.com/ruby/benchmark * https://github.com/ruby/cmath * https://github.com/ruby/dbm * https://github.com/ruby/e2mmap * https://github.com/ruby/gdbm * https://github.com/ruby/getoptlong * https://github.com/ruby/mathn * https://github.com/ruby/mutex_m * https://github.com/ruby/net-pop * https://github.com/ruby/net-telnet * https://github.com/ruby/observer * https://github.com/ruby/pathname (moved to core in 4.0) * https://github.com/ruby/prime * https://github.com/ruby/pstore * https://github.com/ruby/readline * https://github.com/ruby/readline-ext * https://github.com/ruby/ruby2_keywords * https://github.com/ruby/scanf * https://github.com/ruby/sdbm * https://github.com/ruby/set (moved to core in 4.0) * https://github.com/ruby/shell * https://github.com/ruby/sync * https://github.com/ruby/thwait * https://github.com/ruby/tracer * https://github.com/ruby/win32api This list is from a couple cases I noticed myself + [all repos](https://github.com/orgs/ruby/repositories?q=mirror%3Afalse+fork%3Afalse+arch...) - [those committers have access](https://github.com/orgs/ruby/teams/ruby-committers/repositories) - [repos with known maintainers](https://github.com/ruby/ruby/blob/master/doc/maintainers.md)). I filtered manually so there could be some mistake(s), though I tried to check carefully. I am certain CRuby committers had access to some of these repositories (e.g. I merged PRs there), but not sure about all, some might already not have had write access for CRuby committers. It seems only the 4 owners of the Ruby GitHub organization have write access to these repositories. What motivated these changes? I believe it is valuable that all CRuby committers can merge to default/bundled/unbundled gems repositories *without active maintainers*, as it was before. There is [this list](https://github.com/ruby/ruby/blob/master/doc/maintainers.md) to define maintainers, though it's a little bit outdated and inaccurate. It's fine enough for this issue though. (A better definition IMO for active maintainers would be maintainers would actually respond to PRs and issues on GitHub to these repositories otherwise they are effectively not maintaining that repository, at least from an external perspective.) IOW it seems unreasonable to always have to ask one of the 4 owners of the Ruby GitHub organization to merge a PR to such repositories, as it would be a significant overhead for committers and for owners, and it would delay merging PRs significantly. I'm thinking for example to * documentation PRs ([many for pathname](https://github.com/ruby/pathname/pulls)), which really shouldn't need an owner to merge * PRs to improve/fix the CI ([example](https://github.com/ruby/readline-ext/pull/29)) * PRs fixing compatibility with recent changes in ruby's master branch * etc. Yet another way to see this is many default/bundled/unbundled gems do not have active maintainers. AFAIK so far in such cases then all CRuby committers could help, but this seems no longer the case. (FWIW I saw there a `default-gems-contributor` team with 3 people, which explains why they can merge PRs to some repositories that ruby committers can't for example.) -- https://bugs.ruby-lang.org/