Subject: Re: GCD005: Regular and efficient releases

From: Andreas Enge <[email-masked]>
Date: Fri, 13 Jun 2025 21:02:16 +0200

Hello Simon,

Am Thu, Jun 12, 2025 at 09:08:54PM +0200 schrieb Simon Tournier:
> Instead, I think we need two intermediary steps:
>  (1) Clarify what means being a member of a team.
>  (2) Clarify the branching model; especially how to deal with grafts.

these are definitely good points, and I like your suggestion of coupling
grafting with ungrafting commits on a separate (team) branch. But I do
not think these steps are necessary prerequisites to defining a release
process, but rather orthogonal.

> Until now, the bar was high.  Maybe, one way to release more often is to
> decrease the bar so it’s easier to pass it and then we can rise it up,
> by incremental improvements.  This is the section about Package Sets,
> Tiers and Release Artifacts.

I would also say that the GCD is part of that, or more precisely, of
defining a bar: The release team gets more concrete goals than just
"release" - personally, I think I could dare and try to get onto the
release team if this GCD (or a variant) gets adopted, while I would not
even know where to start in the current situation. Also, the goal is to
give some power to the release team to make unpopular decisions, which
people do not dare enough to take right now.

> If the primary Release Manager is not able to keep the commitment (busy
> by life, away from keyboard, unexpected event, etc.), then the secondary
> Release Manager takes the floor.  Right?  But then, this “absent”
> primary Release Manager, does they become the next secondary Release
> Manager?
> Moreover, what does it happen if the both Release Manager are not
> responding?  Do we delay the time to find two new Release Managers?  Or
> is it two of the other members?
> The other question: what does it happen if the Release Team is not able
> to fix a blocker?  Do we delay until the fix?  Do we drop the blocker?
> Who decides?  What is the process for making such decision?
> Who decides if 7 people volunteer to be the next release team?  Hum, it
> will not happen, but still. :-)

I think that your list of "what if" questions is not very helpful, as
ultimately not limited to this GCD, but quintessential to all efforts of
a group of volunteers. What happens if we find too many people wanting
to do the work? Well, I suppose we can work something out, like some of
them being on the first release team, and others on the next one. More
realistically, what happens if not enough people want to do the work?
As said above, part of the goal of this GCD is to lower the bar so that
more people are willing to contribute. For instance, you wonder who
would engage for twice 12 weeks. I think the situation is much worse
right now - someone who volunteers to "do a release" is up for an
unknown amount of work over some unknown time; doing something "time
based" and not "when it is ready" is supposed to lower the burden.
(As an example: "Request for merging core-packages-team branch" happened
five months ago, and we still do not see the end of it after about 20 weeks.)
What happens if nobody does the work, the release team does not respond?
Well then, we will not have a release, but that would not be different
from the current situation, would it?

Andreas