On Mon, 19 Aug 2024 at 22:42:53 -0700, Otto Kekäläinen wrote:
> ## How many packages have a 'upstream-vcs-tag' and what is it typically?
Unlike most of the other questions you asked and answered (thanks!) we
should never expect this to be consistent, because it isn't Debian's
decision: it's upstream's decision what they will name their tags.
The only decision we can make here as Debian packagers is whether to use:
1. a workflow where upstream/latest contains the same commits as
upstream git (like src:mesa);
2. a workflow where upstream/latest contains imported tarball snapshots,
*without* upstream git history merged in (like src:libsdl2);
3. a workflow where upstream/latest contains imported tarball snapshots
*with* upstream git history merged in, most likely via upstream-vcs-tag
(like src:glib2.0)
and the total number of upstream-vcs-tag is effectively counting (3.) (and
possibly some of (1.)).
I'm surprised the number your statistics give for (3.) is such a small
proportion: I find this workflow really useful as a way to reconcile
devref 6.8.8.1's assertion that pristine upstream tarballs are important
with the desire to have upstream git history readily available to make
maintenance easier.
The main reason I don't use upstream-vcs-tag in all the packages I
maintain[1] is that some upstreams have non-DFSG or not-obviously-DFSG
content in their VCS, and as a project we can be very uncompromising about
the application of the DFSG, so using a non-ideal workflow is less of a
concern to me than the prospect that the project might decide that the
upstream VCS is insufficiently Free and demand that the packaging history
is destroyed and re-created.
smcv
[1] other than the usual exceptional cases like packages not maintained
in git upstream, or very large data packages
