Misc #21922: Permissions for committers for ex-default/bundled/unbundled gems repositories

• Status: Open
• Assignee: -

[Eregon (Benoit Daloze)]

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/curses
• https://github.com/ruby/dbm
• https://github.com/ruby/e2mmap
• https://github.com/ruby/gdbm
• https://github.com/ruby/getoptlong
• https://github.com/ruby/iconv
• https://github.com/ruby/mathn
• https://github.com/ruby/mutex_m
• https://github.com/ruby/net-ftp
• https://github.com/ruby/net-pop
• https://github.com/ruby/net-telnet
• https://github.com/ruby/observer
• https://github.com/ruby/pathname (marked as maintained by @akr (Akira Tanaka) but they don't reply on GitHub, there is also an unclear relation with core Pathname which still hasn't been resolved and is causing warnings for months)
• 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
• https://github.com/ruby/shell
• https://github.com/ruby/syck
• https://github.com/ruby/sync
• https://github.com/ruby/thwait
• https://github.com/ruby/tk
• https://github.com/ruby/tracer
• https://github.com/ruby/webrick
• https://github.com/ruby/win32api
• https://github.com/ruby/xmlrpc

This list is from a couple cases I noticed myself + all repos - those committers have access - repos with known maintainers).
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 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), which really shouldn't need an owner to merge
• PRs to improve/fix the CI (example)
• 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.)

[hsbt (Hiroshi SHIBATA)]

First of all, the title is wrong. Ruby committers can still commit to the default gem repository.

(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.)

Thanks, that's wrong permissions. I removed permissions from all repositories except default gems.

[Eregon (Benoit Daloze)]

hsbt (Hiroshi SHIBATA) wrote in #note-1:

First of all, the title is wrong. Ruby committers can still commit to the default gem repository.

Right, I'll update the title.
I reviewed the list, it contains some default gems but most of them are no longer shipped with Ruby 4.0:

• ruby2_keywords, this is a default gem but Ruby committers can't commit to it. I think either committers should have access or it should have an official maintainer (@nobu (Nobuyoshi Nakada)).
• pathname, that's a stdlib in 4.0+. It's a default gem in 3.4 and before though.
• benchmark, fiddle, irb, logger, ostruct, pstore, rdoc, readline, reline, win32ole were default gems in 3.4 and are bundled gems in 4.0. Some of these have official maintainers but not these: benchmark, pstore, readline.
• Similarly for default gems which became bundled gems in 3.4.
• I'm not quite sure what https://github.com/ruby/win32api, it seems an unbundled gem (https://bugs.ruby-lang.org/issues/8601#note-12).

Does that mean that the policy is:

• Ruby committers have write access to default gems as long as those are default gems on ruby/ruby master
• Ruby committers don't have write access to bundled & unbundled gems.

Is that written somewhere? What's the reasoning behind it?
I understand e.g. permissions for publishing a bundled/unbundled gem should be more restrictive, but for merging PRs it seems not problematic and helpful if Ruby committers could do that, same as when those gems were stdlib or default gems.

For gems which used to be default gems I think it would be good that Ruby committers still have access, because they are still default gems on actively supported versions like 3.3 & 3.4.

Who has access to bundled & unbundled gems then? Only the 4 owners of the Ruby GitHub organization?
It doesn't seem ideal to conflate "owner of the Ruby org" and "allowed to merge PRs to gems without an official maintainer". It seems separate roles to me.

Wouldn't it be best if Ruby committers could help maintain those gems without an official maintainer, especially for examples I gave in the description?

In the current situation it seems to me that @hsbt (Hiroshi SHIBATA) is the only one merging such PRs to bundled/unbundled gems without an official maintainer.
That seems a lot of work for one person, could this be better?

[Eregon (Benoit Daloze)]

• Subject changed from Permissions for committers for default/bundled/unbundled gems repositories to Permissions for committers for ex-default/bundled/unbundled gems repositories

[st0012 (Stan Lo)]

I agree that we should have clearer rules on how committers can/should engage with gems under the ruby org.
My (perhaps outdated) understanding was:

• Ruby committers can make changes to gems they don't maintain for misc/doc changes, or sometimes bug fixes too. This includes both default and bundled gems.
• To make non-trivial changes, like features or big refactoring...etc., committers should consult with existing maintainers and get consensus.
• For gems that are unmaintained, ask @hsbt (Hiroshi SHIBATA) for assistance (thanks for all the help in the past few years!)

I understand e.g. permissions for publishing a bundled/unbundled gem should be more restrictive, but for merging PRs it seems not problematic and helpful if Ruby committers could do that, same as when those gems were stdlib or default gems.

With wider adoption of trusted publisher, the write/release permission will become inseparable. And if we were to follow the least-privilege principle, does it make sense to automatically expand permission to ALL of these repos to ALL committers? Should we have a process for committers to request/return access instead?

[Eregon (Benoit Daloze)]

st0012 (Stan Lo) wrote in #note-4:

the write/release permission will become inseparable

I think Deployments environments could help here.
I.e. the release workflow would run in a special release environment, which would need explicit approval (from the people allowed to release).

[Earlopain (Earlopain _)]

Rulesets would also work. You create one targeting all tags and simply restrict tag creation to whoever is allowed to release (org admin, repo admin, maintainers, etc.). Deployments do give better insight into the process though.

[Eregon (Benoit Daloze)]

I noticed https://github.com/ruby/ruby/blob/master/doc/maintainers.md#bundled-gems-upstream-repositories-and-maintainers says a few things about this topic:

Bundled gems upstream repositories and maintainers
The ruby core team tries to maintain the repositories with no maintainers. It may needs to make consensus on ruby-core/ruby-dev before making major changes.

But how can the core team maintain them if they can't merge PRs?