gitlab merge request -> list patchbomb workflows

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

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.