XPost: linux.debian.devel, linux.debian.policy   
   From: simon@josefsson.org   
      
   Holger Levsen  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   
      
   --=-=-Content-Type: application/pgp-signature; name="signature.asc"   
      
   -----BEGIN PGP SIGNATURE-----   
      
   iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmmMfR4UHHNpbW9uQGpv   
   c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f   
   V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z   
   ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh   
   BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA   
   /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx   
   +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx   
   I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0   
   +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R   
   cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE   
   8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J   
   ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6   
   qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB   
   BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA   
   JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF   
   PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh   
   is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFosQTAQDKO+Jl2CUj   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)