The rust-bus user is visible on crates.io crate pages. I think that's enough, but feel free to add a badge to your repos if you like.
Added rust-bus-owner for two crates, but only the first got through. Some bot hit API limits? Or is it manually approved?
What about an organization for the purpose of squatting crates? Since crates.io doesn't have any formal way to release squatted crates for others to claim, we could have an organization whose purpose is to hold squatted crates so that other people could apply for those crate names for their own crates.
Additionally, we could preemptively start squatting any good unclaimed crate names, to prevent anyone from maliciously squatting them which is a problem that crates.io still doesn't want to clamp down on.
I have around 400 -sys creates that I no longer want due to changing the organization of winapi, so I'd be happy to take the charge on something like this.
1 Like
What if just rust-bus them all?
for i in *-sys; do (cd $i && cargo owner --add rust-bus-owner); done
That'd be great. Go ahead.
Thanks for the advice but right now there is still some discussion going on on squatting such as this.
Shouldn't this be something built-in into crates.io? Maybe with an opt-out? A crate without an update for year (or without someone manually clicking some button or something), would be marked as orphaned, and could be requested for re-assignment (that would go through manual vetting, etc.)
2 Likes
Hello
Would you be interested in me helping out? How much work do you find it? Not that I'd be eager to find myself more work, but if I'm going to use you as a backup for my crates, it's only fair to offer something back too.
(my github username is @vorner, same as here)
1 Like
Thanks @vorner!
We haven't figured out yet a process for how we should work, so feedback welcome:
-
Should we be actively searching for crates that need maintenance? Or wait until someone asks for intervention? How?
-
If we know a crate needs a maintainer, how do we find one? Where do we announce it? Should we have a site that lists such crates for example?
We've got 61 crates so far, but we haven't worked yet in an organized fashion.
I don't think there should be any active manual work involved. That wouldn't scale well. I also think that there should be intervention only in case it is really needed, so maybe waiting until someone asks for it is good. The rust-bus owner is visible on the crate page, so it should be discoverable by whoever feels impatient.
As for the maintainer, I think announcing here on the forum and through the badge on crates.io could work. Let's see what happens few times first before making processes or sites 
.
Anyway, I was wondering if a crate author should be able to express some wishes about how interventions would be handled ā eg when searching for a maintainer, what the criteria would be and so on.
I agree. I also fear that adding maintainers based on "who's been around" would shy away potential contributors. The Rust community is very inclusive (that's my personal experience), and I think it should be a goal for the Rust bus too. Trust is subjective and prone to bias.
Maybe the bus could require releases or new members be approved by at least two persons?
Me too --- push access to 61 crates is a big responsibility. Are there ways acces could be more distributed?
Unrelated, but there's a similar project in the python ecosystem called jazzband. Maybe they have some advice on running this kind of organization?
Good point. We have to think how we manage membership. It's a tricky problem: it requires a lot of trust, because having access to other people's crates is a huge responsibility, but also we want to be inclusive and welcome everyone who wants to help.
1 Like
I think distributing control of all rust-bus crates is moving into the wrong direction. The only way to prevent misuse of power is to incorporate consensus, but even then history shows this isn't airtight.
What I'm typing below is just some random ideas, because progress seems to be halting.
I think automatisation is key here, have bots randomly assign 2/3/3+ people from the bus-group to each pull-request as reviewer. Other people can chime in of course, but the bot will only merge+deploy or close when at least 2/3 of participants give approval.
When an assigned member doesn't respond within 7 week days and the issue isn't resolved or closed, 1/3 of the current participant count of new members will be assigned to the issue to speed up consensus about closing, merging or reset of the timeout counter.
Only the bot is allowed to close, merge and publish. The master branch will be blocked from being pushed to. Cargo publishes are blocked unless they come from the bot.
EDIT: In a sense, this is distribution of control.. which means I actually don't disagree with your opinion.
5 Likes
Yeah a tough central v/s decentralisation problem to be solved. We could divide into groups but then the trust issue will increase (with questions such as how do we trust an entire group now?)
I think for starters at least, it is good to keep it centralised at this point. As long as any discussions with regards to a crate is taken only after consulting the entire group, there shouldn't be much of a problem. Though we need a central communication channel (we have a gitter channel already but gitter is buggy which keeps people away)
I think what's more important at this point is forming a report mechanism. Currently, there is no way for us to know if any crate falls under the bus.
I agree with keeping crate code and control centralized.
The only thing we can 100% solve is preventing drive-by PR's from becoming (semi-) decent forks on their own, which will only confuse crate users.
What remains is indeed figuring out how to find bus-crates and guaranteeing "quick" response to code fixes.
I agree with this and your suggestion about giving control to a bot that obeys the consensus. I think this should apply to publishing to crates.io and adding new members too.
I'm now convinced too that we shouldn't split the bus into smaller teams, if that is what you mean.
Or Discourse:
Is Rust Bus about maintainership without an actual owner using bots (as being discussed in posts above) or just about finding a new owner that will "catch the falling flag" and become a new, Rust Bus-independent owner of the crate.
I suggest concentrating on the latter: finding new owner, not trying to maintain without an owner. For this the two main questions are:
- When to give access? This requires settling on definition of an abandoned crate, set conditions to become a new owner (e.g. the owner-prospect should already maintain a fork of the project).
- When to revoke access? If new (or even original) owner starts publishing malware to Rust Bus-monitored crate, it may be reason for Rust Bus to intervene.
3 Likes