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