Proposed changes to merge request workflow

[Oleg Grenrus]

+1

On 9.10.2019 13.18, Matthew Pickering wrote:
> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs