... | ... | @@ -74,6 +74,36 @@ The *Pipelines* tab provides a more detailed overview on the state of the variou |
|
|
|
|
|
Finally, the *Changes* tab shows the patch itself. This view may be restricted to changes made by a single commit by selecting the commit in the *Commits* tab. Moreover, one may view previous iterations of the merge request using the two drop-down menus at the top of the tab. To leave an inline comment click on a line in the patch.
|
|
|
|
|
|
|
|
|
## 4. Draft Status
|
|
|
|
|
|
You can mark a MR as "draft" or "work in progress" by beginning the title with the string `Draft:` or `WIP:`. (The two are equivalent.)
|
|
|
|
|
|
### 4.1 What does it mean for an MR to be marked as Draft?
|
|
|
|
|
|
* It signals that your MR is not ready for review; you are working on it. (Of course, you are free to ask someone for a review.)
|
|
|
* The automated merge system (marge-bot) will not merge a Draft MR into master.
|
|
|
* Maintainers are unlikely to fix CI issues, review or rebase such patches.
|
|
|
|
|
|
### 4.2 Why has someone changed my MR marked as Draft?
|
|
|
|
|
|
There are a number of reasons why an MR might be marked as draft by someone else:
|
|
|
|
|
|
* The patch has been reviewed and some aspect of it needs to be addressed by the author.
|
|
|
* The patch is causing tests to fail on CI which need to be addressed. Either by fixing the patch or accepting new test output.
|
|
|
* The patch needs outside input to proceed (ghc-proposal approval, clc-proposal approval, upstream changes, community feedback)
|
|
|
* The patch is still being worked on.
|
|
|
|
|
|
### 4.3 When should I remove "Draft" from my MR?
|
|
|
|
|
|
* If you want review or help on design and implementation aspects of your MR.
|
|
|
* If you think there are no remaining issues with your MR and it's ready to be merged into master.
|
|
|
* If CI fails but you suspect the failures are unrelated to the MR.
|
|
|
|
|
|
If you are in doubt it's **always ok to remove "Draft"**. A MR not marked ready might never be seen by a maintainer. So it's better to mark your MR as ready than not.
|
|
|
|
|
|
Worst case a maintainer will mark it as Draft again if they think it's up to you to make changes to the MR before moving forward.
|
|
|
|
|
|
### 4. Modifying the validation pipeline
|
|
|
|
|
|
By default we run a selected few jobs in each merge request on the most common platforms.
|
... | ... | @@ -106,3 +136,16 @@ Each batch is an MR of its own, which must itself pass CI. You can expect GitLab |
|
|
### 6. Rebasing
|
|
|
|
|
|
You generally do *not* need to rebase your MRs unless there are merge conflicts with `master`. GitLab will automatically rebase on top of `master` when batching MRs.
|
|
|
|
|
|
## 7. Backports
|
|
|
|
|
|
After a patch has made it to `master` it might be appropriate to backport it to the stable branch (e.g. `ghc-8.8`). If backporting is desired first ensure that the issue is milestoned for the next minor release and mark the merge request containing the fix with the appropriate "backport needed" label(s) (e.g. ~"backport needed:8.8").
|
|
|
|
|
|
While the release manager can perform the backport on your behalf, it is appreciated if you open a merge request with the backported patches yourself. There are two ways to backport a merge request:
|
|
|
|
|
|
* Via the web interface using the "Cherry-pick" button on the merged MR. While convenient, this is only possible if there are no merge conflicts with the stable branch. Be sure to **select the correct target branch**.
|
|
|
* Via the command-line using the `git cherry-pick` command. In this case select the appropriate "backport" template (e.g. `backport-for-ghc-8.8`) when creating your merge request.
|
|
|
|
|
|
After the merge request is created ensure it has the ~backport label applied and that its milestone is set appropriately.
|
|
|
|
|
|
Once the backport MR lands the ~"backport needed" label can be removed from the source MR. |