REQUEST: GitHub team for publishing OpenTelemetry Rust crates

[lalitb]

The @open-telemetry/rust-maintainers GitHub team has been the owner of OpenTelemetry-related Rust crates on crates.io (https://crates.io/teams/github:open-telemetry:rust-maintainers), allowing package publishing.
Due to the accidental deletion (#2356), and subsequent recreation of various teams under the OpenTelemetry organization, this team can no longer be used as the crates.io owner. This is caused by a known bug in crates.io: rust-lang/crates.io#6949, specifically prohibiting the reuse of a recreated GitHub team with the same name as a crate owner.

We need to decide on a solution soon as the publishing of new crates is blocked now. Options I can see for now:

1. Rename the rust-maintainers team: to (say) otel-rust-maintainers
   Drawback: Inconsistent with existing maintainer group naming conventions

2. Create a new publishing team under OpenTelemetry Org: e.g., rust-publishers with rust-maintainers as the sole member
   Advantage: Allows future flexibility to grant publish rights to non-maintainers

3. Add the existing maintainers as the individual owner members of the Otel crates.
   Drawback: This would be difficult to manage, scale, and keep things organized in the long term, with 20+ crates in the main and contrib repo.

@open-telemetry/rust-maintainers please comment if there are better suggestions. Option 1 and 2 would need help from the TC/GC, and I would prefer to go with Option 2.

[cijothomas]

+1 to option 2, given it avoids the inconsistency part and has no other downside I can think of.

[trask]

@lalitb let me know when you all are decided and I can create the new team

[jtescher]

Second option 2 👍

[TommyCpp]

+1 on option 2

[lalitb]

Thanks all. @trask can you help with creating the new team - rust-publishers.

[trask]

@open-telemetry/rust-publishers created

I added rust-publishers in between rust-maintainers and rust-approvers, can you check this and confirm this is the setup you want?

[lalitb]

I added rust-publishers in between rust-maintainers and rust-approvers

Does it mean that rust-publishers is now child team of rust-approvers, and the rust-maintainers the child of rust-approvers ?
So adding any new member in rust-publishers will make them as approvers, as this is not what we want.

[trask]

I added rust-publishers in between rust-maintainers and rust-approvers

Does it mean that rust-publishers is now child team of rust-approvers, and the rust-maintainers the child of rust-approvers ? So adding any new member in rust-publishers will make them as approvers, as this is not what we want.

ok, I have updated rust-publishers now so that it has no parent, and I have re-parented rust-maintainers back to rust-approvers.

please check and confirm this is the setup you want, thanks

[lalitb]

Thanks @trask, this should be good.

[svrnm]

Just a drive by comment since I did some research for that for my day job: a practice we implemented for cisco-open is that all packages are owned by a service account (e.g. https://github.com/opentelemetrybot or a dedicated one), and credentials for that account are stored in a 1password, that way even if all maintainers leave, there is someone with full privileges.

This is especially important because only non-team owners have permissions to add/remove other owners, see https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner (emphasis is mine):

If a team name is given to --add, that team is invited as a “team” owner, with restricted right to the crate. While they have permission to publish or yank versions of the crate, they do not have the ability to add or remove owners. In addition to being more convenient for managing groups of owners, teams are just a bit more secure against owners becoming malicious.

Note, that this seems to be practice across other orgs as well:

• here is our service account: https://crates.io/users/cisco-service
• similar practice from AWS Labs: https://crates.io/users/aws-sdk-rust-ci

We also made the service account the sole non-team owner of the crates, but this is due to the given governance structure. This is something the rust maintainers need to decide on themselves, since doing that has both upsides and downsides