Re: Proposed changes to the commit policy (#59513)

[Attila Lendvai]

> While I understand this “extra“ work is a burden, what would you suggest
> to reduce the number of broken packages? Because all the red circles in
> the dashboard [2] is a strong issue, IMHO.


some random 0.02 follows from a non-committer. i don't think this would be a 
lot of extra burden, but i'm not sure how this scales up to several committers.

with that in mind:

besides the `master` branch, i would introduce a number of consequtive branches 
called `staging1`..`staging4`.

the more "problematic" a commit is, the deeper it should land in the stack of 
the staging branches.

commits are "promoted" stage-by-stage from staging4 towards master. the deeper 
we are in the stack, the less frequently it happens, and in larger batches. a 
major releases means promoting staging4 all the way up to master.

master is manually fast-forwarded to `staging1` every few days/hours, after 
checking the CI. this should be done by a dedicated person/role/group.

when master is updated, then an immediate attempt should also be made to rebase 
the staging branches on top of the new master. when this rebasing requires 
substantial effort, then it should be abandoned, and whoever is responsible for 
the problematic commits should do the rebasing.

all the branches are built automatically by the CI, but there's a strict 
priority: e.g. `staging2` is only built when `staging1` has finished building, 
or when manually requested by a maintainer.

the staging branches may be force-pushed, but the closer they are to master, 
the less haphazardly it should happen. when a committer sees that a 
history-rewrite is in order, they should drop a mail to the committer mailing 
list informing the others, and a "done" reply when finished (this would work 
better on a communication channel where deleting not-anymore-relevant messages 
is possible).

---------

further details:

LTS (Long Term Support): depending on the available human resources, when a 
major release is made, a branch (and a channel) could be opened for that 
release. this branch would receive backported fixes on a best effort basis. 
users, who want to delay dealing with the API changes introduced by the major 
release, may decide to stick to this channel for a while.

in the new setup master is always fully covered by the substitute servers. in 
the current setup i often find myself locally building large packages like 
chromium, which is a regular headache to me as a user.

compared to the current setup, `staging1` would be a new branch; rename 
`staging` -> `staging2`; `core-updates` -> `staging3`. API changes should land 
in `staging4`, waiting there until a major release.

this naming scheme is more intuitive for newcomers, but it might also be more 
error prone in everyday routine work.

HTH,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“To be human is not a fact, but a task.”
        — Søren Kierkegaard (1813–1855), paraphrased