[Qemu-devel] Spreading the load on QEMU pullreq handling and release work

[Peter Maydell]

For most releases in the past five years, I've been handling the
work of applying pull requests, tagging release candidates, and
so on. (For one or two releases somebody else has done this when
I've been off on holiday.) This takes up a fair chunk of my time
during the actual "release" phase of a cycle, and it also
represents a "bus factor" issue for the project if I'm the only
person doing this. I'd like to try to spread this work out a bit
between more people.

Specifically, where I'd like to get to is that we have a rota of
three people doing this, which at our "three releases a year"
pace means any one person only has to handle one release cycle
a year.

Part of this move is going to require moving away from some of the
ad-hoc scripting and testing that I currently do on a selection of
personal and work machines and instead using machines that can be
used by other project members.  (One recent suggestion is that
perhaps the gitlab CI might be a useful place to start, since it
allows us to provide custom build workers rather than only doing
x86 host testing.)

For the moment I'd like to ask for in-principle volunteers
to be on the release-handling rota.

The work involves:
 * the mechanical process of actually processing pullreq
   emails and applying them
 * letting people know about failures, which can mean some
   investigation of exactly why something has failed to
   distinguish problems with the pull from preexisting
   intermittent failures from infrastructure issues
 * more careful by-hand scrutiny of pull requests from
   submaintainers who haven't done it before or who don't make
   pull requests often (checking for missing signoffs, weirdly
   malformed pull requests, patches that shouldn't be in the
   pull, etc)
 * maintenance of what I guess will need to be a shared
   project GPG keyring to add submaintainer keys (there's
   a judgement call required for whether a new key is
   sufficiently trusted, working with the submaintainer to
   ask them to try to get more signatures if possible, etc)
 * curating the "Planning" wiki page where we record things
   not yet fixed in the current release, including chasing
   people for fixes for RC bugs, asking around if anything
   ought to go in, tracking potential RC issues that crop up
   on the mailing list, etc
 * making sure we correctly raise the "is this important
   enough to go in" bar for pull requests during the release
   candidate phase by scrutinizing pull requests and if
   necessary pushing back on submaintainers
 * likely some other things I have forgotten

Since there is a definite human judgement required here, this
isn't going to be a fully automatable process[*], and it would
be best done by people who've got a reasonably long history of
working with the project (both from a trust perspective and
because they have the experience to make the judgement calls
required).

[*] It could quite possibly be automated a bit more than I
currently do it, though. I'm also open to the idea that maybe we
should do less gatekeeping at the apply-pull stage and instead
delegate to submaintainers to make the right judgements, though
in my experience there is usually at least one pullreq
submitted late in the rc process which has stuff in it that
should not go in at that point...

NB: at the moment there is a split in handling of release
candidates and the release, where I do the tagging of an rc in
git, and Michael Roth then rolls tarballs and makes
announcements of the rc or final release. Michael -- is that
work something you'd like to spread around between more people
or are you happy to continue to do it all?

So, any volunteers (from anybody, not just people on the cc list) ?

thanks
-- PMM