... | ... | @@ -21,18 +21,16 @@ Submitting a patch for incorporation into the tree is done by creating a *merge |
|
|
<!-- 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 [merge request conventions](/gitlab/merge-requests) and [below](#opening-a-merge-request) for the basics of opening an MR.
|
|
|
<!-- * ~"MR::1-needs triage" label is set automatically. -->
|
|
|
1. **Triage** can be performed by any developer including yourself (see [MR triage protocol](/gitlab/merge-requests#triage-protocol)). This should be done within 1 day.
|
|
|
<!-- * ~"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.
|
|
|
1. **Open an MR:** see [opening a merge request](#2-opening-a-merge-request) below for the basics of opening an MR.
|
|
|
<!-- * ~"MR::1-needs triage" label is set automatically. --> <!-- 1. **Triage** can be performed by any developer including yourself (see [MR triage protocol](/gitlab/merge-requests#triage-protocol)). This should be done within 1 day. --> <!-- * ~"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, 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.
|
|
|
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.
|
|
|
<!-- * ~"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.
|
|
|
|
|
|
If you are blocked waiting at any stage then please apply the ~"Blocked on Review" label to draw attention to the MR.
|
|
|
If you are blocked waiting at any stage then please apply the ~"Blocked on Review" label and leave a comment mentioning @triagers to draw attention to the MR.
|
|
|
|
|
|
## 2. Opening a merge request
|
|
|
|
... | ... | @@ -104,7 +102,30 @@ If you are in doubt it's **always ok to remove "Draft"**. A MR not marked ready |
|
|
|
|
|
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.
|
|
|
|
|
|
## 5. Modifying the validation pipeline
|
|
|
## 5. Review checklist
|
|
|
|
|
|
See the [merge request description template](https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/merge_request_templates/Default.md) for a checklist of requirements for a merge request.
|
|
|
|
|
|
When reviewing a merge request here are a few things to check for:
|
|
|
|
|
|
* Have you followed GHC's [coding style guidelines](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/coding-style), and especially have you added [suitable `Notes`s](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/coding-style#2-using-notes)?
|
|
|
* Are the commits logically structure? Are their commit messages descriptive?
|
|
|
* Are ticket numbers referenced as appropriate?
|
|
|
* Is a GHC release notes entry included (e.g. `docs/users_guide/*-notes.rst`)?
|
|
|
* Have changelog entries been added to any changed packages (e.g. `libraries/*/changelog.md`)?
|
|
|
* Has a test case been added?
|
|
|
* Milestone and ~"backport needed" label set as appropriate
|
|
|
* Does the patch change the language accepted by GHC or add a significant new user-facing feature? If so perhaps a [GHC proposal](https://github.com/ghc-proposals/ghc-proposals) is in order.
|
|
|
* Does the patch change GHC's core libraries (e.g. `base`, `template-haskell`)? If so:
|
|
|
* Has the [Core Libraries Committee](https://github.com/haskell/core-libraries-committee) consented to any changes to `base` (directly or due to changing a definition that `base` re-exports)?
|
|
|
* Has the ~"user-facing" label been applied? After applying that label, has the [head.hackage job](https://gitlab.haskell.org/ghc/head.hackage/) been run to characterise the effect of the change on user code?
|
|
|
* Changelog and release notes entries are mandatory
|
|
|
* Have package versions been bumped as appropriate?
|
|
|
* Has an entry been added to the next release's [migration guide](../migration)?
|
|
|
|
|
|
To ensure that all interested reviewers have an opportunity to comment, please leave at least 24 hours between the time an MR is opened and assigning to @marge-bot.
|
|
|
|
|
|
## 6. Modifying the validation pipeline
|
|
|
|
|
|
By default we run a selected few jobs in each merge request on the most common platforms.
|
|
|
|
... | ... | @@ -120,10 +141,10 @@ You can use *labels* to modify the configurations which are tested on a merge re |
|
|
|
|
|
You apply a label using the "Labels" button in the right hand column.
|
|
|
|
|
|
## 6. Merging your merge request
|
|
|
## 7. Merging your merge request
|
|
|
|
|
|
We use @marge-bot to automatically rebase and merge branches to `master`.
|
|
|
After your merge request has been reviewed and approved, you can request that it be added to the merge queue by @-mentioning @reviewers. Your MR should be added to the merge queue within a day or two, assuming it passes CI and the commit history is in order (individually buildable commits with informative commit messages).
|
|
|
After your merge request has been reviewed and approved, you can request that it be added to the merge queue by @-mentioning @triagers. Your MR should be added to the merge queue within a day or two, assuming it passes CI and the commit history is in order (individually buildable commits with informative commit messages).
|
|
|
|
|
|
As long as your MR satisfies the following, GitLab will batch your MR with other MRs and attempt to merge into `master`:
|
|
|
|
... | ... | @@ -133,13 +154,13 @@ As long as your MR satisfies the following, GitLab will batch your MR with other |
|
|
|
|
|
Each batch is an MR of its own, which must itself pass CI. You can expect GitLab to merge two or three batches per day.
|
|
|
|
|
|
### 7. Rebasing
|
|
|
## 8. 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.
|
|
|
|
|
|
## 8. Backports
|
|
|
## 9. 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").
|
|
|
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:9.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:
|
|
|
|
... | ... | |