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
