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

On Fri, May 29, 2020 at 11:31:33AM -0600, Ariadne Conill wrote:
> 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
> 

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

Ariadne Conill <ariadne@dereferenced.org> wrote:
> Hello,

Hi,

> 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.

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