Micha Lenk writes ("Re: Summary of the current state of the tag2upload
discussion"):
> In general our traditional approach of handling source packages is,
> we upload upstream's source achive plus our modifications (patches)
> and instructions how to build it (the packaging). Our tooling
> (basically dpkg-source) reference all these from a Debian source
> control file, the .dsc file.
This is the "Debian source packages in 1993" slide from my 2023 talk.
This was true, once. Nowadays, for most packages, this is a pretence.
Most people maintain their packages in git. Many upstreams regard git
as canonical, and publish tarballs not at all, or only as a
concession. The proportion of software for which this is true is
steadily rising. Many teams (including of serious, important and
longstanding packages) work only in git. The Debian Xen team take
upstream signed git tags as their input and work entirely in git.
> From what I understood so far, the overall promise tag2upload tries
> to make is to simplify package maintenance to an extent that we
> offload the separation of the patches and the packaging from the
> upstream source to Git.
I don't think this is the right way to look at it.
tag2upload formalises and standardises and streamlines the *existing*
git-based workflows which are in use in Debian today.
It *does* make it easier to switch to using git, rather than
tarballs-and-patches, because it makes the git story better. But the
git transition is a separate thing, and most packaging teams are
already much of the way through it.
> In the tag2upload concept, the uploaded files referenced by the
> .dsc file and the .dsc file itself are implicitly considered a
> second class citizen of the Debian ecosystem
The tag2upload system is part of a *parallel* git-based system for
handling source code. The intent is that all source packages will be
available *both* ways (and can be edited using *voth* views).
So, yes, from the point of view of a maintainer using git,
tarballs-and-patches are secondary. But that's true already.
And, conversely, from the point of view of a maintainer using .dscs,
git is secondary.
Indeed, right now, git's existence is a kind of open secret. There's
VCS- headers and salsa and so on. Most people are working in git.
But it's not official.
What I am trying to do is put git on the same footing as .dscs: you'll
be able to use both, with the same level of fidelity and officialness.
> Still the tag2upload proponents dismiss a suggestion to also take
> changing the source format or tooling into account as an unfeasible
> "boil-the-ocean approach" (see [8]).
People have been thinking about changing source formats, or making
other kinds of more radical changes, for many many years.
Certainly since at least 2013, when Joey Hess and I and some others we
came up with a plan to improve things that we thought would be
workable and deployable, unlike the attempts (and suggestions) that
had been made so far. We've come a long way already, and
significantly improved some maintainers' workflows.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
