Holger Levsen <[email protected]> writes: > I believe you that, but what I think you don't get is that due > https://wiki.debian.org/tag2upload#Not%20supported I still need > to be able to do uploads the traditional way and believe it or > not, but my tooling for traditional uploads is already there that > I can do traditional uploads super fast and super easy. > > This, and given I have other stuff to do and limited spoons to learn > new stuff, doesnt give me much incentive to try 'git debpush'. > > Why should I bother learning a new thing which only works for some things > I need it, thus increases my mental load and increases the complexity of > already > very complex stuff and only has little benefit to most of my workflows?
I share these concerns (and was late to adopt gbp for similar concerns), but I have migrated to use tag2upload significantly because it offers a way for me to FORGET about all the old workflows, which would decrease my mental load and reduce tool complexity for us all. All the things on the "Not supported" ways can be considered bugs elsewhere -- thus I think the title of that section could be changed to "Design limitations" or similar instead. Analyzing them in turn: > "Uploads to NEW (even if only binary-NEW), because for those ftp.d.o > currently demands maintainer-generated binaries." Why on earth are we accepting maintainer-generated binaries into the archive in 2026? Yes, I know several reasonable answers to that question, but they don't resolve the concern with maintainer-generated binaries. NEW uploads should be permitted to be source-only. For bootstrapping or circular dependencies that more deeply require binary uploads, let's please design a proper solution instead. > "pristine-tar: With a new upstream version, tag2upload will generate a > fresh orig tarball with git archive (via git-deborig). This is OK, but > it may surprise some users. 1106071." This is probably the toughest nut, and is mostly a matter of opinion if pristine-tar is a good pattern and offers anything useful. I used to be a big supporter of pristine-tar, but I'm now neutral. Pristine-tar doesn't offer the strong security properties or features that I thought it did, and comes with a large storage and transfer cost. > Uploads to security-master. This is difficult: 862105. TBH I have no idea about this one, but I suspect the security-master upload workflow isn't particular modern. > Uploads to backports where your workflow involves throwing away the > changelog entries for previous backports. I.e. if you start fresh for > each version from testing you backport. If you do something like git > checkout debian/bookworm-backports && git merge debian/latest and then > resolve the debian/changelog merge conflict so as to preserve all > entries, then it works (1109584). The special debian/changelog handling for backports has always seemed odd to me. I think having in-package changelog files are increasingly becoming an obsolete pattern, for the same reasons ChangeLog files are now less relevant. > NMUs that don't use the package maintainer's git repository, and git > workflow, aren't likely to work well. Instead, use dgit, which offers > a completely uniform git-based NMU workflow. Doing NMUs without pushing to maintainer's repository leads to a mess that is frustrating to clean up from (look at some NetKit packages), and the only reason why anyone would ever do that is because some maintainers protect commit access to their packaging. Which is a real problem. > DELAYED/DEFERRED uploads (1123680). I think the concept of DELAYED/DEFERRED, like NMUs, are historic ways of working which today have better methods: bug-reports, merge requests, Salsa pipelines, Debusine uploads, or mailing-list discussion. /Simon
signature.asc
Description: PGP signature
