Proposed changes to merge request workflow

Richard Eisenberg rae at richarde.dev
Tue Oct 8 21:28:29 UTC 2019


+1 from me.

> On Oct 8, 2019, at 7:19 PM, Shayne Fletcher via ghc-devs <ghc-devs at haskell.org> wrote:
> 
> All sounds very sensible to me.
> 
> On Tue, Oct 8, 2019 at 2:17 PM Ben Gamari <ben at well-typed.com <mailto:ben at well-typed.com>> 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] https://gitlab.haskell.org/ghc/ghc/wikis/proposals/merge-request-workflow <https://gitlab.haskell.org/ghc/ghc/wikis/proposals/merge-request-workflow>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> 
> 
> -- 
> Shayne Fletcher
> Language Engineer / +1 917 699 7663
> Digital Asset <https://digitalasset.com/>, creators of DAML <https://daml.com/>
> 
> 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 http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message._______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20191008/de5c3513/attachment-0001.html>


More information about the ghc-devs mailing list