Re: WIP flag for merge requests

[Agustín Benito Bethencourt <agustin benito codethink co uk>]

Hi,

On Tuesday, 17 July 2018 11:21:22 PDT Agustín Benito Bethencourt via 
Buildstream-list wrote:
> Hi,
>
> On Tuesday, 17 July 2018 03:25:03 PDT Jim MacArthur via Buildstream-list
>
> wrote:
> > Our current use of the 'WIP' flag - which so far as I can tell hasn't
> > been documented on the mailing list - differs from the description in
> > HACKING.rst.
> >
> > Codethink have been using this flag to indicate that a merge request is
> > ready for general review and not for maintainer review. After an initial
> > review the WIP flag would be removed which signaled that it was ready
> > for a more formal review. We started using this two-stage review process
> > to try and reduce the load on Tristan Van Berkom.
> >
> > However, HACKING.rst, says "Merge requests that are not yet ready for
> > review must be prefixed with the WIP: identifier."
> >
> > It's also been suggested that things not ready for review should not be
> > made into a merge request.
> >
> > HACKING.rst should reflect the actual procedure - what should it be?
>
> Thanks for highlighting this topic. I have it in my ToDo but we ended up not
> discussing Gitlab related topics in the BoFs.
>
> I think the contrary. The current usage of MR can be improved in order to
> reduce the management overhead of those doing code review.
>
> I will talk to Tristan to find a solution but the name of a MR should not be
> the ultimate solution. In order to change the state of an item, Gitlab
> provides labels and workflows so filtering becomes easier and MR names do
> not need to be changes.
>
> I will propose a solution late next week if everything goes as planned.

Please watch this issue if you are interested on this topic: https://
gitlab.com/BuildStream/nosoftware/alignment/issues/5

Best Regards
-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html