> 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
