qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QEMU Summit Minutes 2023


From: Cédric Le Goater
Subject: Re: QEMU Summit Minutes 2023
Date: Tue, 28 Nov 2023 18:54:42 +0100
User-agent: Mozilla Thunderbird

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.


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 ?

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

Thanks,

C.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]