@centril I don't really agree with your push to force features into a release at the wire, like in https://github.com/rust-lang/rust/pull/57367#issuecomment-466891211:
we could try to get this into 1.34 even tho FCP has not completed... at the risk of beta-backporting out if it should not complete
The whole point of the 6-week trains is that a feature goes in when it's ready. If it misses the train, then it's just 6 more weeks.
We should strive to basically be ignorant of when the trains depart, other than for marketing-related things like the edition
@Jake Goulding it's not forcing anything; its a low risk thing that is unlikely to go out of FCP; backporting out the de-stabilization would also be easy and we have the bandwidth to do it.
Note that I made no argument centered around the relative risk of the change.
OK; but I think it is an important factor when doing things like this.
You are subverting the FCP process to get on a train earlier than if you had followed the process.
You've decided that this feature is important enough to go around the process.
No, I've concluded that it's low risk and easily revertible. If FCP does not complete we will revert. We have done this several times in the past and it worked fine.
We have done this several times in the past
Which doesn't make it better. If you think that the process is broken, it's better to update the process.
There's also the question of why it needs to be done. Where's the harm in just waiting?
only (edit: critical) bug fixes should be backported
destabilisation is not a bug fix, it is a process failure
simple rule, which I think should be easy to agree with.
I'm with @Jake Goulding and @nagisa on this; the release schedule is pretty quick, waiting a few weeks is no big deal, and gives a chance to shake out more bugs (even if they are very unlikely).