Simon Richter writes ("Re: [RFC] General Resolution to deploy tag2upload [and 1
more messages]"):
> I think we cannot increment ourselves into a good solution here.
We certainly can improve things a long way. That's what we're doing.
The way to do a big transition is to write a gateway, and then
gradeually move interfaces to the new way of doing things.
But you're right that there's an underlying hard problem.
Right now there isn't *any* really good solution to the problem of
maintaining a long term delta queue, as a downstream.
That is the core problem which is addressed by gbp pq, by
git-debrebase, by git-dpm, by git-debcherry, by stgit, and in own its
way by dpkg-sources's `3.0 (quilt)`.
But tag2upload *does* significantly improve each of our existing
git-based approaches, and enables future improvements. It *will*
enable leaving cruft behind:
> There are lots of other problems with the various mappings in use, each
> makes different trade-offs. Accommodating them all inside tag2upload is
> an ab-initio commitment to technical debt.
It's certainly not. We are already saddled with that debt.
tag2upload doesn't help pay it all off, only some of it.
Nevertheless, tag2upload does represent a bet about the future.
It represents a bet that the hypothetical answer to our prayers (for a
really good way to handle maintaining and rebasing and sharing a delta
queue) won't be based on tar and patch and diff.
It represents a bet that that answer looks enough like a fast
forwarding git branch that we can store it in existing git
repositories and share it using existing git tooling.
It represents a bet that if it is not precisely git, but maybe
something on top of git, it's close enough in model to a git branch,
or a a signed git tag, that we can reuse much of the data model and
much of the code.
Almost all of the somewhat-clumsy answers we have already to this
problem have these properties. So that bet seems a good one to me,
a decade or so after I first made it in the context of dgit.
It's true that there's a fair amount of code in tag2upload to deal
with the different workflows. Most of that is to do with *source
packages*, not git representations. The pure-git representations
generated by fully git-based tooling are generally tractable. But, to
an extent, that code represents a bug that the marvellous downstream
delta queue tool won't appear, and become ubiquitous, tomorrow.
(Even, tomorrow in Debian terms.)
But the real difficulty comes when importing a .dsc from the
archive, and then modifying it in git, and wanting to re-upload it.
This is something tag2upload wants to support. But it's hard because
the varieties of nonsense you can upload as a source package are quite
astonishing, and that makes a bidirectional gateway hard.
Nevertheless, we have solved that problem. I think it was worth doing.
Debian hasn't abolished source package uploads and `quilt (3.0)`
in the last 10 years, and we won't in the next 10 either.
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.
