Require approval from t-infra instead of t-release on tier bumps #144906
Conversation
rustbot
added
the
S-waiting-on-review
|
r? compiler_leads |
|
Has the release team weighed in on this? I agree this conceptually makes more sense but since the original policy was the result of an RFC, I think we should do a T-release/T-infra FCP to confirm this is what both teams want. |
|
I asked Mark, who was fine with it (along with most members of t-infra), but yeah, we should probably involve the whole release team. |
|
@rust-lang/release hi everyone, this change takes you off the compiler target tier changes FCPs, are y'all happy with that or do you see a reason to involve the release team there? |
Noratrieb
added
T-infra
|
@rfcbot fcp merge Historically the release team was on the FCP because early discussions imagined we'd be checking the "value" of a target, but I think T-compiler and T-infra are better positioned for this anyway (e.g., pulling statistics on usage, deciding how different individual targets are - and so how much usage of one indicates reason to promote others) and T-release doesn't have a large body of stakeholders in various platforms. T-compiler also has established processes for exploring these questions as part of tier 2 and 3 target proposals. So proposing we merge this, happy to see any concerns registered. |
|
Team member @Mark-Simulacrum has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
|
@rfcbot reviewed I don't have a problem with switching release to infra here. However, on a tangent, I wonder why the "value" question has been delegated to compiler and not also libs, especially when non-host targets are considered. |
In practice, I think libs do get asked about if the libs team would have concerns with promoting a target beyond Tier 3, but mostly from an impl POV (and not necessarily "value"). For example: rust-lang/compiler-team#864 (comment). (But this is also not necessarily "written down".) |
rfcbot
added
the
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
removed
the
proposed-final-comment-period
davidtwco
added
S-waiting-on-fcp
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
|
@bors r+ rollup |
bors
added
the
S-waiting-on-bors
davidtwco
removed
the
S-waiting-on-fcp
…idtwco Require approval from t-infra instead of t-release on tier bumps Discussed at https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Tier.201.20target.20promotion.20RFC.20FCP.20sign-offs/with/532735844. I also changed "viability and value" to just "viability". I think that t-infra should decide whether it's viable to support a given target on our CI. The value should be determined by t-compiler. r? `@jieyouxu`
…idtwco Require approval from t-infra instead of t-release on tier bumps Discussed at https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Tier.201.20target.20promotion.20RFC.20FCP.20sign-offs/with/532735844. I also changed "viability and value" to just "viability". I think that t-infra should decide whether it's viable to support a given target on our CI. The value should be determined by t-compiler. r? ``@jieyouxu``
Rollup of 33 pull requests Successful merges: - #139345 (Extend `QueryStability` to handle `IntoIterator` implementations) - #140740 (Add `-Zindirect-branch-cs-prefix`) - #142079 (nll-relate: improve hr opaque types support) - #142938 (implement std::fs::set_permissions_nofollow on unix) - #144767 (Correct some grammar in integer documentation) - #144906 (Require approval from t-infra instead of t-release on tier bumps) - #144983 (Rehome 37 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`) - #145025 (run spellcheck as a tidy extra check in ci) - #145166 (suggest using `pub(crate)` for E0364) - #145255 (dec2flt: Provide more valid inputs examples) - #145306 (Add tracing to various miscellaneous functions) - #145336 (Hide docs for `core::unicode`) - #145429 (Couple of codegen_fn_attrs improvements) - #145452 (Do not strip binaries in bootstrap everytime if they are unchanged) - #145464 (Stabilize `const_pathbuf_osstring_new` feature) - #145474 (Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups) - #145486 (Fix `unicode_data.rs` mention message) - #145493 (remove `should_render` in `PrintAttribute` derive) - #145505 (Simplify span caches) - #145510 (Visit and print async_fut local for async drop.) - #145511 (Rust build fails on OpenBSD after using file_lock feature) - #145532 (resolve: debug for block module) - #145533 (Reorder `lto` options from most to least optimizing) - #145537 (Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.) - #145538 (bufreader::Buffer::backshift: don't move the uninit bytes) - #145542 (triagebot: Don't warn no-mentions on subtree updates) - #145549 (Update rust maintainers in openharmony.md) - #145550 (Avoid using `()` in `derive(From)` output.) - #145556 (Allow stability attributes on extern crates) - #145560 (Remove unused `PartialOrd`/`Ord` from bootstrap) - #145568 (ignore frontmatters in `TokenStream::new`) - #145571 (remove myself from some adhoc-groups and pings) - #145576 (Add change tracker entry for `--timings`) r? `@ghost` `@rustbot` modify labels: rollup
Discussed at https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Tier.201.20target.20promotion.20RFC.20FCP.20sign-offs/with/532735844.
I also changed "viability and value" to just "viability". I think that t-infra should decide whether it's viable to support a given target on our CI. The value should be determined by t-compiler.
r? @jieyouxu