Bug#1127616: developers-reference: should document using git-debpush to upload

On Wed, Feb 11, 2026 at 08:52:04PM +0100, Simon Josefsson wrote:
>The Python Team's Policy insistance on use of pristine-tar and throwing
>away upstream git history is [1]:
>
>   DPT requires a pristine-tar branch, and only upstream tarballs can be
>   used to advance the upstream branch. Complete upstream Git history
>   should be avoided in the upstream branch.

Well, for my own packages I insist on including upstream git history, so 
this certainly wasn't my choice, and it was before my time on the DPT.  
However, I suspect that it was a pragmatic choice to make it even 
slightly practical to maintain several thousand source packages in a 
more or less uniform structure despite the upstreams using a pretty wide 
variety of code hosting mechanisms and practices.  IIRC there are still 
quite a few packages that use something other than git or that have no 
public git repository, and there are definitely plenty where the 
upstream maintainer seems to pay more attention to what's on PyPI than 
what they've tagged in git (e.g. they don't bother to push tags).  The 
big popular packages usually work the way you'd expect, but there is a 
significant long tail.

We already have an almost impossible amount of work to do just keeping 
up with ecosystem-wide changes (sure, there's been nothing even remotely 
on the scale of the Python 3 transition for a long time, but small 
probabilities of being affected by any given breaking change multiplied 
by thousands of packages still mount up quickly).  Despite understanding 
the downsides of the current team policy, I for one have absolutely no 
appetite or capacity for yet another thing that requires us to go around 
and reorganize everything.  dgit/tag2upload doesn't require us to do 
that; it can slot into our existing workflows, and not all team members 
even have to agree.

>The pypi.debian.net man-in-the-middle upstream tarball redirector is the
>recommended (?) debian/watch URL to use for Python packages [2].

We've been gradually moving away from this in some cases in favour of 
pointing to forge-generated tarballs, but it varies somewhat.  There is 
no one approach that works for all Python packages:

  * Source distributions ("sdists") pushed to PyPI are technically a 
    build product of the upstream source tree, and sometimes they don't 
    include all the files we need - for example, omitting tests is fairly 
    common, as is trying to include tests but omitting some of the data 
    files they need.  And some upstreams only publish wheels to PyPI and 
    not sdists.

  * On the other hand, it's also fairly common to run into packages where 
    upstream uses something like submodules, and so the forge-generated 
    tarballs will be incomplete and basically useless.  So will pointing 
    directly to upstream git tags unless you mess about with multiple 
    components.  In those cases the sdists on PyPI usually work fine and 
    are much less hassle.

So sure, the situation is not ideal.  But it might be worth walking a 
mile in our shoes first.