Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REQUEST: GitHub team for publishing OpenTelemetry Rust crates #2369

Open
lalitb opened this issue Sep 30, 2024 · 10 comments
Open

REQUEST: GitHub team for publishing OpenTelemetry Rust crates #2369

lalitb opened this issue Sep 30, 2024 · 10 comments
Labels
area/project-infra Non-GitHub project infra (DockerHub, etc.)

Comments

@lalitb
Copy link
Member

lalitb commented Sep 30, 2024

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
Copy link
Member

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

@trask
Copy link
Member

trask commented Sep 30, 2024

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

@jtescher
Copy link
Member

Second option 2 👍

@TommyCpp
Copy link

+1 on option 2

@lalitb
Copy link
Member Author

lalitb commented Sep 30, 2024

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

@trask
Copy link
Member

trask commented Sep 30, 2024

@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
Copy link
Member Author

lalitb commented Sep 30, 2024

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
Copy link
Member

trask commented Sep 30, 2024

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
Copy link
Member Author

lalitb commented Sep 30, 2024

Thanks @trask, this should be good.

@svrnm
Copy link
Member

svrnm commented Oct 1, 2024

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:

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

@trask trask added area/project-infra Non-GitHub project infra (DockerHub, etc.) and removed needs author feedback labels Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/project-infra Non-GitHub project infra (DockerHub, etc.)
Projects
Development

No branches or pull requests

6 participants