Proposed changes to merge request workflow

Matthew Pickering matthewtpickering at gmail.com
Wed Oct 9 10:18:02 UTC 2019


Sounds good in principal but I object to

>  Make it clear that it is the contributor's responsibility to identify reviewers for their merge requests.

Asking for reviews is one of the most frustrating parts of
contributing patches, even if you know who to ask! So I think the
maintainer's should be responsible for finding suitable and willing
reviewers.

Cheers,

Matt

On Tue, Oct 8, 2019 at 7:17 PM Ben Gamari <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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


More information about the ghc-devs mailing list