On Wed, Nov 29, 2023 at 08:50:06AM -0700, Warner Losh wrote: > On Wed, Nov 29, 2023 at 8:44 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > 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.mayd...@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. > > > > I'd honestly optimize for 'frequent merges of smaller things' rather than > 'infrequent merges of larger things'. The latter has caused most of the > issues for me. It's harder to contribute because the overhead of doing so > is so large you want to batch everything. Let's not optimize for that > workaround for the high-friction submission process we have now. If there's > always smaller bits of work going in all the time, you'll find few commit > races... though the CI pipeline is rather large, so having a ci-staging > branch to land the MRs to that have completed CI, but not CI on the tip, > might not be bad... but the resolution of conflicts can be tricky, though > infrequent, so if a ci-staging branch bounces, all MRs would need to be > manually requeued after humans look at why and think through who needs to > talk to whom, or if it's just a 'other things landed before you could get > yours in and it's not the ci-staging being full of other people's commits > that is at fault.
I agree. Right now we tend to have fairly large pull requests, because people are concious of each pull request consuming non-trivial resources from the release maintainer. If this new MR based approach reduces the load on the release maintainer, then sending frequent small pull requests is almost certainly going to be better. 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 :|
