On Thu, 2025-01-23 at 17:06:04 -0800, Otto Kekäläinen wrote:
Current https://dep-team.pages.debian.net/deps/dep14/ states that the
default Debian branch name is 'debian/latest':
In Debian this means that uploads to unstable and experimental should be prepared either in
the debian/latest branch or respectively in the debian/unstable and debian/experimental
branches.
...
The helper tools that do create those repositories should use a command like git symbolic-ref
HEAD refs/heads/debian/latest to update HEAD to point to the desired branch.
Within the omitted context, this seems clearly to me to be just an
example on how to point the HEAD to the default branch, and not a
declaration of what constitutes the default recommended branch in
that DEP.
I assume that this, and that debian/latest is the first item on the
alternative recommendations on that DEP, is the reason you have been
going around claiming debian/latest is the primary and recommended
default by the DEP (which does not seem correct), as a way to push for
this (which does not seem right), and where there is no consensus nor agreement. Even after being told so by multiple people, and where even
a recent comment in that direction on a thread you participated in
earlier, could be:
https://lists.debian.org/debian-devel/2024/08/msg00260.html
And where similar sustained objections to the naming and workflow have
been popping up every time this has been brought up.
I would be curious to hear why people are *not* adopting 'debian/latest'?
[ The following is heavily adapted from a comment from a Go team MR. ]
In the Debian context «latest» seems like a very confusing and ambiguous
term as its meaning imposes an ordering, and because while latest refers
to the most up-to-date or recent thing, when we are talking about software development and where multiple development branches are possible, the term
can be taken in absolute or relative terms. It could easily refer to the
latest changes in absolute time (which can also be either packaging
commits or upstream releases or snapshots), or it could refer to the
latest changes relative to a specific branch (say latest from sid or
latest from experimental, or say the latest upstream 5.x release when
upstream also has a devel branch or a 6.x branch or similar).
Because of the ambiguity of the term in this context, using debian/latest
does not generally make the development workflow obvious:
* If it is about latest in absolute terms, then if you ever need
concurrent sid and experimental development, then the debian/latest
branch would need to flip flop between these depending on which one
is the most recent (also most recent in packaging terms or upstream
terms?) at the time (which seems rather broken and a mess of history,
or it would become a misnomer). Or you coerce the development into a
single branch and declare that no uploads to sid can ever happen while
the branch is sitting on experimental (which seems rather bad?).
* If it is in relative terms, and:
- debian/latest always tracks for example the sid suite, and then
there is a debian/experimental branch with all recent activity,
then debian/latest can be easily argued is not the latest both in
relative nor absolute terms;
- so it seems that the workflow that makes a bit more sense for
debian/latest is to track either sid or experimental suites
(whatever is newer, again in what terms?) and then possibly have
a debian/sid branch to track changes in sid while debian/latest
is sitting on experimental (this can still be argued to be a
misnomer when the debian/sid branch contains newer commits, even
if it's sitting on an older version!). But then when debian/latest
is sitting on sid, then this either requires the overhead of
continuously merging changes from debian/latest back into
debian/sid to keep the branch alive, or to leave it as a dead
branch while debian/latest takes its role, which is also confusing
(because sid in the archive is always active, while packages in
experimental can get pruned).
The problem with that latter workflow is that, the usual flow into a
Debian stable release is through sid, and experimental tends to be used
for multiple purposes ranging from preparing upcoming work, either new
upstream development branches, or to stage some possibly disruptive
change, a transition or for NEW processing to not block sid, or for
short-lived discardable experimenting, etc. In addition sid does not necessarily have an ancestor relationship with experimental, the
histories can be decoupled, and the process of moving something from experimental requires human consideration and intervention, and it
might actually end up never happening, so there is no natural automatic
flow like from unstable to testing. And still the problem is that the debian/latest name does not imply any specific workflow, nor does the
DEP for this naming.
In a context where there is only ever a single line of development
(such as downstreams with no unstable/experimental package development branches), using a single «<vendor>/latest» makes way more sense. I
also think that there are going to be situations in Debian where
a «debian/latest»-style workflow might make sense from a workflow point
of view for some teams with specialized workflows (where upstream have
a predictable release cycle, or where you only ever commit safe and
releasable stuff but do not know beforehand what the next target suite
should be, for example) or for some people (there were some cases
presented in this and previous d-d threads) that think they will never
need experimental (which does not really seem future-proof, and then
debian/sid would work as well). So I think it makes sense to allow for
this (probably with a specified detailed workflow, but still with qualifications and explaining all the context-specific problems with
that workflow and naming), and AFAIUI these were the primary reasons «<vendor>/latest» was added (*not* as a preferred workflow or naming,
but as an acceptable alternative).
But unconditionally using a naming and workflow that lands people by
default into a branch potentially pointing to experimental content of
a random nature with who knows what kind of state present there, does
not really seem wise and looks like a very poor general default. Where users/developers should (in the most general case) be landing on the
sid branch which is what is targeted for the next stable release and
is what is always active, and not something potentially containing
stuff targeting experimental (if the debian/latest branch has to keep flip-flopping to honor its own name) with an unknown state that might
be blocking immediate uploads to sid. In the same way experimental
has a very low apt pin even if you add it, or you can think of this
also as if in unstable w/o any configuration «apt source something» automatically picked sid or experimental depending on whatever is
the latest (unpredictably either based on version or on freshness,
depending on the source package).
The usual upstream names main (or master, even with this one being
phased out) to designate the primary development branch are a bit
less problematic (because they do not impose an order), but then they
also do not unambiguously imply a specific workflow, when just looking
at the names. (For example I use main for non-native packaging where
that implies sid, and any experimental work is always in an experimental branch, so I guess I'll ponder about namespacing with debian/ and to
use debian/sid to make this more clear.)
This also ties into the upstream/latest naming which seems as
problematic. On one hand due to the same reasons debian/latest can be problematic, where following the upstream branch name makes more sense
to me (instead of latest); and on the other because the upstream
branches are really vendor specific, where debian/copyright
Files-Excluded and Files-Included control their contents, so not vendor-namespacing them by default seems also wrong. And thus, if
the upstream branches were vendor-namespaced that would also suddenly
make the upstreamvcs remote rename completely unnecessary, and would
get rid of people's objections to its apparent ugliness, which I think
is more a symptom and a gut feeling that there's something wrong with
the proposal being pushed.
So in summary, I think that in the Debian context the «<vendor>/latest», «upstream/latest» (and even «<vendor>/main») are confusing and ambiguous, or potentially not future-proof, and do not imply a specific workflow
just by looking at the name, and do not map clearly into the
sid/experimental dichotomy. Where an explicit debian/<suite> or debian/<codename> is always going to be in general the more obvious
(self documenting), consistent (matches the pattern of say
debian/bookworm), simpler workflow, which matches the Debian archive
and release cycles. And thus I strongly object to debian/latest being
so aggressively pushed as some kind of good general default and
preferred naming and workflow (which it is not even on the DEP!). But
to repeat, I think it's perfectly fine for teams/people that want to
use it because they have specialized needs or they prefer it for
whatever reason!
I also have a strong issue with the apparent effort to tilt the usage
numbers, and try to change all defaults, with phrasing such as
"not being modern" (?!), where I expect then the other namings and
workflows can then eventually be declared "old" or "wrong" and then
banned. Which does not seem very helpful, the consequence of which feels
like it will be to make people packaging more miserable. Instead of
proposing something and letting people adopt it if they think it's an improvement over what they currently use. :/
The DEP-14 has been around since November 2014 and one would think
that DDs would have adopted 'debian/latest' as the default branch and
git head now. Since 2020/2021 the whole 'master' was deprecated in
favor of 'main' by most git services and tools, yet 'master' is still
the most popular one in Debian.
Git is a great tool for collaboration. It is sad to see that in Debian
usage of git is stifled by simple things like people not agreeing to
use a common branch naming scheme despite there being a proposal for
10+ years now.
This has been pointed out else-thread, but just want to echo that the
way this is writing is rather misleading.
Thanks,
Guillem
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)