... | ... | @@ -27,7 +27,7 @@ Submitting a patch for incorporation into the tree is done by creating a *merge |
|
|
<!-- * ~"MR::2-under review" label is set by the developer that performed the triage. -->
|
|
|
1. **Technical review** reviewers will evaluate the concept and implementation of the patch and work with the contributor (that's you) to iterate as necessary. At this stage, additional changes are best made as separate commits, for ease of reviewing. Reviewers can use the “Approve” button to indicate they are happy with the MR.
|
|
|
<!-- * ~"MR::3-ready for merge" label is set by the contributor (that's you) once reviewers and contributor are satisfied with the MR. -->
|
|
|
1. **Squash and rebase:** squash all your work-in-progress commits into a single commit with an informative commit message. (Occasionally your MR deals with more than one issue, in which case multiple commits may be appropriate, but the common case is a single commit.) Check that you have followed the [merge request guidance](https://gitlab.haskell.org/ghc/ghc/-/wikis/gitlab/merge-requests#review-checklist).
|
|
|
1. **Squash and rebase:** squash all your work-in-progress commits into a single commit with an informative commit message, and rebase on master. (Occasionally your MR deals with more than one issue, in which case multiple commits may be appropriate, but the common case is a single commit.) Check that you have followed the [merge request guidance](https://gitlab.haskell.org/ghc/ghc/-/wikis/gitlab/merge-requests#review-checklist).
|
|
|
1. **Final review:** a member of [the GHC Team](https://gitlab.haskell.org/ghc/ghc-hq#2-the-ghc-team) will have a final look at the MR. If this is the case, a the GHC Team member will add the MR to the merge queue.
|
|
|
<!-- * ~"MR::4-in merge queue" label is set by the maintainer. -->
|
|
|
1. **Post-merge cleanup:** the contributor (that's you) should close and/or have a final look over the any related issues.
|
... | ... | |