-
Notifications
You must be signed in to change notification settings - Fork 170
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
Update review policy #553
base: master
Are you sure you want to change the base?
Update review policy #553
Conversation
@Mark-Simulacrum, where would you like this to be added? Do you want to draft the concrete text? |
@nagisa, do you want to elaborate on that? |
The official guidelines are [here][whats-a-major-change]. | ||
When in doubt, err on side of treating something as a major change. | ||
You can also nominate the PR for discussion in the compiler team's triage meeting by tagging it `I-nominated`. | ||
If you nominate a PR please make sure to state a concrete question for the compiler team to discuss. |
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.
@pnkfelix, you signaled that you wanted to discuss the wording of this paragraph.
(rust-lang/highfive#350 has been merged) |
Little late to the discussion here, updated review policy looks good to me, but wanted to suggest another edge case that we should document in our review policy: a pull request which makes changes to support the use of rustc internals for some external project - these aren't common but I've seen it happen a few times - do we accept these changes if they're small and otherwise improvements, do we reject these unless it's a mature and released project, etc? |
I think we should allow changes making things public, cleaning up things or making them more general, as long as the owners of the compiler region agree (so just assign to them). As a concrete example: if someone is using the mir interpreter, and they want to make something public, it is likely not a problem, but there are some functions that are module- or crate-private on purpose, as they uphold invariants within the mir interpreter. So basically, just assign such PRs to the relevant people (usually they get pinged anyway due to having told highfive that they want to get pinged on changes to these parts) |
@michaelwoerister I know it's been a while, are you still interested in working on this? I'm not clear if this was waiting for more updates or reviews, or if it is ready to go as-is. |
Oh my, that was never merged, was it? Sorry for not following up! I'll look into getting this over the finish line. |
449cc37
to
e054722
Compare
@wesleywiser & @davidtwco, I think the outstanding questions have been addressed (see the final two commits). I don't think there are any major changes compared to when the document was discussed originally, so I think we could merge the PR in the current state. I did not add the point @davidtwco made in #553 (comment). I'd be happy to if I can get some help with what the actual text should look like. |
Discussing this was proposed in: rust-lang/compiler-team#444. The actual discussion took place on zulip.
@rust-lang/compiler-contributors: Please leave comments about anything that you'd still like to have discussed.