... | ... | @@ -17,11 +17,8 @@ Submitting a patch for incorporation into the tree is done by creating a *merge |
|
|
|
|
|
## 1. Merge Request Workflow
|
|
|
|
|
|
|
|
|
<!-- TODO: The label workflow needs to be implemented -->
|
|
|
|
|
|
1. If you are fixing a bug then have a look at [fixing bugs](working-conventions/fixing-bugs) else if you are adding a feature see [adding features](/working-conventions/adding-features).
|
|
|
1. **Open an MR:** see [opening a merge request](#2-opening-a-merge-request) below for the basics of opening an MR. Apply the ~"Blocked on Review" label when you believe the word is ready for code review.
|
|
|
1. **Open an MR:** see [opening a merge request](#2-opening-a-merge-request) below for the basics of opening an MR. Apply the ~"Blocked on Review" label when you believe the work is ready for code review.
|
|
|
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.
|
|
|
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 [review checklist](#5-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, and if it is ready, add the MR to the merge queue.
|
... | ... | |