gitlab merge request -> list patchbomb workflows

gitlab merge request -> list patchbomb workflows

[Ian Jackson]

At Xen Summit we had another discussion about patch submission and
review workflows.

We agreed that it would be a nice idea to conduct another experiment
with gitlab MRs.  The previous experiment yielded negative results,
but we think we might be able to do better.

The shape of the experiment was roughly:

 * Some robot would convert a gitlab MR into a patchbomb and email
   it to the list.  (The From: line would be the MR submitter's
   gitlab profile email address.)

 * Patch review would be done in the usual way by email.  These emails
   would naturally end up in the MR submitter's mailbox.

 * We would initially conduct the experiment with internal submitters,
   and with short/simple patches.

Open questions that weren't answered at the time include:

 * How do we intend to track acked/reviewed status ?  I think
   patchwork can help with this, but if we keep the series simple
   perhaps this will be fine.

 * If a resubmission was needed, how would a v2 post be triggered ?
   I don't think we have a good answer to this.  I considered tha
   following possible ultimate possibilities:

     A. when you update the git branch after the v1 posting,
        the robot marks the MR as draft.  Repost happe ns when
        you mark the MR as ready for review

     B. the robot comments in the gitlab issue, and there is
        some @robot command to tell it to repost

   AFAICT there is no code anywhere that would do either of these.
   I suggest for now we do (B) manually with a human (probably, me)
   writing comments in the MR.

 * Who if anyone will fold acked-by/reviewed-by into commit messages

   We cannot sensibly ask someone using the gitlab MR UI to do this.
   Also avoiding this manual clerical work was one of the benefits we
   are hoping to achieve.

   I therefore suggest that we don't do this folding at all, and use
   patchwork's UI to review the status of a series.

Next steps:

I looked for a tool that would do the automatic patchbombing.  It
doesn't seem to exist.  For other reasons I now have a library that
can scan/inspect git{lab,hub} MRs.

For now I propose to write a simple tool which does the patchbomb, and
expect to run it by hand on our experimental MRs.

Comments?

Ian.

Re: gitlab merge request -> list patchbomb workflows

[Julien Grall]

Hi Ian,

On 09/07/2021 16:48, Ian Jackson wrote:
> At Xen Summit we had another discussion about patch submission and
> review workflows.
> 
> We agreed that it would be a nice idea to conduct another experiment
> with gitlab MRs.  The previous experiment yielded negative results,
> but we think we might be able to do better.
> 
> The shape of the experiment was roughly:
> 
>   * Some robot would convert a gitlab MR into a patchbomb and email
>     it to the list.  (The From: line would be the MR submitter's
>     gitlab profile email address.)
> 
>   * Patch review would be done in the usual way by email.  These emails
>     would naturally end up in the MR submitter's mailbox.
> 
>   * We would initially conduct the experiment with internal submitters,
>     and with short/simple patches.
> 
> Open questions that weren't answered at the time include:
> 
>   * How do we intend to track acked/reviewed status ?  I think
>     patchwork can help with this, but if we keep the series simple
>     perhaps this will be fine.
> 
>   * If a resubmission was needed, how would a v2 post be triggered ?
>     I don't think we have a good answer to this.  I considered tha
>     following possible ultimate possibilities:
> 
>       A. when you update the git branch after the v1 posting,
>          the robot marks the MR as draft.  Repost happe ns when
>          you mark the MR as ready for review
> 
>       B. the robot comments in the gitlab issue, and there is
>          some @robot command to tell it to repost
> 
>     AFAICT there is no code anywhere that would do either of these.
>     I suggest for now we do (B) manually with a human (probably, me)
>     writing comments in the MR.
> 
>   * Who if anyone will fold acked-by/reviewed-by into commit messages
> 
>     We cannot sensibly ask someone using the gitlab MR UI to do this.
>     Also avoiding this manual clerical work was one of the benefits we
>     are hoping to achieve.
> 
>     I therefore suggest that we don't do this folding at all, and use
>     patchwork's UI to review the status of a series.

I am not entirely sure if this is what you are looking for. However, I 
thought I would mention it.

I have recently started to use b4 [1] to fetch patches and collect tags 
from the mailing list. I am wondering if the tools could be extended to 
also allow a quick look through of the review "state" of each patch?

Cheers,

[1] 
https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation

-- 
Julien Grall

Re: gitlab merge request -> list patchbomb workflows

[Ian Jackson]

Julien Grall writes ("Re: gitlab merge request -> list patchbomb workflows"):
> I have recently started to use b4 [1] to fetch patches and collect tags 
> from the mailing list. I am wondering if the tools could be extended to 
> also allow a quick look through of the review "state" of each patch?

Cool.  That's interesting.  I need to think about it some more, but I
think this is a possible alternative to using patchwork for the
analysis task.

Also, if a robot wanted to post a v2 it could use b4 to fold the acks
etc. into the repost, without the submitter having to add them to the
git branch.

Ian.

Re: gitlab merge request -> list patchbomb workflows

[Stefano Stabellini]

On Fri, 9 Jul 2021, Ian Jackson wrote:
> Julien Grall writes ("Re: gitlab merge request -> list patchbomb workflows"):
> > I have recently started to use b4 [1] to fetch patches and collect tags 
> > from the mailing list. I am wondering if the tools could be extended to 
> > also allow a quick look through of the review "state" of each patch?
> 
> Cool.  That's interesting.  I need to think about it some more, but I
> think this is a possible alternative to using patchwork for the
> analysis task.
> 
> Also, if a robot wanted to post a v2 it could use b4 to fold the acks
> etc. into the repost, without the submitter having to add them to the
> git branch.

Hi Ian,

I think kernel.org is already working on the same feature, you might
want to ask Konstantin Ryabitsev about it.

Cheers,

Stefano