On 09/05/25 at 10:27 +0200, Andreas Tille wrote:
However, I have doubts about (4), since there's still so many different workflows to use Git+Salsa.
Which brings us back to DEP-14 as a baseline recommendation that canErr, the current state of things is that DEP-14 is still in CANDIDATE
help reduce friction. While individual workflows vary, having some repository is a precondition for any collaboration--and DEP-14 provides a neutral, widely accepted starting point.
state, and I read the last thread on this topic as unconclusive[0].
However, I have doubts about (4), since there's still so many different workflows to use Git+Salsa.
Which brings us back to DEP-14 as a baseline recommendation that can
help reduce friction. While individual workflows vary, having some
repository is a precondition for any collaboration--and DEP-14 provides a neutral, widely accepted starting point.
On Fri, May 09, 2025 at 12:43:54PM +0200, Lucas Nussbaum wrote:
On 09/05/25 at 10:27 +0200, Andreas Tille wrote:
However, I have doubts about (4), since there's still so many different workflows to use Git+Salsa.
same here.
Which brings us back to DEP-14 as a baseline recommendation that canErr, the current state of things is that DEP-14 is still in CANDIDATE state, and I read the last thread on this topic as unconclusive[0].
help reduce friction. While individual workflows vary, having some repository is a precondition for any collaboration--and DEP-14 provides a neutral, widely accepted starting point.
that, both, plus the fact that DEP-14 does not recommend one specific workflow, but several.
I would love to see data about the actual acceptance of DEP-14 among
packages in the archive: my feeling is that it is currently being a bit ignored by maintainers and teams (but maybe I'm wrong).
So, it looks like among the largest packaging teams, only the go team,
the gnome team, and the php team have significantly adopted DEP-14.
Note that this is not a criticism of DEP-14, only an attempt at
providing numbers about DEP-14 adoption.
On 09/05/25 at 12:43 +0200, Lucas Nussbaum wrote:
I would love to see data about the actual acceptance of DEP-14 among packages in the archive: my feeling is that it is currently being a bit ignored by maintainers and teams (but maybe I'm wrong).
I started working on a salsa importer in UDD. It still needs some
polishing and Web pages to expose interesting results, but it already provides the following information:
* 37641 source packages in trixie/main
* of which 36083 declare a VCS URL
* of which 34644 point to a salsa project
* of which 34370 point to a salsa project that exists
.. grouped by salsa group:
salsa_group | count
--------------+-------
debian | 4255
perl-team | 3963
rust-team | 2970
python-team | 2703
go-team | 2338
js-team | 1677
r-pkg-team | 1159
java-team | 1089
ruby-team | 1054
haskell-team | 957
.. grouped by default branch:
default_branch | count
-----------------+-------
master | 24467
debian/master | 2569
debian/latest | 2480
debian/sid | 2160
debian | 561
debian/main | 522
debian/unstable | 512
debian/epoxy | 450
main | 338
debian-unstable | 117
Looking at the DEP-14 compliance of the above:
default_branch | count
-----------------+-------
master | 24467 ; not DEP-14-compliant
debian/master | 2569 ; not DEP-14-compliant, but shares the idea of
using <vendor>/ branches
debian/latest | 2480 ; DEP-14-OK
debian/sid | 2160 ; DEP-14-OK but not recommended (debian/unstable would be)
debian | 561 ; not DEP-14-compliant
debian/main | 522 ; not DEP-14-compliant, see debian/main
debian/unstable | 512 ; DEP-14-OK
debian/epoxy | 450 ; not DEP-14-compliant (this is used by the
openstack team)
main | 338 ; not DEP-14-compliant
debian-unstable | 117 ; not DEP-14-compliant
So that leaves 2480+2160+512=5152 source packages using a DEP-14 default branch.
They are maintained by the following salsa groups:
salsa_group | count_dep14 | count_total ------------------------+-------------+-------------
go-team | 1491 | 2338
debian | 980 | 4255
python-team | 333 | 2703
gnome-team | 321 | 329
perl-team | 268 | 3963
php-team | 211 | 268
multimedia-team | 152 | 606
homeassistant-team | 120 | 435
science-team | 74 | 856
DebianOnMobile-team | 74 | 83
pkg-octave-team | 72 | 73
js-team | 55 | 1677
games-team | 53 | 506
ruby-team | 51 | 1054
fonts-team | 48 | 393
lxqt-team | 48 | 48
swaywm-team | 27 | 31
virtualsquare-team | 26 | 26
java-team | 25 | 1089
So, it looks like among the largest packaging teams, only the go team,
the gnome team, and the php team have significantly adopted DEP-14.
Note that this is not a criticism of DEP-14, only an attempt at
providing numbers about DEP-14 adoption.
Lucas
I have published similar stats before and I ran a large "poll" on this >mailing list with subject "DEP-14: Default branch name 'debian/latest' >objections?" to find out what the objections are. My take is that a
vocal minority with very strong opinions prevent Debian from landing
on a default Debian branch name.
Once we have a decision, Guido is more likely
to support making that decision the default in git-buildpackage, and
the people who previously migrated from master to debian/master or
debian/sid (while the historic DEP-14 suggested them) are more likely
to change to the final branch name. With this everything would most
likely converge.
On Sun, May 11, 2025 at 02:35:14PM -0700, Otto Keklinen wrote:
Once we have a decision, Guido is more likely
to support making that decision the default in git-buildpackage, and
the people who previously migrated from master to debian/master or debian/sid (while the historic DEP-14 suggested them) are more likely
to change to the final branch name. With this everything would most
likely converge.
I think this significantly underestimates the annoyance involved in renaming existing long-lived branches (in that all clients have to re-clone or manually adjust), which is certainly why I generally avoid doing so unless I absolutely have to.
...I think this significantly underestimates the annoyance involved in renaming
existing long-lived branches (in that all clients have to re-clone or manually adjust), which is certainly why I generally avoid doing so unless I
absolutely have to.
This could even be something that gbp is aware of (maybe by a
configuration option which can be placed in gbp.conf, perhaps named
something like 'old-debian-branch') which it then warns the user about
when the two branch pointers aren't pointing at the same commit. Or
something like that.
While this is accurate considering the latest DEP-14 version, it
should be noted that the first DEP-14 draft allowed 'master' as the
main branch for native packages and up to 2020-11-29 DEP-14
recommended debian/master instead of debian/latest.
Earlier adopters (like me) thus probably don't follow the latest
changes to DEP-14 because what's the point of renaming a perfectly
fine branch.
On 09/05/25 at 12:43 +0200, Lucas Nussbaum wrote:
I would love to see data about the actual acceptance of DEP-14 among packages in the archive: my feeling is that it is currently being a bit ignored by maintainers and teams (but maybe I'm wrong).
I started working on a salsa importer in UDD. It still needs some
polishing and Web pages to expose interesting results, but it already provides the following information:
* 37641 source packages in trixie/main
* of which 36083 declare a VCS URL
* of which 34644 point to a salsa project
* of which 34370 point to a salsa project that exists
[...]
* 37641 source packages in trixie/main
* of which 36083 declare a VCS URL
* of which 34644 point to a salsa project
* of which 34370 point to a salsa project that exists
[...]
This is now available at https://udd.debian.org/cgi-bin/dep14stats.cgi
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 47:34:07 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,066 |
| Messages: | 6,417,282 |
| Posted today: | 1 |