Submitting a patch for incorporation into the tree is done by creating a merge request. The merge request serves as a place to conduct code review, collect continuous integration results, and eventually merge your patch.
Merge Request Workflow
- If you're fixing a bug then have a look at fixing bugs else if you're adding a feature see adding features.
- Open an MR: see merge request conventions and below for the basics of opening an MR.
- Triage can be performed by any developer including yourself (see MR triage protocol). This should be done within 1 day.
- Technical review reviewers will evaluate the concept and implementation of the patch and work with the contributor (that's you) to iterate as necessary. Reviewers can use the “Approve” button to indicate they are happy with the MR.
- Final Review: a maintainer will have a final look at the MR and add the MR to the merge queue.
- Post-merge cleanup: the contributor (that's you) should close and/or have a final look over the any related issues.
Opening a merge request
To open a merge request:
- Push your branch. You may push either to your fork or the primary ghc/ghc> project.
- Starting from the GHC GitLab project click on the Merge Requests link in the left navigational bar.
- Click on the green New Merge Request button on the top right corner of the Merge Requests page
- In the left drop-down of the Source branch pane select the project to which you pushed your branch.
- In the right drop-down of the Source branch pane select the name of your branch.
- Click on the green Compare branches and continue button.
- Give your merge request a title. Suffix with the issue number e.g "Fix some bug #12345"
- Write a description of your change. This should be ideally at very least a few sentences to help reviewers understand what you have done. If your change requires any changes to submodules, please be sure to include links to the upstream merge requests in your description.
- Click on the green Submit merge request button.
Working with your merge request
Your merge request shows you several panes information:
Top-most is the request's title and description. These can be edited by pressing the yellow
Edit button on the top-right corner of the page.
The next pane summarises your merge request, showing the the source and target branches.
The next pane shows the status of the merge request's continuous integration builds. If the build has failed you can click on the red X icon to see the build log.
At the bottom of the page is the code review interface, consisting of several tabs:
The Discussion tab shows a summary of the comments left on the change. This includes comments left in-line in the code, as well as those independent of the code.
The Commits tab lists the commits being proposed for merge. These may be clicked upon to restrict the diff to only changes made by that commit.
The Pipelines tab provides a more detailed overview on the state of the various continuous integration jobs associated with the merge request.
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.
Merging your merge request
We use GitLab's merge train functionality to automatically rebase and merge branches to
After your merge request has been reviewed and approved it can be added to the merge queue by pressing the "Start merge train" button:
As long as your MR satisfies the following, GitLab will batch your MR with other MRs and attempt to merge into
- Approved by a GHC developer
- Passing CI
- Has no merge conflicts with
master(see rebasing below)
Each batch is an MR and must pass CI, so you can expect GitLab to merge two or three batches per day.
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.