At the moment, we have a policy to use forward-compatibility lints, but no policy on how to remove them. @petrochenkov has been heroically pursuing this on their onw. @arielb1 and I were talking and wanted to propose the following strategy. The ideal pattern is as follows. Some points need refinement. =)
- Begin with a warning period for some number of cycles N >= 1
- Do one cycle of “deny by default”
- After beta is issued with “deny by default” enabled, support may be removed on stable
Conditions for each stage:
Stage 1: warning. No prior conditions, just have to write a PR. The proper procedure is described in RFC 1589.
Stage 2: deny. We have to do a crater run and at least notify all affected crate authors. Ideally, there should be pending PRs. Something like what @petrochenkov has done seems ideal.
QUESTION: I think we also want some kind of “absolute” criteria along the lines of “there shouldn’t be a lot of people affected in practice”. This means more than we have a pending PR to fix it: it means that, if a major crate is affected, the PR should have landed in a release available on crates.io so that people can just “cargo update” to get the release. Ideally, the old release would also be yanked, and this would issue some sort of warning that people get which advises them to
cargo update, but that would work best in conjunction with cargo #2608. (cc @wycats, @alexcrichton)
Stage 3: The deny-by-default branch must have reached beta. There should be not be significant controversy on the tracking issue. =)
QUESTION: Should we also require some absolute period of time? In principle, you could land a patch on nightly, branch beta, and then two days later rip out support from nightly. This has happened in the past and people who live in the nightly ecosystem were somewhat annoyed. I hope that with we can wean people from nightly with macros 1.1 and make this a non-issue, but it’s something to think about.
Exemptions from the rules
Note that I said that these are the ideal requirements. I think we always have the option to do things differently (e.g., skip stage 2) if there are other concerns, but this is a decision that must be “ratified” by the compiler team. We can use RFC bot to do this.
How do we decide when to move between stages?
This raises one final point – do we always require consent by compiler team to move to stage 2 or 3? Or should we say that if the above criteria are met, we can just move without gaining consent from the whole team?
Background on RFC bot
If you haven’t heard much about RFC bot, the way it works is that we tag the issue with
T-compiler and then send a message like
@rfcbot fcp merge. This will create a checklist for every member of
T-compiler to check off their name. You can find the list of pending RFCs on your personal dashboard http://rusty-dash.com/fcp/YOURNAMEHERE. The idea is that this is all very lightweight: you can just check off your name with a quick click if you are happy. You can also register concerns that must be resolved before consensus is reached.
If there are inactive members of the compiler team, we’ll just check their names for them, but if people are consistently inactive, we should talk to them about moving to alumni status (I think there are several inactive members of compiler team right now, so this will probably come up. =)
My thoughts on the “open questions”:
- I think we should just always use rfcbot to move between stages.
- To move to deny by default:
- We should require that less than 30 total crates are affected (not root crates)
- There should be open PRs for all root crates; if opening a PR is not possible, the authors should be notified
- To move to a hard error:
- I say as soon as the beat is branched, it’s fair game