Re: Suite branches
On Tue, Apr 22, 2025, at 7:31 PM, NoisyCoil wrote:
> Hi again,
>
> I opened a MR at [1] with a proposal for an initial implementation of
> debcargo-conf namespaces. By namespace I mean an identifier for a set of
> branches which must talk to each other, like the master and pending
> branches currently do for unstable/exp. The intention is of course to
> use these for suite branches. Each suite should have its own namespace.
so.. a namespace is a suite? why not call a spade a spade?
> The reason why I introduced a new configuration file (.dcc.conf) is we
> should have a per-branch source of truth for the branch naming scheme,
> so all scripts can use it. In theory one could compute the branch names
> from the current one's (e.g. if the current branch is master (resp.
> trixie/master) then the pending-release branches are called pending-*
> (resp. trixie/pending-*), and vice-versa). In practice
but wouldn't we have that anyway? if the branch is named XXX/pending-YYY,
then we know it's the pending branch for suite XXX for crate YYY, and the
corresponding main/master branch is XXX/latest (or XXX/master, or whatever
convention we settle on). if no suite-prefix is encoded in the branch name,
we know it's unstable.
> 1. the computation should still be centralized, i.e. provided by a
> single function to be sourced by the scripts instead of left to them, at
> which point one can as well hardcode the names,
this could still be the case, without hard-coding it in a file that needs
to have different contents per suite.
> 2. by harcoding the names we won't have to care about what we call the
> branches: we'll have the master ones and those managed by the scripts
> (like the pending release branches), and will still be able to name
> extra branches as we like.
this could also still be done, provided you prefix such branches with
the suite? e.g., trixie-backports/mr/update-foobar could trivially
still be mapped to use trixie-backports as suite, whereas a random
branch mr/update-foobar would need to be checked inside to know which
suite/branch it targets, so the proper convention is more useful for
humans without any downsides for scripts?
if we want to prevent confusion for existing names, a simple list of
allowed suite names (that can be synced/backported to all branches)
would cover that as well..
> I am not married to any of the ideas in the MR so please feel free to
> critique them and/or propose alternatives. Whatever works for keeping
> suites separate is fine.
I haven't looked in detail, but I think a simple var.sh.frag variable
that detects the target suite based on the currently checked out branch
should do basically all that is needed atm. for experimental we'd of
course want/need more helper if we do the one-branch-per-crate approach,
probably at least:
- sync experimental branch for $crate with unstable
- switch to experimental branch for $crate
- merge experimental changes to unstable for $crate
?
> [1] https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/894
Reply to: