Subject: release qualification process

From: Ariadne Conill <[email-masked]>
Date: Fri, 29 May 2020 11:31:33 -0600

Hello,

In the process of releasing Alpine 3.12, it was observed that the s390x 
machines had not built any of the RCs and were in fact behind by 22 days.  
This has caused some turbulence in releasing Alpine 3.12, as we are now 
waiting on the s390x builder to catch up.

I would like to propose an update to our release qualification process that 
should resolve this problem: each architecture has a designated release 
manager, and each release manager gives a go/no-go before the release process 
is initiated with a git tag.  In the event that a release manager gives a no-
go for an architecture, the release may either be delayed or the architecture 
not included in the release, depending on the situation.  The core team (or 
its designated replacement) may also issue a no-go for a specific architecture.

Thoughts?

Ariadne

---

From: Kevin Daudt <[email-masked]>
Date: Fri, 29 May 2020 21:33:41 +0200

> its designated replacement) may also issue a no-go for a specific architecture.

Hi,

I think something needs to improve, but I wonder how this will work in
practice. The release manager would need to be someone involved with
that specific platform and also sufficiently involved in the project (I
guess having access to main would probably necessary).

Otherwise it would only be an administrative role without any real
benefit, that turns up just twice per year when we do a release.

I feel that for most platforms, this person would end up being ncopa
anyway, so not a lot would change.

But we have to start somewhere, otherwise we will be stuck in the same
situation forever.

Kevin

---

From: Sören Tempel <[email-masked]>
Date: Sat, 30 May 2020 11:11:42 +0200

Hi,

> its designated replacement) may also issue a no-go for a specific architecture.

In general, it would be convenient to have an individual or a group of
individuals "responsible" for a specific architecture. For instance, if
tests for an aport fail on a specific architecture one can contact the
individual(s) responsible for this architecture for further
investigation. Given the amount of architectures we currently support, I
occasionally run into issues on architecture I do not have direct access
to (e.g. s390x) without any means of debugging the issue. The
individual(s) could also be responsible for overseeing the release
process on this architecture.

Greetings,
Sören