XPost: linux.debian.devel, linux.debian.policy   
   From: gwolf@debian.org   
      
   Simon Josefsson dijo [Wed, Feb 11, 2026 at 01:59:10PM +0100]:   
   >(...)   
   >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.   
      
   I agree on this. A tool should not be promoted as the only one right and   
   modern way to interface with the archive as long as it does not address   
   some widespread and useful use cases.   
      
   >(... several points I completely agree with ...)   
   >> "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.   
      
   I agree, I do not _love_ pristine-tar, but I do _use_ it. And I don't want   
   to ditch it just to try a new tool.   
      
   >> 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.   
      
   Maybe it is not particularly modern, but it is _vital_. And as long as we   
   have to teach newcomers to use a different tool whenever they need to do a   
   security upload, I cannot support having The Single Sanctioned Workflow™ to   
   be one that cannot be used. A different set of tools have to be learned by   
   our developers to do security support.   
      
   >> 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.   
      
   I do believe there is important value in having a human-readable,   
   human-oriented debian/changelog. Not all commits are of the same   
   importance, and having a document written so that readers understand the   
   main issues in a way that does not assume familiarity with implementation   
   details is important IMO.   
      
   Now, I know this is not an issue WRT git-debpush, it only highlights a   
   –again, IMO– minor nuance where a bit of usual practice has to be changed.   
      
   >> 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.   
      
   ...And that some maintainers do not keep their packaging in a VCS (and,   
   particularly, in Git). Yes, this is finally seen as a problem rather than   
   norm, but still...   
      
   >> 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.   
      
   Here, I disagree. I find DELAYED/DEFERRED a good, useful practice. It is a   
   good way to fix a bug in an NMU if you are not sure the package maintainer   
   is active and you don't want to keep the pending upload in the back of your   
   head for X days until you get an answer — uploading something to be done a   
   week from now is a good way to say, “I did the following changes and it   
   works for me™, feel free to roll it back before it reaches the public”.   
      
   I would love it if, for several of the last points, we lowered this notion   
   of “package ownership”. I would love that Debian held a culture where the   
   Maintainer/Uploader fields stated who is most likely to respond to issues   
   with packaging, but where every package would be a valid upload target for   
   all of us. But I know many people are not willing to embrace something that   
   strong.   
      
   -----BEGIN PGP SIGNATURE-----   
      
   iHUEABYIAB0WIQRgswk9lhCOXLlxQu/i9jtDU/RZiQUCaYy63wAKCRDi9jtDU/RZ   
   iWKlAP9HpegKGeQivL2PyD2uzYflT7W0gFld+fWuOQLabSvsIQEA/B1SF6yOhkZk   
   9f8cFppfVuwLGCwdesqJ2A7AjDU4uwY=   
   =3/8K   
   -----END PGP SIGNATURE-----   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)