Re: Can we enforce beta release for the freeze

[Emmanuele Bassi <ebassi gmail com>]

On Mon, 22 Feb 2021 at 00:20, Shaun McCance <shaunm gnome org> wrote:

 

What I want is a discussion on how we can ensure beta releases happen in the future. For example, can we do more to automate releases? Or (again, for example), could we have an automated script that emails this list with modules missing beta releases? Then even if releases are missed, people like me would at least know what to expect from the beta.

"Automating releases" is a vast topic.

In theory, we could simply ask maintainers to upload a (signed) tag to GitLab, and then our tools would be able to deal with that—of course, that requires some process change and some tool change from the release team perspective, but we've been trying to get towards that goal for a while now. That would get rid of the "upload a dist tarball to gnome.org" step, which is, frankly, the least involved step. We'd still require maintainers to run dist as part of the release checklist because otherwise how are they going to tag a release in the first place?

Of course, we *should* also rely on CI to ensure that a `dist` operation always passes on the main development branch; it would be good to have a project-wide CI rule that runs the dist on a schedule, but maintainers can do this *today* in their projects.

In the end, though, releases are manual labour; only the maintainer can say: "okay, this is good enough for other people to use" (where "people" defines different audiences depending on the stage of the development cycle). No amount of automation is going to solve that because if it did we would not need per-project maintainers in the first place, and we would only need people reviewing code and pressing the "Merge" green button.

The delay on this beta release was caused by the fact that we have a shortage of maintainers, and too few people in key positions. This issue can only be solved by having redundancies in the *human* pipeline. Maintainers: *please*, mentor contributors to pick up the release process. Document what you do, and give out release duties to other people at least once per cycle, if you can.

The release team can do "non maintainer" releases, of course; the problem is, of course, that maintainers can be *very* protective of their fiefdoms, so the release team has to wait for either being explicitly asked to do a release, or for an answer from maintainers as to whether they'll be able to do a release. We *cannot* have it both ways: either the release team can take over your project for a specific task—do a release, keep the build running—or we have to wait until we get an answer from the maintainer.

Ciao,

 Emmanuele.

--

https://www.bassi.io
[@] ebassi [@gmail.com]