Merge pull request #3998 from RalfJung/contrib
contributing guide: mention expectations around force pushes and squashing
This commit is contained in:
commit
d581d802b1
@ -13,6 +13,25 @@ for a list of Miri maintainers.
|
|||||||
|
|
||||||
[Rust Zulip]: https://rust-lang.zulipchat.com
|
[Rust Zulip]: https://rust-lang.zulipchat.com
|
||||||
|
|
||||||
|
### Pull review process
|
||||||
|
|
||||||
|
When you get a review, please take care of the requested changes in new commits. Do not amend
|
||||||
|
existing commits. Generally avoid force-pushing. The only time you should force push is when there
|
||||||
|
is a conflict with the master branch (in that case you should rebase across master, not merge), and
|
||||||
|
all the way at the end of the review process when the reviewer tells you that the PR is done and you
|
||||||
|
should squash the commits. For the latter case, use `git rebase --keep-base ...` to squash without
|
||||||
|
changing the base commit your PR branches off of. Use your own judgment and the reviewer's guidance
|
||||||
|
to decide whether the PR should be squashed into a single commit or multiple logically separate
|
||||||
|
commits. (All this is to work around the fact that Github is quite bad at dealing with force pushes
|
||||||
|
and does not support `git range-diff`. Maybe one day Github will be good at git and then life can
|
||||||
|
become easier.)
|
||||||
|
|
||||||
|
Most PRs bounce back and forth between the reviewer and the author several times, so it is good to
|
||||||
|
keep track of who is expected to take the next step. We are using the `S-waiting-for-review` and
|
||||||
|
`S-waiting-for-author` labels for that. If a reviewer asked you to do some changes and you think
|
||||||
|
they are all taken care of, post a comment saying `@rustbot ready` to mark a PR as ready for the
|
||||||
|
next round of review.
|
||||||
|
|
||||||
### Larger-scale contributions
|
### Larger-scale contributions
|
||||||
|
|
||||||
If you are thinking about making a larger-scale contribution -- in particular anything that needs
|
If you are thinking about making a larger-scale contribution -- in particular anything that needs
|
||||||
@ -45,14 +64,6 @@ process for such contributions:
|
|||||||
This process is largely informal, and its primary goal is to more clearly communicate expectations.
|
This process is largely informal, and its primary goal is to more clearly communicate expectations.
|
||||||
Please get in touch with us if you have any questions!
|
Please get in touch with us if you have any questions!
|
||||||
|
|
||||||
### Managing the review state
|
|
||||||
|
|
||||||
Most PRs bounce back and forth between the reviewer and the author several times, so it is good to
|
|
||||||
keep track of who is expected to take the next step. We are using the `S-waiting-for-review` and
|
|
||||||
`S-waiting-for-author` labels for that. If a reviewer asked you to do some changes and you think
|
|
||||||
they are all taken care of, post a comment saying `@rustbot ready` to mark a PR as ready for the
|
|
||||||
next round of review.
|
|
||||||
|
|
||||||
## Preparing the build environment
|
## Preparing the build environment
|
||||||
|
|
||||||
Miri heavily relies on internal and unstable rustc interfaces to execute MIR,
|
Miri heavily relies on internal and unstable rustc interfaces to execute MIR,
|
||||||
|
Loading…
Reference in New Issue
Block a user