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

[Aleksandar Markovic]

On Apr 30, 2019 7:38 PM, "Peter Maydell" <address@hidden> wrote:
>
> 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) ?
>

I think I could successfully undertake majority of the tasks you mentioned
(l am not certain on build tests only, since I most probably donˊt have the
test equipment that is versatile enough and I am not sure how Github CI
works).

In any case, I admire your handling this heavy burden so far, and wish we
continue making QEMU better every year.

Sincerely,
Aleksandar

> thanks
> -- PMM
>