On Wed, Nov 29, 2023 at 8:33 AM Philippe Mathieu-Daudé <phi...@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
