-
Notifications
You must be signed in to change notification settings - Fork 15
Bus Factor/More Maintainers #25
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
Comments
I agree T-rustdoc is a better long term owner. That said, I volunteer to be the second (or third, or fourth) person with publish rights short term 🙋♂️ |
This is a good point, although I'm unclear why we shouldn't add T-rustdoc as an owner now? It's usually better to have a team be the owner rather than individuals since then it's automatically synced with the team repo over time. |
mainly because i think there’s more process needed to assign a whole team to it oh gh/crates.io, and it implies a level of “officiality” that’s not true yet. if t-rustdoc is maintaining, it should probably live in the rust gh org. |
Ah I see. I thought it was already considered an official crate, but I guess that hasn't been discussed yet. 👍 |
Update on this. It was discussed on zulip, and we decided on moving to T-rustdoc, in the rust-lang github. I've opened an RFC (rust-lang/rfcs#3505). It needs to be driven forward. Mainly blocked on needing T-Infra to make sure the perm stuff is right. |
Right now, I'm the only person with write access to this repo/publish perms on crates.io. This isn't desirable for a couple of reasons.
Long term, this crate should probably be managed by T-Rustdoc , but in the shorter term, I'd like to give permissions to a second person. I don't anticipate this will be much work, as I intent to continue maintaining this for the forseable future, but they may have to make releases in my absence, and I'd try to communicate with them if I was permanently stepping away.
Before this can be done, we'd probably want to
As the current release process is attrocious (it involves tagging a fake commit, generating the changelog, deleting the tag, ammending the commit, and retagging).
I've thaught of this now, as I'm about to go camping for a week, so won't be able to publish a new version if any come through. I'm not going to make changes before then, as it's too late now, and this needs more time, which is kind of scary as rust-lang/rust#115078 may well be merged when I'm gone. While it's too late to prevent this, I don't want it to happen again.
The text was updated successfully, but these errors were encountered: