Proposed changes to merge request workflow

Shayne Fletcher shayne.fletcher at
Tue Oct 8 18:19:23 UTC 2019

All sounds very sensible to me.

On Tue, Oct 8, 2019 at 2:17 PM Ben Gamari <ben at> wrote:

> tl;dr. I would like feedback on a few proposed changes [1] to our merge
>        request workflow.
> Hello everyone,
> Over the past six months I have been monitoring the operation of our
> merge request workflow, which arose rather organically in the wake of
> the initial move to GitLab. While it works reasonably well, there is
> clearly room for improvement:
>   * we have no formal way to track the status of in-flight merge
>     requests (e.g. for authors to mark an MR as ready for review or
>     reviewers to mark work as ready for merge)
>   * merge requests still at times languish without review
>   * the backport protocol is somewhat error prone and requires a great
>     deal of attention to ensure that patches don't slip through the
>     cracks
>   * there is no technical mechanism to prevent that under-reviewed
>     patches from being merged (either intentionally or otherwise) to
>     `master`
> To address this I propose [1] a few changes to our workflow:
>   1. Define explicit phases of the merge request lifecycle,
>      systematically identified with labels. This will help to make it
>      clear who is responsible for a merge request at every stage of its
>      lifecycle.
>   2. Make it clear that it is the contributor's responsibility to
>      identify reviewers for their merge requests.
>   3. Institute a final pre-merge sanity check to ensure that
>      patches are adequately reviewed, documented, tested, and have had
>      their ticket and MR metadata updated.
> Note that this is merely a proposal; I am actively seeking input from
> the developer community. Do let me know what you think.
> Cheers,
> - Ben
> [1]
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

*Shayne Fletcher*
Language Engineer */* +1 917 699 7663
*Digital Asset* <>, creators of *DAML

This message, and any attachments, is for the intended recipient(s) only, 
may contain information that is privileged, confidential and/or proprietary 
and subject to important terms and conditions available at 
<>. If you are not the 
intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list