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
