Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Amend RFC 1242 to specify what “minimal maintenance” means for r-l-deprecated crates #2624
Jan 13, 2019
Having a better understanding of what it means to deprecate a nursery crate seems like a good goal to me!
The main concern I have right now is I don't think this RFC sufficiently acknowledges our real lack of bandwidth for some nursery crates, let alone those in the deprecated organisation. I think bandwidth is the main reason some of these libraries receive no maintenance. Reviewing, merging, and publishing even small PRs in a repository that you aren't immersed in has a lot of peripheral context building effort in addition to that needed to review, merge, and publish. Having a policy for maintenance doesn't create bandwidth for what is, unfortunately, a bit of a thankless task.
On the other hand though, if there are folks interested in supporting these libraries then having a framework for helping them decide what level of contribution to consider might help them onboard.
In a sense, I think the question of who should be performing the maintenance is orthogonal to this RFC. The status quo already calls for maintenance. This RFC just specifies what's included in that. If there are currently deprecated crates without maintainers, that situation should be resolved by the crate owner/libs team/community ASAP.
Perhaps you are implicitly advocating for no maintenance. As mentioned in the drawbacks/alternatives section of this RFC, I don't think that's a defensible position.
I don't agree with the “peripheral context building effort” part. Especially for small PRs, often no context is needed. Looking at the most recent merges of time and rustc-serialize, most of these could've been easily reviewed by anyone familiar with Rust but not at all familiar with the crate itself.
I get the sentiment here, and while it doesn't seem unreasonable I think reality undermines the goals of this RFC. So I have to disagree that the question of who should perform the maintenance is orthogonal. It's fundamental. Without addressing that root problem we're really just elaborating on a process that doesn't actually exist outside the text in this repository.
That being said, I'm not opposed to this, I just think we need to understand the picture it fits into better, manage our expectations around how maintenance on deprecated repositories is likely to be performed, and look at how changes/clarifications to the deprecation process could result in an increase in bandwidth for these kinds of tasks.
I think setting out explicit guidelines as to how much maintenance a crate will receive is valuable. Declaring a crate to be "unmaintained", even if that's an undesirable stance, is better than claiming it's "minimally maintained" at the moment, when even minimal pull requests are not accepted.
If it's actually not enough bandwidth to maintain these crates, it's better to be up front about this. Part of the frustration with the status quo is setting incorrect expectations.
(To be clear, I'm not advocating one alternative or the other here; just that being clear about what deprecation does entail is one of the most important factors.)