Hi Andreas, On Fri, 13 Jun 2025 at 21:02, Andreas Enge <andr...@enge.fr> wrote: > 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. Yes I agree it’s orthogonal, but still a requirement if we want that this proposal becomes actionable (have regular releases, concretely). Let stretch a bit the picture. :-) Today, each team updates their scope and they do independently of the others. The result: it’s almost impossible to follow and being able to stabilize. And stabilizing is another word for releasing. :-) Before, it was small enough to say: Ok, although we still have a stream of changes, the people who wanted to release fixed themselves the remaining issues. Today, that’s almost impossible to “fix themselves” considering the volume. That’s one of the reason why we are so reluctant to jump in the release process over the past two and half year. If before entering the 12 weeks Release Period and the Teams have not polished their state, then we will burn out. IMHO, the success to be able to release once a year every year is mainly conditioned by the policies we have on the Teams. Obviously, we can first define the Release part and then define the Teams. The former seems a great motivation for the later. :-) To say it explicitly, I think this GCD 005 can only be actionable if it comes with another companion GCD about the Teams. So yes I agree it’s orthogonal, but still a requirement, IMHO. :-) > I think that your list of "what if" questions is not very helpful What I want to raise is that “regular” implies to reduce the “improvisation”, kind of. Again, 12 weeks (3 months) of continuous commitment is something. And it appears to me better to have beforehand some “rules“ in case it’s not smooth as expected. Else it will not be regular, IMHO. What I would like to clarify is what are the “duties” beforehand and how we act if they are fulfilled – no big deal – it’s only to avoid the situations where “we do not know” and try to figure out something. To me, if we want to have something regular, we should reduce the cases where we have to think about theses unexpected corner cases, because when trying to figure out, the real work is not done. Somehow. :-) Cheers, simon
