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

[Attila Lendvai <attila@lendvai.name>]

> 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