Relevant to that: Maybe it's time for a "crates-team"?
I don’t think it needs to be a binary abandoned/not-yet-abandoned. Authors may be unavailable temporarily (e.g. health reasons), or even technically still be available but just “not have time” and touch the crate once a year.
So the rule could be: the longer the author is not involved, the bigger intervention is acceptable.
A recent case was: a new version of Rust affected type inference and the crate needed a 1-line fix. People with pitch forks started gathering on github. The author was not responding for a couple of weeks, but returned eventually.
Taking over the crate and looking for a new maintainer after a couple of weeks would definitely be too much, but OTOH releasing a patch version with the 1-line fix would solve the problem well.
I suggest making it depend on time scale:
- short term (weeks?): nothing except obvious urgent bugfixes
- obvious, because it would be horrible to break someone else’s crate for them
- urgent, because otherwise it can wait for the maintainer (I imagine urgency here dictated mostly by external deadlines like new Rust releases or discovery of security vulnerabilities)
- longer term (months?): if a new fork emerges, help switching to the new fork.
- for libraries it’s easy to publish code as
extern crate new_fork; pub use new_fork::*to gently migrate users.
- for libraries it’s easy to publish code as
I’d also like to help out. I’m
jonas-schievink on GitHub.
I like this general idea, and I think it does a lot to shore up potential issues within the ecosystem. Having backups would be great for a lot of projects. Even if just to mark an entire crate as deprecated.
However, I’m also slightly concerned at the widely increased attack surface this presents. Am I understanding correctly that anyone in the bus organization would be able to push updates for any crate the org is marked as an owner on? To my knowledge there isn’t great reporting for when a package you published gets updated. It would be fairly trivial for someone to push a package update from the bus org to a project under the radar.
Yes, this is a problem. I’ve made a feature request to allow inviting teams, so that non-members can add them:
there should be a group of trusted volunteers
You emphasized “group”, while I’m more worried about “trusted” Especially with the current “message me and I’ll add you” approach.
- I verify who asks to be added and accept only people who have been in the community for a while.
- The feature request I’ve linked to will eliminate the need to add users to the GitHub group, since they will be able to give ownership of crates without belonging to the group.
(I might be off topic here, but it’s related to abandoned crates, so hopefully not too off-topic)
Could there possibly be a distinction between abandoned crate and finished crate?
crates.io just shows the last updated time, but sometimes there’s simply nothing the author can add and it becomes difficult to assess the usability of the crate.
Would be nice if there’s a “pulse” signal or “heartbeat” that the author or the group can can trigger to essentially say “Yep the crate is still being looked after, just nothing to do atm, that’s all”.
Trust is definitely tricky. I think for this to work it needs to be wholly clear and transparent about what its goals are and who’s involved.
I would favour a separate organisation whenever possible like we did with
uuid, with the bus factor team having permissions on crates.io and a separate team having ownership of the repository in its organisation.
There’s a bit of a difference in approach between centralising maintainership under a single umbrella organisation, and distributing it amongst disparate teams. I’m in favour of decentralisation here.
It doesn’t necessarily need to factor in to this at all though if it’s only concerned with being able to push a fork to crates.io under the same name. That’s where I think the question what does it mean for the bus factor team to share ownership over a crate? matters.
Help maintain `bitflags`!
It is a tradeoff. Centralised organisations brings about reputation and trust though. For example you are more likely to use a crate from rust-nursery or serde than some random user.
In Github org, you can create teams and assign only those members to certain repos.
Though i’m fine with either approach.
It might be a good idea for everyone in the org to set their visibility to “public” instead of the default “private” so everyone can see who’s involved and who would get access to their crates. For members, you can do that at https://github.com/orgs/rust-bus/people.
Thanks for pointing that out. Have changed it for my profile
Iron has an org with 7 people, so I think they’re covered.
Yeah I know but they can’t maintain it any more
Anyone wants to co-maintain sodiumoxide crate? You can reply here or DM me or on gitter and will follow up with you.
What is the difference between
cargo owner --add rust-bus-owner and
cargo owner --add github:rust-bus:maintainers? The latter fails for me.
The second command is listed as primary command (for example, in Github’s org description), and I hesitate about the first command because of it may add a regular owner, not less privileged group owner like Rust Bus is supposed to be as far as I know.
If I indeed need to use the first command, maybe it should be advertised more than the second?
Shall there be a Github README.md badge for repositories opted into the Rust Bus program?
cargo owner --add rust-bus-owner. We’ve tried the other command first, but as you’ve found out, it doesn’t work for everyone. I’ve updated the org description.