On Apr 30, 2019 7:38 PM, "Peter Maydell" <peter.mayd...@linaro.org> 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 >
