Amend RFC 1242 to specify what “minimal maintenance” means for r-l-deprecated crates

[jethrogb]

Rendered

[KodrAus]

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.

[sfackler]

I am also curious who exactly you think is going to be performing this work.

[jethrogb]

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.

[jethrogb]

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.

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.

[KodrAus]

In a sense, I think the question of who should be performing the maintenance is orthogonal to this RFC.

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.

[Ericson2314]

We should really look at the dependency graph. Maybe there's just a few popularish crates still using these that bump up the download counts.

[varkor]

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.)

[gnzlbg]

If there are currently deprecated crates without maintainers, that situation should be resolved by the crate owner/libs team/community ASAP.

@jethrogb How ? Finding maintainers even for non-deprecated crates is hard. The crate owner in this case would be the rust-lang org, and beyond asking whether someone wants to maintain a particular crate, there is not much that can be done AFAICT.

[jethrogb]

@gnzlbg I'm not convinced that this is going to be an issue. If someone wants something to change about a crate without a maintainer, they are incentivized to find a maintainer. It could be that same person as well.