Description
Summary
Hi all, T-compiler had some internal discussions about our current feature stabilization procedures, especially if a feature stabilization is a cross-team consideration.
For instance, we may want to improve or add a Stabilization Checklist (for example: documentation, test coverage, FCP/sign-off by relevant teams, FIXME searches, outstanding issue searches, sufficiency checks / double-checks by relevant "owners").
A concrete concern that spawned the above idea is that stabilization PRs are very hard to review -- to the reviewer, it can just seem like "flipping some gates" and "mechanically changing and reblessing a few tests".
Example feature stabilizations where our project-level cross-team stabilization procedure doesn't seem as good/coherent as it can be:
- Stabilization of
#[coverage]attribute: Stabilize #[coverage] attribute rust#130766- Stabilization of
#[derive(CoercePointers)]: Stabilizederive(CoercePointee)rust#133820To be very clear: this is not intended to point blame at any specific individual nor team, but moreso that cross-team stabilizations don't really have a project-level coherent procedure, that helps to make sure that what we stabilize are what we-as-a-project are happy with. We would benefit from having a more refined stabilization procedure that's less confusing for everyone :3
About this issue
This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.