More crates-maintainers repos

[rylev]

r? @m-ou-se

cc @rust-lang/crate-maintainers

Note: some of these repos used to give access to libs and/or libs-contributors . If anyone is missing access, it's just a PR away from giving it to them.

[thomcc]

Some comments -- perhaps these are they way they are deliberately though.

[thomcc]

Note that this is missing pkg-config, flate2, socket2, getopts, backtrace from the list in #861 (comment).

I don't have super strong opinions on these (but have already started helping out on pkg-config-rs, and at least flate2 needs a release).

[rylev]

pkg-config was done in #875. The others require some added functionality I'd like to do in a follow up PR.

[Mark-Simulacrum]

Would like to see approval from Mara as well to validate this, but seems good to me.

[thomcc]

Should this allow publishing to crates.io? I'd like to cut releases of some of these crates soon and looking at e.g. https://crates.io/crates/cc it still only lists rust-lang/libs and rust-lang-owner as having publish rights, not rust-lang/crates-maintainers.

[Mark-Simulacrum]

I personally would like to avoid adding all crates-maintainers directly to the publishing rights, but rather allow publishing via some token that is owned by rust-lang-owner (or a similar bot account). We need to build that system still though. (This is mainly to reduce the burden of trust for adding someone to the team: pushing/merging in GitHub and a crates.io publish have pretty different blast radii).

In the meantime I'm happy to own the debt of publishing crates where necessary with relatively little latency.

[thomcc]

In the meantime I'm happy to own the debt of publishing crates where necessary with relatively little latency.

That sounds like a pretty tedious workflow if I'm being honest, especially if it's to last until some future system is built that doesn't sound like it's been designed yet.

Worth noting that one of the points of frustration people have about some of these crates has been too much time between releases.

[thomcc]

FWIW, in the short term I only really want publishing rights for cc-rs and cmake-rs, since those are the crates most immediately I intend to try to improve (well, pkg-config too, but that just had a release cut). flate2 also has users asking for a release, and I haven't had time to look over most of the others yet.

[Amanieu]

In the case of compiler-builtins I often publish a release immediately after a PR is merge. This is sufficiently infrequent (less than once a week) that if I don't do it immediately I will forget to do it. In any it's not like we're at risk of running out of version numbers.

[thomcc]

I don't know that I would do it that frequently (I was thinking more along the lines of once a week if there were changes merged), but I keep fairly odd hours a lot of the time, and do a lot of open source work pretty late at night for most folk (and over the weekend).

Given that the release has parts that happen before publish (bumping the version) and after publish (cutting a tag, compiling a changelog, publishing a github release), I would really rather not have an intermediate step there of "ask someone else to perform the publish for me" (which might take a while if I ask at 2am PST or something) -- that sounds really annoying.

[thomcc]

FWIW, #861 (comment) does indicate that crates-maintainers should have publish access, if it makes any difference.

[Mark-Simulacrum]

I think we should discuss more, but I would guess a simple scheme can be put together pretty quickly that automates the publish of an existing GitHub commit (for example).

It may be that we give the team access for now to most of these crates and then drop it in the future.

[thomcc]

Yeah, that scheme sounds fine; I would only ever want to publish commits that are already in the repository of course.

My objection was based mainly around having to wait on someone to get things done -- longer term I don't mind having automation be responsible for it at all (especially if it's integrated with tagging, which allow some assurance what got published matches what was tagged).

(And as you might expect, as a result I'm in favor of giving access now and dropping it once the scheme is in place, but I can wait for more discussion)