Re: QEMU Summit Minutes 2023

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]

On Wed, Nov 29, 2023 at 8:33 AM Philippe Mathieu-Daudé <philmd@linaro.org>
wrote:

> On 28/11/23 19:06, Daniel P. Berrangé wrote:
> > On Tue, Nov 28, 2023 at 06:54:42PM +0100, Cédric Le Goater wrote:
>
> > 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.
>
> Are all our tests already on GitLab? Last time I remember Peter still
> had manual tests.
>

As a low-volume maintainer, I'd love nothing more than to push my PR
asynchronously to the release cycle. I'll get immediate yes/no feedback and
have a chance to fix the 'no' from the CI and/or reviewers. I'd know early
in the review when CI tests break that I can deal with in parallel. All as
part of the normal process. Now I have to publish in email, and push to
gitlab and it's very manual, not integrated and a large source of friction
for me as someone who does things from time to time rather than all the
time (since it's the most radically different set or processes from
anything else I contribute to). This way, I don't have to care about
freezes or whatever. During the non-freeze times it goes in once whatever
criteria are ticked (reviewers and no objections, my say so, CI working,
etc) During the freeze times the release engineer ticks another box for it
to go in... or not... and after the freeze, we'll have a battle royale of
accumulated MRs that will go in, though not all queued once since we'll
have to re-run the CI with the new changes.

And maybe we could consider just branching for release. Freeze master for
as long as it takes to branch (which needn't be tip) and then master goes
on with life and the release engineer lands bug fixes to the release branch
like we do now in frozen master. That way we don't get the big in-rush
effects when the freeze lifts. FreeBSD went to this a decade ago and makes
releases so much easier.

Warner

[-- Attachment #2: Type: text/html, Size: 2979 bytes --]