-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Require approval from t-infra instead of t-release on tier bumps #144906
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks good to me. I would like a compiler lead to sign-off, since it's technically a change in how we do Tier 1 target promotions.
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? |
@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 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".) |
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