Re: QEMU Summit Minutes 2023

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Nov 28, 2023 at 06:54:42PM +0100, Cédric Le Goater wrote:
> On 11/21/23 18:11, Alex Bennée wrote:
> > Peter Maydell <peter.maydell@linaro.org> writes:
> > 
> > > QEMU Summit Minutes 2023
> > > ========================
> > > 
> > > As usual, we held a QEMU Summit meeting at KVM Forum.  This is an
> > > invite-only meeting for the most active maintainers and submaintainers
> > > in the project, and we discuss various project-wide issues, usually
> > > process stuff. We then post the minutes of the meeting to the list as
> > > a jumping off point for wider discussion and for those who weren't
> > > able to attend.
> > > 
> > <snip>
> > > 
> > > Topic 2: Are we happy with the email workflow?
> > > ==============================================
> > > 
> > > This was a topic to see if there was any consensus among maintainers
> > > about the long-term acceptability of sticking with email for patch
> > > submission and review -- in five years' time, if we're still doing it
> > > the same way, how would we feel about it?
> > > 
> > > One area where we did get consensus was that now that we're doing CI
> > > on gitlab we can change pull requests from maintainers from via-email
> > > to gitlab merge requests. This would hopefully mean that instead of
> > > the release-manager having to tell gitlab to do a merge and then
> > > reporting back the results of any CI failures, the maintainer
> > > could directly see the CI results and deal with fixing up failures
> > > and resubmitting without involving the release manager. (This
> > > may have the disbenefit that there isn't a single person any
> > > more who looks at all the CI results and gets a sense of whether
> > > particular test cases have pre-existing intermittent failures.)
> > 
> > If we are keen to start processing merge requests for the 9.0 release we
> > really should consider how it is going to work before we open up the
> > taps post 8.2-final going out.
> > 
> > Does anyone want to have a go at writing an updated process for
> > docs/devel/submitting-a-pull-request.rst (or I guess merge-request) so
> > we can discuss it and be ready early in the cycle? Ideally someone who
> > already has experience with the workflow with other gitlab hosted
> > projects.

If no one else beats me to it, I can try and write up something,
since I'm pretty familiar with gitlab PR from libvirt & other
projects.

> Reading the Topic 2 paragraph above, I understand that a maintainer
> of a subsystem would be able to merge its '-next' branch in the main
> repository when CI is all green. Correct ?

A maintainer would have their own fork of qemu-project/qemu, under
their namespace, or if there are maintainers collaborating, they
might have a separate group nmamespace for their subsystem.
eg qemu-block-subsys/qemu, or we could use sub-groups perhaps
so  qemu-project/block-subsys/qemu  for official subsystem
trees.

Anyway, when a maintainer wants to merge a tree, I would expect to
have a MR opened against 'master' in qemu-project/qemu.  The CI
ought to then run and if it is all green, then someone would approve
it to merge to master.

> It seems to me that we should also have a group of people approving
> the MR.

Yes, while we could have one designated gate keeper approving all
MRs, that would defeat some of the benefit of MRs. So likely would
be good to have a pool, and also setup the config so that the owner
of an MR is not allow to approve their own MR, to guarantee there
is always a 2nd pair of eyes as sanity check.

We might also need to consider enabling 'merge trains', so that
we get a serialized CI run again after hte MR is approved, in
case 'master' moved onwards since the initial CI pipeline when
the MR was opened.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|