Re: QEMU Summit Minutes 2023

[Daniel P . Berrangé]

On Tue, Nov 28, 2023 at 06:05:25PM +0000, Peter Maydell wrote:
> On Tue, 28 Nov 2023 at 17:54, Cédric Le Goater <clg@redhat.com> wrote:
> >
> > On 11/21/23 18:11, Alex Bennée wrote:
> > > Peter Maydell <peter.maydell@linaro.org> writes:
> > >> 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.
> >
> >
> > 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 ?
> 
> I think my intention when writing that was to say that the submaintainer
> kicks things off and deals with resubmitting and rerunning if there
> are failures, but actually doing "merge this successfully tested
> pullreq" is still the release-manager's job.
> 
> > It seems to me that we should also have a group of people approving
> > the MR.
> 
> I do think something like this is probably where we want to get to
> eventually, where there's a group of people with the rights to
> approve a merge, and maybe the rules about how many approvals
> or whose approval is needed can differ between "normal development"
> and "in freeze" periods. But the idea of the above text I think
> was that the first step is to change from how the release manager
> receives "please merge this" requests from the current "here's an
> email, you need to test it" to "here's a thing in the gitlab UI
> that has already passed the tests and is ready to go".

If we setup ACL rules to require the release manager only to
start with, it is easy enough to expand the ACL rules later
once we're comfortable with more people doing the work.


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 :|