DEP-14: Default branch name 'debian/latest' objections?

[Otto Kekäläinen]

Hi!

Current https://dep-team.pages.debian.net/deps/dep14/ states that the

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.

I would be curious to hear why people are *not* adopting 'debian/latest'?

Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?

Is it simply because git-buildpackage does not to default to 'debian/latest'?


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.

[Marco d'Itri]

Post by Otto Kekäläinen
I would be curious to hear why people are *not* adopting 'debian/latest'?
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?

Because it works fine and it is the most commonly used branch name for
development. It is also shorter, which is nice.

Post by Otto Kekäläinen
Is it simply because git-buildpackage does not to default to 'debian/latest'?

No, I am happy to change other gbp defaults.

Post by Otto Kekäläinen
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.

Clearly not deprecated enough...
Hence the real question here is: why do you think that "the majority of
Debian packages" should change the branch name that they are currently
using instead of you accepting it for your proposed standard?
I think that this is the core issue with DEP-14.

Post by Otto Kekäläinen
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.

It is not obvious at all to me how this would be stifling usage of git
in Debian.

[Sam Hartman]

Otto> I would be curious to hear why people are *not* adopting
Otto> 'debian/latest'?

Because debian/latest is more to type and because until we adopt
something I think has a chance of getting real conformity, I am far more
interested in my own convenience as a maintainer than I am in a
standard not many people are going to follow.

Effectively I disagree with you that incremental adoption of the kinds
of changes has significant value until you reach a core threshhold of
people committed to the work.

I think you're really close and if you manage to actually get this DEP
accepted, I'm going to fall in on as much of it as I can and on some of
the other recommendations you have been pushing.

I think uniformity in our use of git would be really really helpful.
But there have to be enough people committed before I'm going to
sacrifice my own convenience in favor of that uniformity.
Even if the convenience is really small.

So, the biggest thing you can do to get people like me to fall in would
be to give me a list of people who have committed to the uniformity so I
can see if we've met the threshold where I think it has a chance.

[Simon Josefsson]

Post by Sam Hartman
Otto> I would be curious to hear why people are *not* adopting
Otto> 'debian/latest'?
Because debian/latest is more to type and because until we adopt
something I think has a chance of getting real conformity, I am far more
interested in my own convenience as a maintainer than I am in a
standard not many people are going to follow.
Effectively I disagree with you that incremental adoption of the kinds
of changes has significant value until you reach a core threshhold of
people committed to the work.
I think you're really close and if you manage to actually get this DEP
accepted, I'm going to fall in on as much of it as I can and on some of
the other recommendations you have been pushing.
I think uniformity in our use of git would be really really helpful.
But there have to be enough people committed before I'm going to
sacrifice my own convenience in favor of that uniformity.
Even if the convenience is really small.
So, the biggest thing you can do to get people like me to fall in would
be to give me a list of people who have committed to the uniformity so I
can see if we've met the threshold where I think it has a chance.

That matches my position very well -- however I would add that for me
the simplest way to win me over is to improve tooling so that the
recommended workflow is the default for all involved tools and that they
actually work.

/Simon

[Michael Tokarev]

Post by Otto Kekäläinen
I would be curious to hear why people are *not* adopting 'debian/latest'?
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?

For me it's 3 things.

1. "debian/*" is just more to type than "*". For example, I often name multiple
objects (branches, tags) on the git command line to push to a remote.
I also often name directories after branches, and here, having / in the name
does not work well.

2. With debian/* I lose another convenient way to use debian/ as a path name,
without adding "--" to the options.

3. "latest" is a misnomer (unlike "main" or "master"). For example, I often use
"experimental" branch which is more recent than "master", yet the main
development is happening in "master".

There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

Thanks,

/mjt

[Samuel Thibault]

Post by Michael Tokarev
3. "latest" is a misnomer (unlike "main" or "master"). For example, I often use
"experimental" branch which is more recent than "master", yet the main
development is happening in "master".

Yes, that's why I wouldn't use "latest". I'd rather use debian/sid.

Samuel

[Julien Plissonneau Duquène]

Post by Michael Tokarev
2. With debian/* I lose another convenient way to use debian/ as a path name,
without adding "--" to the options.

As an alternative you may find `./` easier to type, depending on which
keyboard layout you are using.

Cheers,

[Tobias Frost]

Post by Michael Tokarev
3. "latest" is a misnomer (unlike "main" or "master"). For example, I often use
"experimental" branch which is more recent than "master", yet the main
development is happening in "master".

Same here. I think "latest" is a bad choice, as it is ambigious in some
situations: For example, is my experiment(al) package* latest or is the one
target for the next stable latest? For me, it is much clearer to say e.g
"debian/sid" or "debian/experimental" to express what I want.

* (noting that experiments might not end up in sid, those changes might not
* even have a business
in the latest branch.)

Post by Michael Tokarev
There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

(Maybe that you cannot have <$branch> and <$branch>/something)

Post by Michael Tokarev
Thanks,
/mjt

[Yadd]

Post by Tobias Frost

Post by Michael Tokarev
3. "latest" is a misnomer (unlike "main" or "master"). For example, I often use
"experimental" branch which is more recent than "master", yet the main
development is happening in "master".

Same here. I think "latest" is a bad choice, as it is ambigious in some
situations: For example, is my experiment(al) package* latest or is the one
target for the next stable latest? For me, it is much clearer to say e.g
"debian/sid" or "debian/experimental" to express what I want.

Or debian/master or debian/main to keep git logic (and previous gbp
behavior)

Post by Tobias Frost
* (noting that experiments might not end up in sid, those changes might not
* even have a business
in the latest branch.)

Post by Michael Tokarev
There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

(Maybe that you cannot have <$branch> and <$branch>/something)

Post by Michael Tokarev
Thanks,
/mjt

[Fabio Fantoni]

Post by Tobias Frost

Post by Michael Tokarev
3. "latest" is a misnomer (unlike "main" or "master"). For example, I often use
"experimental" branch which is more recent than "master", yet the main
development is happening in "master".

Same here. I think "latest" is a bad choice, as it is ambigious in some
situations: For example, is my experiment(al) package* latest or is the one
target for the next stable latest? For me, it is much clearer to say e.g
"debian/sid" or "debian/experimental" to express what I want.
* (noting that experiments might not end up in sid, those changes might not
* even have a business
in the latest branch.)

Hi, for years on some packages every new major version I did the uploads
on experimental first, in addition to the cases of feature freeze,
master was the default branch and I did it on experimental branch
changing d/gbp.conf, d/salsa-ci.yml and d/control, recently I switched
to debian/latest and I'm keeping it there whether you upload to
experimental or sid and I think that doing debian/unstable (or
debian/sid) less frequently only if you have the latest in experimental
but need some urgent fixes in unstable greatly reduces the need to
change branches (with a few more operations only for where you upload).

So even if it may seem vague it depends on how you choose to do things
and in many cases you could save time if you keep a generic branch as
default rather than one tied to unstable or experimental (which requires
more operations even when not necessary to maintain consistency)

There is also another thing to consider, if you keep a generic one as
default it always points to the latest version, while a specific one
might not be the latest version and if the contributors do not check
well the branches they could risk wasting time (and maybe also the
reviewers) doing work that does not include work in progress on more
recent branch or that conflicts with it

Post by Tobias Frost

Post by Michael Tokarev
There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

(Maybe that you cannot have <$branch> and <$branch>/something)

Post by Michael Tokarev
Thanks,
/mjt

[Otto Kekäläinen]

Thanks everyone for sharing your viewpoints, it is interesting to read!

I feel I need to clarify that I am not a native English speaker and my
intent was to write a polite and honest email. It does not say
anywhere that "you must use debian/latest". I am happy with whatever
the convention is, as long as it works, and is universal at least for
new packages.

I am fine if single-maintainer packages, or closed-team packages do
whatever they want, as it won't affect others (at least immediately),
but not having "best practice" agreed on basic things like git
branches does cause unnecessary friction and time waste for those who
participate in the maintenance of packages in multiple different
teams, at least from my perspective.

As somebody who is mentoring multiple new maintainers, I see them in
particular having unnecessary hardship from lack of properly agreed
conventions. For the long-term success of Debian, I think that
discussing the best practices and having some things agreed is
valuable, even though running the discussions does take energy.

[Soren Stoutner]

Post by Otto Kekäläinen
Thanks everyone for sharing your viewpoints, it is interesting to read!
I feel I need to clarify that I am not a native English speaker and my
intent was to write a polite and honest email. It does not say
anywhere that "you must use debian/latest". I am happy with whatever
the convention is, as long as it works, and is universal at least for
new packages.
I am fine if single-maintainer packages, or closed-team packages do
whatever they want, as it won't affect others (at least immediately),
but not having "best practice" agreed on basic things like git
branches does cause unnecessary friction and time waste for those who
participate in the maintenance of packages in multiple different
teams, at least from my perspective.
As somebody who is mentoring multiple new maintainers, I see them in
particular having unnecessary hardship from lack of properly agreed
conventions. For the long-term success of Debian, I think that
discussing the best practices and having some things agreed is
valuable, even though running the discussions does take energy.

I agree that we need one standard naming scheme. Based on the email responses, it
seems like debian/latest doesn’t convey the appropriate meaning, with something like
debian/unstable being more appropriate. Perhaps you should create a vote with MR
options (similar to the one you did for DEP-0 naming). Once there is a strong consensus
on what the name should be, I would recommend that gbp be reprogrammed to default
to that name (I know it is a lot of work), and after that it will probably be fairly easy to to
get DEP-14 accepted.

[Fabio Fantoni]

Post by Otto Kekäläinen
Thanks everyone for sharing your viewpoints, it is interesting to read!
I feel I need to clarify that I am not a native English speaker and my
intent was to write a polite and honest email. It does not say
anywhere that "you must use debian/latest". I am happy with whatever
the convention is, as long as it works, and is universal at least for
new packages.
I am fine if single-maintainer packages, or closed-team packages do
whatever they want, as it won't affect others (at least immediately),
but not having "best practice" agreed on basic things like git
branches does cause unnecessary friction and time waste for those who
participate in the maintenance of packages in multiple different
teams, at least from my perspective.
As somebody who is mentoring multiple new maintainers, I see them in
particular having unnecessary hardship from lack of properly agreed
conventions. For the long-term success of Debian, I think that
discussing the best practices and having some things agreed is
valuable, even though running the discussions does take energy.

I agree that we need one standard naming scheme.  Based on the email
responses, it seems like debian/latest doesn’t convey the appropriate
meaning, with something like debian/unstable being more appropriate.

debian/unstable is not good in case in default branch want to keep the
latest work regardless of uploads to unstable or experimental, and use
debian/unstable only if the latest versions are uploaded to experimental
(could also be just for the freeze period) but urgent fixes are needed
for unstable

Perhaps you should create a vote with MR options (similar to the one
you did for DEP-0 naming).  Once there is a strong consensus on what
the name should be, I would recommend that gbp be reprogrammed to
default to that name (I know it is a lot of work), and after that it
will probably be fairly easy to to get DEP-14 accepted.
--
Soren Stoutner

[Julien Plissonneau Duquène]

Post by Otto Kekäläinen
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.

To be fair `debian/latest` was introduced much later in that DEP history
...

Post by Otto Kekäläinen
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.

... precisely in 2020-11-29. Before that the DEP recommended
`debian/master`.

As a remainder, that whole `master` deprecation is still controversial
(e.g. should we deprecate "server" and "service" as well?).

Cheers,

[Gioele Barabucci]

Post by Julien Plissonneau Duquène

Post by Otto Kekäläinen
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.

... precisely in 2020-11-29. Before that the DEP recommended
`debian/master`.
As a remainder, that whole `master` deprecation is still controversial
(e.g. should we deprecate "server" and "service" as well?).

Aside from the "master"/"slave" discussion, prefixing branches with a
namespace is a basic good practice when dealing with multiple
development places at the same time (upstream, debian, ubuntu), each
having multiple short- and long-lived branches (mainline, backports,
features).

Even if we were to keep "master" instead of "latest", it's much better
to use "upstream/master" and "debian/master": no name clashes and no
ambiguity about which "master" one is referring to.

Regards,

[Yadd]

Post by Gioele Barabucci

Post by Otto Kekäläinen
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.

... precisely in 2020-11-29. Before that the DEP recommended `debian/
master`.
As a remainder, that whole `master` deprecation is still controversial
(e.g. should we deprecate "server" and "service" as well?).

Aside from the "master"/"slave" discussion, prefixing branches with a
namespace is a basic good practice when dealing with multiple
development places at the same time (upstream, debian, ubuntu), each
having multiple short- and long-lived branches (mainline, backports,
features).
Even if we were to keep "master" instead of "latest", it's much better
to use "upstream/master" and "debian/master": no name clashes and no
ambiguity about which "master" one is referring to.

Hi,

I'll still wait to apply DEP-14 until this choices are done ;-)

Best regards,

[Julien Plissonneau Duquène]

Post by Gioele Barabucci
Even if we were to keep "master" instead of "latest", it's much better
to use "upstream/master" and "debian/master": no name clashes and no
ambiguity about which "master" one is referring to.

Or maybe `debian/main` to keep up with the popular trend, and as `main`
is a better choice anyways, regardless of some popular controversial
arguments.

[Gard Spreemann]

Even if we were to keep "master" instead of "latest", it's much better to use
"upstream/master" and "debian/master": no name clashes and no ambiguity about
which "master" one is referring to.

Or maybe `debian/main` to keep up with the popular trend, and as `main` is a
better choice anyways, regardless of some popular controversial arguments.

Indeed. I don't really understand what "latest" is meant to
convey. Latest what? "Latest work ever done on this package at any given
moment"? We surely don't want to discourage branches with specific
topics that surely can hold later work?

[Gard Spreemann]

Post by Otto Kekäläinen
Hi!
Current https://dep-team.pages.debian.net/deps/dep14/ states that the

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.

I would be curious to hear why people are *not* adopting 'debian/latest'?

I call the branch debian/sid simply because sid is already what we call
the distribution where we by default do work on the "latest stuff".


Best,
Gard

[Gioele Barabucci]

Post by Gard Spreemann

Post by Otto Kekäläinen
I would be curious to hear why people are *not* adopting 'debian/latest'?

I call the branch debian/sid simply because sid is already what we call
the distribution where we by default do work on the "latest stuff".

You mean debian/unstable, don't you? :P

"unstable" is what is written in changelog and "debian/unstable" is

Post by Gard Spreemann
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.

debian/latest = UNRELEASED (may be unstable or experimental)

debian/unstable = This will be uploaded to unstable.

Regards,

--
Gioele Barabucci

[Gard Spreemann]

Post by Gioele Barabucci

Post by Gard Spreemann

Post by Otto Kekäläinen
I would be curious to hear why people are *not* adopting 'debian/latest'?

I call the branch debian/sid simply because sid is already what we call
the distribution where we by default do work on the "latest stuff".

You mean debian/unstable, don't you? :P
"unstable" is what is written in changelog and "debian/unstable" is DEP-14

Post by Gard Spreemann
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.

debian/latest = UNRELEASED (may be unstable or experimental)
debian/unstable = This will be uploaded to unstable.

I appreciate the distinction being pointed out. For stuff that is not
clearly slated for upload anywhere, but still meant to be shared through
git, I usually use a descriptive name for whatever the purpose of the
branch is (debian/testing-out-new-major-upstream-version-x,
whatever). Either that branch gets abandoned, or it gets merged into
debian/sid (and uploaded to unstable).

This has probably been discussed a lot already, so sorry if I'm
rehashing tired points, but I don't really see the point of a consistent
name for a branch that may or may not ever feature uploads
anywhere. Surely the goal is an upload to unstable – hence my thinking
when calling the main branch debian/sid (or debian/unstable, as you
point out earlier).


Best,
Gard

[Salvo Tomaselli]

Post by Gioele Barabucci
debian/latest = UNRELEASED (may be unstable or experimental)
debian/unstable = This will be uploaded to unstable.

I wouldn't think that is needed at all, since git tags exist.


so tags is what gets uploaded and the rest isn't already.

[Jonathan Dowland]

Post by Otto Kekäläinen
I would be curious to hear why people are *not* adopting
'debian/latest'?
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?

In my case (not many packages, mostly solo-maintained these days) I just
haven't bothered to put the time in to do it. If there was strong
consensus on the new scheme, such that I could be sure doing the work
might be making lives easier for other people, I would be more inclined
to do it. But (as this sub-thread shows), there isn't.

Post by Otto Kekäläinen
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.

To some extent this is backwards. DEPs are supposed to codify best
practice; DEP-14 suggests something that the majority of packages are
not actually doing. Its status as DRAFT, and the fact it could change at
any time, aren't encouraging etiher.

If a large packaging team adopted it, or the git-buildpackage
maintainers changed their defaults, that would help the numbers.

[Raphael Hertzog]

Hi,

To some extent this is backwards. DEPs are supposed to codify best practice;
DEP-14 suggests something that the majority of packages are not actually
doing.

That's not correct. We have this requirement for Debian policy, it's
supposed to codify best practices that have been already widely deployed,
but not for DEP.

DEP are "Debian Enhancement Proposals" so they imply that there are changes
to do and the process is there to build some sort of rough consensus about
those improvements and build a way forward.

Its status as DRAFT, and the fact it could change at any time, aren't
encouraging etiher.

It has been CANDIDATE (not DRAFT) without major changes for a long time.

If a large packaging team adopted it, or the git-buildpackage maintainers
changed their defaults, that would help the numbers.

There are large teams that adopted it. But I agree that the fact that
git-buildpackage was not updated accordingly is the main reason why we are
having this discussion today.

And it's a pity because the git-buildpackage maintainer was in favor
but simply didn't had the time to handle that transition properly, and
nobody else did it either (me included).

AFAIK Otto started to contribute to git-buildpackage for this, so
hopefully that will change now.

Cheers,

[Fabio Fantoni]

Post by Otto Kekäläinen
Hi!
Current https://dep-team.pages.debian.net/deps/dep14/ states that the

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.

I would be curious to hear why people are *not* adopting 'debian/latest'?
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?
Is it simply because git-buildpackage does not to default to 'debian/latest'?
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.

I think:

- because is not the default in tools

- because it is not addressed in the documentation or as an example I
have seen documentation that used it but due to the lack of details of
additional operations there was the risk of not really using it
(https://wiki.debian.org/PackagingWithGit?action=diff&rev2=53&rev1=52)

- because it has changed (it was debian/master) and maybe they don't
want to change again, or they fear it will change again

- because it is not easy and fast to migrate and if you do it you have
to redo the local repository, if you are alone working on the repository
it is not a big problem while if you are many it can create inconveniences


for example, about migration, I changed major repositories on cinnamon
team recently where I near only me to work with:

- push any works if not already done

- change d/gbp.conf for new branches name and push skipping salsa-ci (if
used)

- convert with salsa cli that is faster but one thing fails and require
manual operation:

salsa --group cinnamon-team protect_branch cinnamon master no
salsa --verbose --group cinnamon-team --rename-head rename_branch
cinnamon --source-branch=master --dest-branch=debian/latest
# this will fails to delete master, change default branch from salsa
website (in Settings->Repository) and delete master branch (from website)
salsa --group cinnamon-team protect_branch cinnamon debian/latest m d
salsa --verbose --no-fail --group cinnamon-team rename_branch cinnamon
--source-branch=upstream --dest-branch=upstream-tmp
salsa --verbose --no-fail --group cinnamon-team rename_branch cinnamon
--source-branch=upstream-tmp --dest-branch=upstream/latest

note: in case of multiple debian/upstream branches more operations will
be needed

- for local repository instead multiple operation to convert is simpler
and fast do new with a gbp clone

In case of multiple people active working on repository is good to
advise all to push any work not pushed, not to do anything else at the
scheduled time of conversion and then make a new copy with gbp clone.

[gregor herrmann]

Post by Fabio Fantoni

Post by Otto Kekäläinen
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?

- because is not the default in tools
- because it is not easy and fast to migrate and if you do it you have to
redo the local repository, if you are alone working on the repository it is
not a big problem while if you are many it can create inconveniences

IMO this is the real hurdle.
Migrating thousands (in the case of pkg-perl) repos both remote/on
salsa and locally (for dozens of team members) is not trivial, and
AFAIK noone so far has come up with working tooling.


Cheers,
gregor

[G. Branden Robinson]

as for the original subject of this thread: what's actually wrong with
'debian/main' instead of 'debian/latest'? i personally do not really
care, and can live with whatever is decided.

I'd point out that "debian/main" also refers to the part of the Debian
package archive that is not "contrib" or "non-free".

I therefore perceive "debian/main" as ambiguous.

Regards,
Branden

[Charles Plessy]

Hello everybody,

How about debian/default or debian/devel?

The good thing with these names is that they are friendly to
tab-completion, as the finger on the letter d does not have to move.

Have a nice day,

[Chris Hofstaedtler]

Post by Charles Plessy
Hello everybody,
How about debian/default or debian/devel?

Yes please do a few more changes to the names, so everybody can pick
whatever they like ("it was fine back then"), and everone who went
under a painful migration to the current scheme can either
experience that again or, better, will ignore whatever the DEP will
say in the future.

Chris

[Guillem Jover]

Hi!

Post by G. Branden Robinson

as for the original subject of this thread: what's actually wrong with
'debian/main' instead of 'debian/latest'? i personally do not really
care, and can live with whatever is decided.

I'd point out that "debian/main" also refers to the part of the Debian
package archive that is not "contrib" or "non-free".
I therefore perceive "debian/main" as ambiguous.

I think this has been mentioned in the past, and I understand this could
be considered confusing depending on the context. But I think that in
this specific context this looks a bit like a stretch, because using
this naming to refer to an archive area without also qualifying it in
addition with a specific suite/codename does not make much sense to me,
also when in particular the main archive area is implicit in most (if
not all) of the maintainer side of the packaging. So in context, to me
it seems clear it should be referring to the main development branch
for Debian. :)

Thanks,
Guillem

[Holger Levsen]

Post by Guillem Jover

Post by G. Branden Robinson
I'd point out that "debian/main" also refers to the part of the Debian
package archive that is not "contrib" or "non-free".
I therefore perceive "debian/main" as ambiguous.

I think this has been mentioned in the past, and I understand this could
be considered confusing depending on the context. But I think that in
this specific context this looks a bit like a stretch, because using
this naming to refer to an archive area without also qualifying it in
addition with a specific suite/codename does not make much sense to me,
also when in particular the main archive area is implicit in most (if
not all) of the maintainer side of the packaging. So in context, to me
it seems clear it should be referring to the main development branch
for Debian. :)

I agree with Guillem here. I also like debian/devel btw...
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Ich bin so alt, ich hab im Kindergarten noch Aschenbecher getöpfert.
(@joanalistin)

[Jeremy Bícha]

Until 2020, DEP-14 suggested <vendor>/master.

The use of "master" became undesired if a better word was available.
See https://inclusivenaming.org/

DEP-14 was already using upstream/latest so for parallel construction,
<vendor>/latest was kind of an obvious choice.

Note that DEP-14 explicitly allows you to use debian/unstable and
debian/experimental if you want.

As has already been mentioned earlier in this thread, the Debian GNOME
renamed all our branches from debian/master to debian/latest a year
and a half ago.

And for our specific workflow, using debian/latest (or debian/master
before) proved better since at the time of packaging, we don't always
know whether we will upload to unstable or experimental. For most of
our packages, once we upload to Experimental, it is rare to upload to
Unstable again. GNOME is on a 6-month release cycle so there is only a
small amount of time, usually after GNOME Beta, where we stage some
things in experimental before they are ready for upload to Unstable.
If we do need to upload to Unstable when a package is already in
Experimental, we use a short-lived debian/trixie branch. If the
development cycle is long enough, that short-lived branch gets
re-created (this was done with libadwaita-1 for a new GNOME series).
At or near new stable release time, a permanent debian/trixie branch
is created which allows for merge requests for stable updates.

As Simon pointed out, long-lived development would probably work
better with a debian/experimental branch. I think many Debian packages
never or only rarely use Experimental so debian/latest is probably
best practice for most packages.

Thank you,
Jeremy Bícha

[Johannes Schauer Marin Rodrigues]

Quoting IOhannes m zmölnig (Debian GNU|Linux) (2025-01-27 12:27:12)

Post by gregor herrmann

Post by Fabio Fantoni
- because it is not easy and fast to migrate and if you do it you have to
redo the local repository, if you are alone working on the repository it is
not a big problem while if you are many it can create inconveniences

IMO this is the real hurdle.

indeed.
this has been the main blocker, why I did not update the repositories
(at least those, where i'm practically the sole committer).
ideally, there would be a simple script that does all the conversion for
```sh
salsa2dep14 hello-team/helloworld
```

like this one?

https://salsa.debian.org/debian/devscripts/-/merge_requests/427

[Otto Kekäläinen]

Hi!

Post by gregor herrmann

Post by Fabio Fantoni
- because it is not easy and fast to migrate and if you do it you have to
redo the local repository, if you are alone working on the repository it is
not a big problem while if you are many it can create inconveniences

IMO this is the real hurdle.
Migrating thousands (in the case of pkg-perl) repos both remote/on
salsa and locally (for dozens of team members) is not trivial, and
AFAIK noone so far has come up with working tooling.

I wrote and rewrote this script a couple of times in past two months:
https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/dep-14-convert-git-branch-names.sh

It's not exactly ideal yet, but it does the job. The name is a bit
stupid, and it only outputs the commands it recommends users to run,
it does not actually execute them (yet). In hindsight it became a bit
more complex than what makes sense for a shell script. Simon also
pointed out that the way the `salsa` script (that this uses) stores
API keys in plain-text isn't exactly ideal for security.

Jeremy: You mentioned Debian team is migrating branches. Perhaps you
can test this and collaborate on polishing it?

In general, if anybody wants to take a stab to improve it, feel free
to add me as reviewer in MRs targeting this script.

- Otto

PS. Props to Johannes SMR for reviewing and testing the script in past months!

[Marvin Renich]

Post by Otto Kekäläinen
https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/dep-14-convert-git-branch-names.sh
It's not exactly ideal yet, but it does the job. The name is a bit
stupid, and it only outputs the commands it recommends users to run,
it does not actually execute them (yet). In hindsight it became a bit
more complex than what makes sense for a shell script. Simon also
pointed out that the way the `salsa` script (that this uses) stores
API keys in plain-text isn't exactly ideal for security.
Jeremy: You mentioned Debian team is migrating branches. Perhaps you
can test this and collaborate on polishing it?
In general, if anybody wants to take a stab to improve it, feel free
to add me as reviewer in MRs targeting this script.
In the situation you outlined, it wouldn't have mattered to me one bit
whether the actual latest branch was called debian/sid or debian/latest;
I probably wouldn't have noticed it either way. What would have
mattered to me was that it wasn't the default branch (HEAD on Salsa).
So, rather than worrying about the _name_ of the default branch, I'd
like to suggest a change to DEP-14 that I think would have broader
consensus and be more useful.

Please re-read his entire message.

You started with a goal of making contributions easier for people who
are not part of the packaging team for a particular project. You then
postulated that standardizing certain things would at least be part of
the solution, and so DEP-14 was born. Overall, this is excellent work!
Thank you.

One of the things you postulated was that the name of the default branch
was one of the items that should be standardized. This was a reasonable
assumption. But as Colin points out, the real issue is not the _name_
of the default branch, but that the salsa repo _correctly_ identifies
the default branch, which apparently is not being done for all projects.

This thread has clearly shown that much contention exists for mandating
a specific name for the default branch, at least for existing projects.
Even if you wrote the perfect script to change existing projects to
conform, one that handled all edge conditions properly without human
intervention, the amount of churn, not only on salsa, but also on
_thousands_ of contributors' personal machines, would be **massive**.
And all this when simply mandating that the salsa repo have HEAD set
correctly would solve the problem.

It has also been pointed out that there are some projects (esp. larger
ones) where primary development occurs on multiple different branches.

I strongly urge you to heed Colin's suggestion. Have DEP-14 _require_
that the salsa repo have HEAD set to the branch where new contributors,
NMUers, and others not familiar with the project should be making
changes. Then _suggest_ that _new_ projects use a specific branch name
for this purpose.

Thank you for both your enthusiasm and your effort on this project.

...Marvin

[Marvin Renich]

DEP-14 could have a stronger message, but the requirement for HEAD to point
to the development branch is there.
Currently, there's only one place where DEP-14 talks about the default
branch: the "Native packages" section says "the default branch of the
repository (as pointed by the HEAD reference) should be a development
branch". I suggest that this recommendation should not be just for
native packages. The "For development releases" section should say that
the branch for uploads to the current development release of the
furthest-upstream distribution handled in a given repository (typically
Debian) should be the default branch, as pointed to by the HEAD
reference.

That doesn't nullify my (or Colin's) request to change the requirement
for a specific branch _name_ to only be a suggestion for new projects.

This would avoid the unnecessary, massive churn of renaming branches for
existing projects (and GNOME, apparently, has already done this once for
this DEP).

...Marvin

[Colin Watson]

Post by Marvin Renich
I strongly urge you to heed Colin's suggestion. Have DEP-14 _require_
that the salsa repo have HEAD set to the branch where new contributors,
NMUers, and others not familiar with the project should be making
changes.
[Packaging branches and tags] NOTE: If the Git repository listed in
debian/control's Vcs-Git field does not indicate an explicit branch
(with the -b <branch> suffix) then it should have its HEAD point to
the branch where new upstream versions are being packaged (that is
one of the branches associated to a development release). 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.

and

Post by Marvin Renich
[Native packages] However the default branch of the repository (as
pointed by the HEAD reference) should be a development branch.

DEP-14 could have a stronger message, but the requirement for HEAD to point
to the development branch is there.

Oh. Maybe this is my problem then, but the fact that I missed this even
when I was specifically trying to find it suggests that there might be a
problem. Maybe it should use the phrase "default branch" in both
places?

And yes, Marvin is right to point out that I'm saying that the branch
name should be something we take into account for new repositories
rather than something we try to impose on existing ones. No matter how
much you polish a script to do the renaming in bulk, the change is still
going to be disruptive to anyone who has a local clone of any of the
affected repositories at the moment. So maybe let's spend time on
something else instead.

[Jeremy Bícha]

Post by Otto Kekäläinen
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.

Your timeline is inaccurate. According to DEP-14's own Changes
section, debian/latest was not recommended until 4 years ago. I did
not notice the change right away.

The Debian GNOME team was a fairly early adopter of DEP-14 and we had
to spend time at the beginning of the trixie development cycle to
convert all our packages from debian/master to debian/latest [1]. (Out
of an abundance of caution, it seemed not helpful to do that migration
while bookworm was frozen.) Therefore, even the strongest supporters
of DEP-14 may have only very recently adopted debian/latest.

[1] https://lists.debian.org/debian-gtk-gnome/2023/08/msg00005.html

Thank you,
Jeremy Bícha

[Andrej Shadura]

Hi,

Post by Otto Kekäläinen
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?

I’ve not really used debian/master or debian/latest because it does not seem to convey what I’m intending by the branch name. I’m uploading to unstable, hence it’s debian/unstable for me, not anything else. I don’t intend to change this habit.

[Sean Whitton]

Hello,

I don't think there's a need to use a Debian-specific name for this
concept. 'master' or 'main' are fine.

debian/bookworm etc.. are a different story; I am glad we have those.

As there is much disagreement, maybe we could drop the default branch
name part of the DEP and mark the rest of it as ACCEPTED. I don't think
any other parts have disagreement.

[Xiyue Deng]

Post by Fabio Fantoni
...
There is also another thing to consider, if you keep a generic one as
default it always points to the latest version, while a specific one
might not be the latest version and if the contributors do not check
well the branches they could risk wasting time (and maybe also the
reviewers) doing work that does not include work in progress on more
recent branch or that conflicts with it

I would like to echo on this point. I had worked on a repository that
has the "master" branch marked as the default branch on Salsa, which
lacks many changes compared to the released version. I tried to
manually incorporate those changes, and only later found out that the
actual latest branch is "debian/sid" and it did have everything
up-to-date. (Note that this has since been fixed[1]). I think for new
repository, standardizing on a name (either "debian/latest" or people's
liking) helps identify where the latest work goes to. And as Salvo
pointed out, it's the tag names that indicate where the releases go to,
not the branch names.

[1] https://salsa.debian.org/debian/mozc

Post by Fabio Fantoni

Post by Tobias Frost

Post by Michael Tokarev
There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

(Maybe that you cannot have <$branch> and <$branch>/something)

Post by Michael Tokarev
Thanks,
/mjt

[t***@goirand.fr]

Post by Xiyue Deng

Post by Fabio Fantoni
...
There is also another thing to consider, if you keep a generic one as
default it always points to the latest version, while a specific one
might not be the latest version and if the contributors do not check
well the branches they could risk wasting time (and maybe also the
reviewers) doing work that does not include work in progress on more
recent branch or that conflicts with it

I would like to echo on this point. I had worked on a repository that
has the "master" branch marked as the default branch on Salsa, which
lacks many changes compared to the released version. I tried to
manually incorporate those changes, and only later found out that the
actual latest branch is "debian/sid" and it did have everything
up-to-date. (Note that this has since been fixed[1]). I think for new
repository, standardizing on a name (either "debian/latest" or people's
liking) helps identify where the latest work goes to. And as Salvo
pointed out, it's the tag names that indicate where the releases go to,
not the branch names.
[1] https://salsa.debian.org/debian/mozc

What you experience shows one thing: having the default branch being set correctly should be what we mandate. NOT the name of it, which could be different than the standards for many reason.


Thomas Goirand (zigo)

[Xiyue Deng]

Post by t***@goirand.fr

Post by Xiyue Deng

Post by Fabio Fantoni
...
There is also another thing to consider, if you keep a generic one as
default it always points to the latest version, while a specific one
might not be the latest version and if the contributors do not check
well the branches they could risk wasting time (and maybe also the
reviewers) doing work that does not include work in progress on more
recent branch or that conflicts with it

I would like to echo on this point. I had worked on a repository that
has the "master" branch marked as the default branch on Salsa, which
lacks many changes compared to the released version. I tried to
manually incorporate those changes, and only later found out that the
actual latest branch is "debian/sid" and it did have everything
up-to-date. (Note that this has since been fixed[1]). I think for new
repository, standardizing on a name (either "debian/latest" or people's
liking) helps identify where the latest work goes to. And as Salvo
pointed out, it's the tag names that indicate where the releases go to,
not the branch names.
[1] https://salsa.debian.org/debian/mozc

What you experience shows one thing: having the default branch being
set correctly should be what we mandate.

Indeed. Though IIRC the default branch was not a native git concept
until 2.28, so user of older git may still get confused.

Post by t***@goirand.fr
NOT the name of it, which could be different than the standards for
many reason.

I think for new package repositories having a recommended name is a good
thing to avoid confusions like this, which I think DEP-14 was for.

Post by t***@goirand.fr
Thomas Goirand (zigo)

[Colin Watson]

Post by Xiyue Deng

Post by t***@goirand.fr
What you experience shows one thing: having the default branch being
set correctly should be what we mandate.

Indeed. Though IIRC the default branch was not a native git concept
until 2.28, so user of older git may still get confused.

Firstly, 2.28 predates buster, so we're unlikely to have to worry about
it very much.

Secondly, while 2.28 fixed a number of problems that people ran into
when trying to change the default branch name for new repositories and
various other related corner cases, I don't think any of them applied to
the simple case of just cloning a repository where the remote HEAD
points to something other than "master". I'm not sure exactly how long
that's worked for, but poking through "tig blame builtin/clone.c", I
think it's probably been supported to some extent at least as far back
as git 1.5.6.

[Julien Plissonneau Duquène]

Hi,

Post by t***@goirand.fr
What you experience shows one thing: having the default branch being
set correctly should be what we mandate.

That's one thing, but going one step further, NOT pushing upstream
branches to the packaging repositories may help here as well.

Cheers,

[Phil Morrell]

Post by t***@goirand.fr
What you experience shows one thing: having the default branch being
set correctly should be what we mandate.

We already do "If no branch is specified, the packaging should be on the default branch" but we're only human https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-vcs-fields

That's one thing, but going one step further, NOT pushing upstream branches to the packaging repositories may help here as well.

I'm going to have to disagree with this part, the whole point of DEP14 is that our debianisms are namespaced, so there's no harm in pushing all branches.

[Julien Plissonneau Duquène]

On 25 January 2025 08:07:04 GMT, "Julien Plissonneau Duquène"

Post by Julien Plissonneau Duquène
That's one thing, but going one step further, NOT pushing upstream
branches to the packaging repositories may help here as well.

I'm going to have to disagree with this part, the whole point of DEP14
is that our debianisms are namespaced, so there's no harm in pushing
all branches.

Are you really sure that there is no harm in, for example, pushing all
the 5785 (and counting) branches of https://github.com/JetBrains/kotlin/
to its packaging repository? For the record, it's a 4 GiB download, and
it makes some tools crash. There are probably even worse examples in the
wild.

people keep including all upstream history in the packaging repos
(which seems like an anti pattern to me and goes against the
overwhelming packaging practices for pretty much every other
distribution not based on Debian)

and this affirmation may deserve some discussion.

[1]:
https://salsa.debian.org/dep-team/deps/-/merge_requests/9#note_574074

[Otto Kekäläinen]

Hi!

Post by Julien Plissonneau Duquène

Post by Phil Morrell
I'm going to have to disagree with this part, the whole point of DEP14
is that our debianisms are namespaced, so there's no harm in pushing
all branches.

Are you really sure that there is no harm in, for example, pushing all
the 5785 (and counting) branches of https://github.com/JetBrains/kotlin/
to its packaging repository? For the record, it's a 4 GiB download, and
it makes some tools crash. There are probably even worse examples in the
wild.

I think Phil meant by 'all branches' here both the Debian packaging
branches and the upstream development branch, not 'all upstream
branches'. I don't think that even Kotlin developers themselves want
to have all 5000+ branches and 36000+ tags on their machines :)

I imagine that apart from the largest upstream projects that have
multiple parallel maintenance releases, pulling a single 'main' branch
or equivalent is enough for a Debian Developer to base patches on and
be able to easily submit back upstream.

If you want to have an upstream from Kotlin and make it smaller, you
can do it whit a tag-free and shallow git clone with commands:

gbp clone ***@salsa.debian.org:java-team/kotlin.git
cd kotlin
git remote add upstreamvcs https://github.com/JetBrains/kotlin.git -t
master --no-tags
git fetch upstreamvcs --shallow-since='2 months ago'

du -sh .git
=> 182M .git

If you also want to have the most recent tags, this would selectively
fetch the latest release tags and only them (tailored to the Kotlin
repo tag format):

for TAG in $(git ls-remote upstreamvcs | grep --only-matching
--perl-regexp 'tags/\Kv[^-]+$' | tail); do git fetch upstreamvcs tag
$TAG --depth=1; done
=> 219M .git

However, git does not support *pushing* shallow branches, so the above
does not help optimize Salsa in any way. I only shared as curiosa for
those who are interested in git features.

[Colin Watson]

Post by t***@goirand.fr
What you experience shows one thing: having the default branch being
set correctly should be what we mandate.

That's one thing, but going one step further, NOT pushing upstream branches
to the packaging repositories may help here as well.

Pushing upstream branches is only a problem if an upstream branch is set
as the default. Otherwise, it's helpful for various tools to have them
available.

[Fabio Fantoni]

Post by Xiyue Deng

Post by Fabio Fantoni
...
There is also another thing to consider, if you keep a generic one as
default it always points to the latest version, while a specific one
might not be the latest version and if the contributors do not check
well the branches they could risk wasting time (and maybe also the
reviewers) doing work that does not include work in progress on more
recent branch or that conflicts with it

I would like to echo on this point. I had worked on a repository that
has the "master" branch marked as the default branch on Salsa, which
lacks many changes compared to the released version. I tried to
manually incorporate those changes, and only later found out that the
actual latest branch is "debian/sid" and it did have everything
up-to-date. (Note that this has since been fixed[1]). I think for new
repository, standardizing on a name (either "debian/latest" or people's
liking) helps identify where the latest work goes to. And as Salvo
pointed out, it's the tag names that indicate where the releases go to,
not the branch names.
[1] https://salsa.debian.org/debian/mozc

I wrote this because I also saw this issue over the years.

Check the tags is useful if there are new upstream or debian version (so
new tags) but not unreleased work excluding new upstream version, this
require to look on branches those with the most recent activity,
excluding those of fixes released for stable and backports.

It might seem obvious but unfortunately it is not, I fear that someone
does not check by looking only at the default branch or maybe quickly
not noticing something, for example in cases with particular and
different names that are not common, linked to versions of the distro or
software (at least not numbers).

For this reason, trying to standardize with a single name the branches
where the most current work is carried out (with some exceptions), if
not recommended by DEP-14 (because in some cases it is
counterproductive) but at least suggested being able to have in the
future the majority of uniform gits I think can be useful.

Then there were cases where the problem was that the default branch was
no longer actually used but was not updated, so in addition to the name
it would be good to make sure to keep the default branch updated. I have
seen for example cases of those who created the repository with master
but then immediately used another working branch (like "debian"), or who
had switched from master to main but kept the default on master and
these are just 2 examples of what I had seen.

While I was finishing I saw @zigo's answer regarding this last part,
"default branch being set correctly should be what we mandate" would
help even if is not for all cases (excluding any separate branches for
"test" work, that is ok more updated but not default)

2 other particular cases that hinder could also be when someone work on
another git without updating the fields in d/control and that do not
work on the default branch because maybe only someone with lower
permission remained active in the repository and who cannot push to the
default branch by setting (rare but it happened), it would be necessary
to better define how to act (and also have the means in some cases) to
reduce the problematic cases to which I add a last example, "abandoned"
package in which those who continue cannot modify in the repository and
proceed in another repository but unfortunately until a new upload is
made with the updated vcs fields others don't know and there is a risk
of doing duplicate work elsewhere (it happened also to me)

Post by Xiyue Deng

Post by Fabio Fantoni

Post by Tobias Frost

Post by Michael Tokarev
There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

(Maybe that you cannot have <$branch> and <$branch>/something)

Post by Michael Tokarev
Thanks,
/mjt

[Xiyue Deng]

Hi Fabio,

Post by Fabio Fantoni

Post by Xiyue Deng

Post by Fabio Fantoni
...
There is also another thing to consider, if you keep a generic one as
default it always points to the latest version, while a specific one
might not be the latest version and if the contributors do not check
well the branches they could risk wasting time (and maybe also the
reviewers) doing work that does not include work in progress on more
recent branch or that conflicts with it

I would like to echo on this point. I had worked on a repository that
has the "master" branch marked as the default branch on Salsa, which
lacks many changes compared to the released version. I tried to
manually incorporate those changes, and only later found out that the
actual latest branch is "debian/sid" and it did have everything
up-to-date. (Note that this has since been fixed[1]). I think for new
repository, standardizing on a name (either "debian/latest" or people's
liking) helps identify where the latest work goes to. And as Salvo
pointed out, it's the tag names that indicate where the releases go to,
not the branch names.
[1] https://salsa.debian.org/debian/mozc

I wrote this because I also saw this issue over the years.
Check the tags is useful if there are new upstream or debian version (so
new tags) but not unreleased work excluding new upstream version, this
require to look on branches those with the most recent activity,
excluding those of fixes released for stable and backports.
It might seem obvious but unfortunately it is not, I fear that someone
does not check by looking only at the default branch or maybe quickly
not noticing something, for example in cases with particular and
different names that are not common, linked to versions of the distro or
software (at least not numbers).
For this reason, trying to standardize with a single name the branches
where the most current work is carried out (with some exceptions), if
not recommended by DEP-14 (because in some cases it is
counterproductive) but at least suggested being able to have in the
future the majority of uniform gits I think can be useful.
Then there were cases where the problem was that the default branch was
no longer actually used but was not updated, so in addition to the name
it would be good to make sure to keep the default branch updated. I have
seen for example cases of those who created the repository with master
but then immediately used another working branch (like "debian"), or who
had switched from master to main but kept the default on master and
these are just 2 examples of what I had seen.
"default branch being set correctly should be what we mandate" would
help even if is not for all cases (excluding any separate branches for
"test" work, that is ok more updated but not default)
2 other particular cases that hinder could also be when someone work on
another git without updating the fields in d/control and that do not
work on the default branch because maybe only someone with lower
permission remained active in the repository and who cannot push to the
default branch by setting (rare but it happened), it would be necessary
to better define how to act (and also have the means in some cases) to
reduce the problematic cases to which I add a last example, "abandoned"
package in which those who continue cannot modify in the repository and
proceed in another repository but unfortunately until a new upload is
made with the updated vcs fields others don't know and there is a risk
of doing duplicate work elsewhere (it happened also to me)

Thanks for providing more real world use cases. I think these may help
people (me included) understand the rationale on trying to suggest a
name for the branch of the latest work better.

Post by Fabio Fantoni

Post by Xiyue Deng

Post by Fabio Fantoni

Post by Tobias Frost

Post by Michael Tokarev
There were cases when git wont let me use debian/foo "branch subdir" since it
clashed with other objects in the git repository, but I don't remember what it
was.

(Maybe that you cannot have <$branch> and <$branch>/something)

Post by Michael Tokarev
Thanks,
/mjt

[Colin Watson]

Post by Xiyue Deng
I would like to echo on this point. I had worked on a repository that
has the "master" branch marked as the default branch on Salsa, which
lacks many changes compared to the released version. I tried to
manually incorporate those changes, and only later found out that the
actual latest branch is "debian/sid" and it did have everything
up-to-date. (Note that this has since been fixed[1]). I think for new
repository, standardizing on a name (either "debian/latest" or people's
liking) helps identify where the latest work goes to.

I find myself in this situation from time to time as well. However, I
disagree with your conclusion. At least for me, and I'm going to guess
for most contributors, I wouldn't reliably think to look for a
non-default branch at all unless I was doing something a little more out
of the ordinary such as preparing an update for a stable release; it
wouldn't really matter whether that branch was called debian/master or
debian/main or debian/sid or debian/latest. I usually work on the
assumption that the branch I get by "git clone" from Salsa is the one I
should be working on for the usual case of developing on unstable, and
since that assumption is nearly always correct, it saves me time and
energy over explicitly looking around for different branch names every
time I clone a repository (I work on a lot of different packages).

In the situation you outlined, it wouldn't have mattered to me one bit
whether the actual latest branch was called debian/sid or debian/latest;
I probably wouldn't have noticed it either way. What would have
mattered to me was that it wasn't the default branch (HEAD on Salsa).

So, rather than worrying about the _name_ of the default branch, I'd
like to suggest a change to DEP-14 that I think would have broader
consensus and be more useful.

Currently, there's only one place where DEP-14 talks about the default
branch: the "Native packages" section says "the default branch of the
repository (as pointed by the HEAD reference) should be a development
branch". I suggest that this recommendation should not be just for
native packages. The "For development releases" section should say that
the branch for uploads to the current development release of the
furthest-upstream distribution handled in a given repository (typically
Debian) should be the default branch, as pointed to by the HEAD
reference.

DEP-14 needn't prescribe exactly what the name of that branch should be,
and if it does then we should pragmatically regard it only as an
indication of what tools that _create_ Debian packaging repositories
should do. Renaming branches is intrusive (it still typically requires
manual action from anyone who has an existing clone and wants to pull
changes!), and so there can be no realistic expectation that existing
repositories will reliably change to follow a new suggested default
name.

[Xiyue Deng]

Hi Colin,

Post by Colin Watson

Post by Xiyue Deng
I would like to echo on this point. I had worked on a repository that
has the "master" branch marked as the default branch on Salsa, which
lacks many changes compared to the released version. I tried to
manually incorporate those changes, and only later found out that the
actual latest branch is "debian/sid" and it did have everything
up-to-date. (Note that this has since been fixed[1]). I think for new
repository, standardizing on a name (either "debian/latest" or people's
liking) helps identify where the latest work goes to.

I find myself in this situation from time to time as well. However, I
disagree with your conclusion. At least for me, and I'm going to guess
for most contributors, I wouldn't reliably think to look for a
non-default branch at all unless I was doing something a little more out
of the ordinary such as preparing an update for a stable release; it
wouldn't really matter whether that branch was called debian/master or
debian/main or debian/sid or debian/latest. I usually work on the
assumption that the branch I get by "git clone" from Salsa is the one I
should be working on for the usual case of developing on unstable, and
since that assumption is nearly always correct, it saves me time and
energy over explicitly looking around for different branch names every
time I clone a repository (I work on a lot of different packages).
In the situation you outlined, it wouldn't have mattered to me one bit
whether the actual latest branch was called debian/sid or debian/latest;
I probably wouldn't have noticed it either way. What would have
mattered to me was that it wasn't the default branch (HEAD on Salsa).
So, rather than worrying about the _name_ of the default branch, I'd
like to suggest a change to DEP-14 that I think would have broader
consensus and be more useful.
Currently, there's only one place where DEP-14 talks about the default
branch: the "Native packages" section says "the default branch of the
repository (as pointed by the HEAD reference) should be a development
branch". I suggest that this recommendation should not be just for
native packages. The "For development releases" section should say that
the branch for uploads to the current development release of the
furthest-upstream distribution handled in a given repository (typically
Debian) should be the default branch, as pointed to by the HEAD
reference.
DEP-14 needn't prescribe exactly what the name of that branch should be,
and if it does then we should pragmatically regard it only as an
indication of what tools that _create_ Debian packaging repositories
should do. Renaming branches is intrusive (it still typically requires
manual action from anyone who has an existing clone and wants to pull
changes!), and so there can be no realistic expectation that existing
repositories will reliably change to follow a new suggested default
name.

Thanks for your comments! I agree with you that with the improvements
on tooling (e.g. git), the default branch matters the most for avoiding
confusion.

However, there is an inconvenience if there is not a recommended default
branch name. When I switch among several projects, the default branch
name changes between "master", "main", "debian/master", "debian/latest",
etc., which is kind of distracting. I think recommending a name helps
to reduce this fragmentation in the long run. This may not be an issue
for experienced git user, but helps newcomers a lot.

Post by Colin Watson
--

[Rene Engelhard]

Hi,

Post by Otto Kekäläinen
I would be curious to hear why people are *not* adopting 'debian/latest'?
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?
Is it simply because git-buildpackage does not to default to 'debian/latest'?

I am maintaining a package which does only have debian/ in git, so gbp stuff does not really apply, but still.

People also asked about this for that one.  And got confused that master is sid.


So I am chiming it since rules which do not make real sense impose problems.


What should debian/latest be? The latest upstream (pre-)release? Aka what is in experimental? Or not even there,

just preparing stuff for experimental?

That would confuse people and waste peoples time.

People look up debian/latest and see stuff not relevant for sid where they ae working on/for. Especially on freezes where stuff still happens for experimental.

Or even worse, as follows:

"Latest stuff"? That would in my case be a version which will only be released in August and has not even have a pre-release yet. The alpha

will be in May only.

Because I usually do try to follow and do stuff well before so I am ready when it gets "hot".

(Ideally even uploading on the day of the release itself.)


And no, I am not doing "let's wait for X, then adapt, missing stuff here and there and waiting for some time to sort it out" thingy some maintainers seem to do.


debian/latest is bad here.


I use master for sid and anything else is branches.


Regards,


Rene

[Gioele Barabucci]

Post by Rene Engelhard
I am maintaining a package which does only have debian/ in git, so gbp
stuff does not really apply, but still.

Hi,

just for the record: gbp supports debian/-only repositories.

Just set `overlay = True` and `export_dir = ../build-area/` in
debian/gbp.conf and gbp will work as expected.

See, for example: https://salsa.debian.org/debian/findutils

Regards,

[Rene Engelhard]

Hi,

Post by Gioele Barabucci

Post by Rene Engelhard
I am maintaining a package which does only have debian/ in git, so gbp stuff does not really apply, but still.

Hi,
just for the record: gbp supports debian/-only repositories.

Just for the record, it does not.

Post by Gioele Barabucci
Just set `overlay = True` and `export_dir = ../build-area/` in debian/gbp.conf and gbp will work as expected.

***@frodo:~/***@frodo:~/Debian/Pakete/LibreOffice/libreoffice/libreoffice-25.2.0.3$ gbp buildpackage

gbp:error: /home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-25.2.0.3 is not a git repository


doing it in debian/:


***@frodo:~/Debian/Pakete/LibreOffice/libreoffice/libreoffice-25.2.0.3/debian$ gbp buildpackage --git-ignore-new
gbp:error: Can't determine package type: Failed to read changelog: [Errno 2] No such file or directory: './debian/changelog'

Post by Gioele Barabucci
See, for example: https://salsa.debian.org/debian/findutils

That is not a debian/-only repository, it has a README.md in  there and then a debian/ subdir.

debian/ only-repository here means that the content in debian/ is in git and debian is the git checkout.

(upstreams tarballs extracted + git checkout ... debian)


Here the example is (obviously) https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice


Regards,


Rene

[Otto Kekäläinen]

Hi Rene,

Post by Rene Engelhard
What should debian/latest be? The latest upstream (pre-)release? Aka what is in experimental? Or not even there,
just preparing stuff for experimental?

This is a good question, as it goes to the core of why DEP-14
recommends debian/latest first, respectively in the debian/unstable
and debian/experimental branches second (or at least I am think this
is why, I didn't write DEP-14).

In every git repository you need to have one default branch that
signifies what regular or occasional contributors should target with
their improvements. So from your three categories above, I would say
"preparing stuff for experimental" would be the best fit. Of course,
some of your uploads might go into unstable, hence DEP-14 authors
chose 'latest'. The branches are not to document what *is already* in
Debian, tags serve that purpose.

Think of it like this: If I want to contribute to Hunspell, one of
your packages, by fixing #528601 and writing a man page for munch, I
would clone your ***@salsa.debian.org:libreoffice-team/hunspell.git
and as it defaults to branch 'master', I would make my commit on top
of that, and either submit a merge request that suggest to merge the
man page into the 'master' branch (as it is the current default
branch), or I might send a patch via BTS, but that patch would apply
cleanly only on the 'master' branch as it was based off it. I would
also expect that if the man page for munch is *not* on the master
branch, then it means that nobody else has written it and solved the
bug yet.

I would most likely also run 'git add remote ottok
***@github.com:ottok/hunspell.git', switch to upstream real 'master',
git rebase on it and git push and submit the same man page upstream,
as upstream Hunspell is hosted on GitHub. Eventually we all probably
wish to have all generic improvements benefit everyone universally and
be upstrean, not just in Debian. In this scenario it would slightly
slow me down that I need to deal with two 'master' branches that have
the same files but are actually not of the same history.

I hope this helps to illustrate the purpose of 'latest', and also show
a scenario where having it called 'debian/latest' helps collaboration.
For the record, I am not asking you to change anything in Hunspell, I
just tried to make a good story by using a concrete example.

Post by Rene Engelhard
That would confuse people and waste peoples time.
People look up debian/latest and see stuff not relevant for sid where they ae working on/for. Especially on freezes where stuff still happens for experimental.
"Latest stuff"? That would in my case be a version which will only be released in August and has not even have a pre-release yet. The alpha
will be in May only.

Personally if I have some features that are not ready to be uploaded
for a long time, I would maintain them in a 'feature branch'. In some
cases that feature branch might live as a MR that is open for a very
long time. Or I might call it debian/experimental and upload to
experimental, but not merge to debian/latest until post early June in
the context of your question.

I hope this helps to illustrate the workflows.

[Rene Engelhard]

Hi,

Post by Otto Kekäläinen
I would
also expect that if the man page for munch is *not* on the master
branch, then it means that nobody else has written it and solved the
bug yet.

And exactly that assumption is wrong. (And contradicts what you say later, like in have a debian/experimental and merge it back late..)

Stuff which is in development upstream or in experimental exists, even if it is not in master.

Sometimes it's the version where stuff happens - like in freeze time where all stuff happens there since sid is (basically) frozen for anything not supposed to be for the release.

Post by Otto Kekäläinen

Post by Rene Engelhard
That would confuse people and waste peoples time.
People look up debian/latest and see stuff not relevant for sid where they ae working on/for. Especially on freezes where stuff still happens for experimental.
"Latest stuff"? That would in my case be a version which will only be released in August and has not even have a pre-release yet. The alpha
will be in May only.

Personally if I have some features that are not ready to be uploaded
for a long time, I would maintain them in a 'feature branch'. In some
cases that feature branch might live as a MR that is open for a very
long time.

But then it's not "latest". I would call whet is in experimental for libreoffice "latest". Especially next week when 25.2.0 will be released 25.2.0 is the "latest" upstream final release, and 24.8.x is not :)

Post by Otto Kekäläinen
Or I might call it debian/experimental and upload to
experimental, but not merge to debian/latest until post early June in
the context of your question.

And if it never ends up in sid for a release?

In your workflow described above people will  get confused why they get LO 25.2 instead of 24.8. That doesn't help for contributing to sids 24.8 package.


Regards,


Rene

[Simon McVittie]

Post by Rene Engelhard

Post by Otto Kekäläinen
Personally if I have some features that are not ready to be uploaded
for a long time, I would maintain them in a 'feature branch'. In some
cases that feature branch might live as a MR that is open for a very
long time.

But then it's not "latest". I would call whet is in experimental for
libreoffice "latest". Especially next week when 25.2.0 will be released
25.2.0 is the "latest" upstream final release, and 24.8.x is not :)

DEP-14 has naming schemes for two reasonable workflows, and I think a
lot of criticisms of it are assuming that one of them is the only one
and disregarding the other.

In the GNOME team we use debian/latest (the default branch in the git
repo) for the newest upstream version that we're packaging (whether
that's for unstable or experimental), and if necessary we create a
debian/trixie or debian/unstable branch for updates that target testing
and unstable while we already have a version in experimental. src:gtk4
and src:mutter are good examples. This is good if most of the package's
Debian maintainers are mostly focused on the development branch and
making few changes to the more-stable branch, or if the lifetime of a
development branch is quite short (6 months for GNOME).

When maintaining dbus and flatpak I use a different workflow, where the
default branch in the git repo is debian/unstable, and there's a parallel
debian/experimental branch for newer upstream releases that aren't
ready for unstable. At the moment both are inactive because the latest
upstream release of both dbus and flatpak is a stable 1.16.x release
(this is not coincidence, with my upstream hat on I made sure both would
be ready in time for trixie), but use of the debian/experimental branch
will resume as soon as we get a 1.17.0 development release. This is good
if the lifetime of the development branch is relatively long (generally
more like 1-3 years for dbus and flatpak), and bug fixing in the stable
branch is getting more Debian-maintainer attention.

Both workflows make sense, DEP-14 explicitly allows for both, and I think
it's an oversimplification to dismiss either one as never appropriate. Our
workflows should be as simple as possible, but no simpler.

It sounds as though, if you were using DEP-14 for LO, you would want
the workflow used in dbus and flatpak (with no debian/latest branch),
and not the workflow used in GNOME (with a debian/latest branch as
default). And that's fine! If I didn't think that was fine, I wouldn't
have chosen it for dbus and flatpak.

I think the debian/latest workflow (as used by the GNOME team) is a
better default to suggest to new maintainers, and a better default for
typical non-key packages where the upstream developer doesn't maintain
long-lived stable branches and the package doesn't usually have a
version in experimental. dbus is not a typical package; neither is LO,
and neither are things like gcc, systemd and the kernel. We should make
sure our policies accommodate these atypical packages, because many of
them are very important OS components, but we shouldn't necessarily let
them determine the defaults that we use for 90% of the archive.

I hope that makes sense?

I think this is an example of a wider design principle: defaults are
for the common case, and for inexperienced users (or in this case,
inexperienced developers) who have no basis for choosing whether they
want something non-default. It's OK if experienced users/developers
will often want to do something non-default to accommodate their more
complicated situation, because by the time they find themselves in that
more complicated situation, hopefully they're experienced enough to
make good decisions about how they will move away from the defaults,
and understand the cost vs. benefit of doing so.

smcv

[Mathias Gibbens]

Current https://dep-team.pages.debian.net/deps/dep14/ states that the

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.

I would be curious to hear why people are *not* adopting 'debian/latest'?

I'm strongly in favor of debian/sid (or debian/unstable, but hey,
that's more to type!) over debian/latest as the default git branch.

As others have pointed out, debian/latest is confusing -- what does
"latest" actually mean? Whereas, debian/sid gives an implicit hint that
these are things destined for eventual upload to unstable.

If I'm working on something that may not be ready for an upload to
unstable, I'll create a different branch which then may or may not get
merged into debian/sid.

When you also want to track packaging work for experimental, stable
updates, and backports it makes even more sense to have the default
branch be debian/sid, since you'll also have debian/experimental,
debian/bookworm, debian/bookworm-backports, etc in your repo. This
pattern has worked well for me thus far, and I intend to keep following
it.

Mathias

[Guillem Jover]

Post by Otto Kekäläinen
Current https://dep-team.pages.debian.net/deps/dep14/ states that the

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.

Post by Otto Kekäläinen
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. :/

Post by Otto Kekäläinen
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