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

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

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@jethrogb
Copy link
Contributor

jethrogb commented Jan 13, 2019

Rendered

@jethrogb jethrogb force-pushed the jethrogb:deprecation-maintenance branch from aed6722 to 17fc0d9 Jan 13, 2019

@KodrAus

This comment has been minimized.

Copy link
Contributor

KodrAus commented 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.

@sfackler

This comment has been minimized.

Copy link
Member

sfackler commented Jan 13, 2019

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

@jethrogb

This comment has been minimized.

Copy link
Contributor Author

jethrogb commented Jan 14, 2019

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

This comment has been minimized.

Copy link
Contributor Author

jethrogb commented Jan 14, 2019

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

This comment has been minimized.

Copy link
Contributor

KodrAus commented Jan 14, 2019

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

This comment has been minimized.

Copy link
Contributor

Ericson2314 commented Jan 15, 2019

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

This comment has been minimized.

Copy link
Member

varkor commented Jan 15, 2019

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

Update text/0000-deprecation-maintenance.md
Co-Authored-By: jethrogb <github@jbeekman.nl>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment