Re: Suite branches
On 19/04/25 18:01, Fabian Grünbichler wrote:
for suite branches. My proposal (which already came up during the
meeting) is to use $SUITE -- e.g. trixie-backports -- for the suite's
master branch and $SUITE/pending-$CRATE for the pending branches.
that doesn't work, you can't have a branch `foo` and a branch `foo/bar`.
>
> we probably need to do
>
> $suite/latest
> $suite/pending-crate
>
> or a similar scheme?
Ah, you're right of course. I had avoided $SUITE/master to keep it
simpler, but I guess we'll have to choose between $SUITE/master,
$SUITE/latest or alternatives. I tend to prefer a uniform scheme such as
master + $SUITE/master, although I'm also happy to move on from "master"
as a default branch name, and in this regard $SUITE/latest or
$SUITE/main is a +1 for me.
As for experimental, I think yesterday we haven't decided if we want to
have a separate branch for it.
I think there's two variants that make sense:
- keep the current approach with unstable and experimental in one branch
- do a new branch*per crate* for experimental, that only contains the
experimental changes for that crate (e.g., experimental/$crate and
maybe experimental/pending-$crate)
-- this branch could be managed/checked/noticed by tooling
-- it can be merged back to the master one just like the pending branches
-- it can be reset to the unstable state if needed (previous experimental
changes abandonded, new experimental changes "branched" off)
I like the second one. I'd personally go with it. Experimental already
kind of is a scattered collection of packages, so it makes sense for
each package to have its separate branch when needed.
having one experimental and one unstable branch with constant cross
merging will lead to mistakes that are messy and hard to undo..
Agreed.
see above, but ack in principle besides that. do we only want to use this
for backports, or also for (potential) stable or stable-security updates?
Once we have a mechanism in place for general suite branches we can use
it however we want, and I think separate stable and stable-backports
branches is probably something we want to have (not entirely sure about
security). However, we should put some thought into how to coordinate
between the stable, stable-security and stable-backports branches, as
the situation for these is similar to that of unstable + exp. In
particular, while stable can have a life of its own, with
stable/pending-$CRATE branches being yet-to-be-accepted uploads to
stable-proposed-updates, it is unclear to me how stable-backports and
stable-security should interface with stable. In a certain way they are
similar to unstable + exp, with the exception that backports will never
be merged into stable. Also, the experimental approach will hardly work
since backporting a package often requires backporting many
dependencies, i.e. backports is not a scattered collection of packages
like exp often is.
when should we fork off those branches from master?
Fork off trixie as soon as most migration to testing requires manual
intervention? We can then fork off the other trixie branches from there.
That would be 10 days before the hard freeze, I think? IIUC packages
with autopkgtests can still migrate automatically after that, but
migration time is increased to 20 days so a package with autopkgtests
uploaded 9 days before the hard freeze will only migrate to testing 11
days after the hard freeze. Please double-check this calculation, but I
think this means that by forking trixie 10 days before the freeze we'll
make sure nothing else gets into trixie automatically for about 3 weeks
after that. Everything that gets in afterwards, that is, during the last
20 days of the hard freeze, must be pushed back to the forked-off branch
manually (and the maintainer be publicly shamed unless they had a good
reason for their late upload).
Reply to: