Re: gitlab merge request -> list patchbomb workflows

[Julien Grall <julien@xxxxxxx>]

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