Micha Lenk writes ("Re: Summary of the current state of the tag2upload
discussion"):
> Am 23.06.24 um 20:32 schrieb Ian Jackson:
> > Most people maintain their packages in git. Many upstreams regard git
> > as canonical, and publish tarballs not at all, or only as a
> > concession. [...]
>
> Yet our tooling and official workflows don't work that way.
That's precisely the problem.
> > tag2upload formalises and standardises and streamlines the *existing*
> > git-based workflows which are in use in Debian today.
>
> Okay, but couldn't the existing git-based workflows get formalized and
> standardized without changing the way how you upload to Debian? Why is
> it so important to tie the support for so many workflows to the method
> how the upload is done?
Because of our users (and downstreams) !
We're supposed to publish our source code. The point of Debian being
Free Software isn't just so that *we* can share and modify the code.
Our users must be able to do so too. They must be able to take the
work that we have done, and modify it in turn, and share their
modifications with others. This should be convenient and easy.
For packages where upstream works in git, we should *definitely* be
providing our users with git too. Otherwise we have inserted
ourselves (and our ancient and crazy tooling) as a barrier between the
user and the upstream.
So we must publish the git history. Precisaely the source that's also
available as a .dsc in the archive. Officially. In a standard place.
In a standard form; ideally, a form similar to what a
non-Debian-export would expect.
> > 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.
>
> It is possible that I don't have all the needed background here. Would
> you mind to share a few pointers that outline how these plans worked
> out? I am genuinely interested in anything that could explain to me why
> any previous attempts of making Git a first class citizen in the Debian
> ecosystem didn't succeed so far. This could help me to get a better
> understanding of your long way, and maybe shed some light on why you're
> insisting so starkly on some of the tag2upload design decisions.
I'm afraid I don't have references to all those other ideas.
If you have read these whole giant threads, you'll have seen various
people proposing ideas which seem like they would be much simpler and
have fewer moving parts. You'll also see responses pointnng out
(variously) that these schemes tend to involve everyone having to
change their git workflow, or even more radical changes the way
everyone in Debian handles source code.
The best I can do is probably just to say that almost all of those
ideas have been suggested before. Most of them were around in 2013,
or earlier. Many of these ideas are fairly obvious.
Some of these ideas are quite good, if we could see how to get there
from here, both socially and technologically. But Debian and its
ecosystem is huge and diverse. That's one of Debian's big strengths;
where we have imposed uniformity it has usually involved pain and
suffering.
Mostly these ideas just stayed as ideas; in some cases some parts were
implemented. Eg, dpkg-source's "3.0 (git)" source package format,
which is not supported in Debian.
The parts of "do Debian work in git" that *have* been implemented and
deployed are precisely the parts that can be deployed *without*
everyone having to change.
There has been an enormous amount of work by, for example: the author
of git-buildpackage; the operators of first Alioth and now Salsa;
the authors and maintainers of other Debian git tools such as git-dpm
and git-debcherry; etc. (My own git-debrebase tool fits in this list.)
That work, by so many people, has been a great success!
The work of the typical Debian maintainer is nowadays much, much,
easier than it was in 1993. Thanks to everyone who has contributed to
this revolution!
The problem remains, though, been that it's not official and
systematised. The resulting chaos is a particular problem for our
downstreams and users. [1] This situation is not the fault of any of
the people involved. It's just a piece of work that hasn't been done
yet.
That task is what we're trying to achieve, with tag2upload.
Like the parts of this picture that have come before, tag2upload is
deployable because it doesn't involve forcing change on everyone. Not
only does that make it technically and politically possible, but it is
is a kind way to go about introducing such a change. That is very
important to me.
Ian.
[1]
For an picture of how bad the situation is, see this article by
me, aimed at our users:
https://diziet.dreamwidth.org/9556.html
Get source to Debian packages only via dgit; "official" git links
are beartraps
--
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.
