Hello, Holger Levsen [10/Feb 3:11pm GMT] wrote: > as I said on the thread on -devel, there are at least two annoying bugs in > tag2upload which make me not want to use it yet and which I think also > prevent suggesting to use it to everyone in all cases. > > (to repeat: a.) impossible to do -1 uploads while preserving existing signed > upstream tarballs and b.) loosing the information that an upload was > sponsored.)
Thanks. Let me respond to each of these:
(1) The vast majority of upstreams that newcomers are likely to
encounter do not produce tarballs. Instead, they push signed git
tags, and let GitHub/some other forge publish automatically
generated tarballs for those that want them.
It makes no sense to privilege these automatically generated
tarballs. Rather, we should care about the tags the human
maintainers sign, which is exactly what tag2upload does.
There are upstreams that produce signed tarballs and Debian
maintainers who are keen on us archiving all those. But those are
overwhelmingly packages maintained by our existing experienced
developers, who wouldn't be reading this text anyway.
So, as one relatively old-timer to another, I would ask you to try
to put yourself in the shoes of newcomers and the upstream projects
they tend to want to package for Debian when thinking about this.
It's also the case that we often repack tarballs to remove
DFSG-incompatible files, which changes the checksums anyway.
(2) This is #1116530. I understand your concern here. It's unfortunate
that the code generating the relevant web view has not been updated
yet. At the same time, tag2upload has already processed hundreds of
uploads, and we can expect the uptake to only steadily increase from
here. So we are going to have this problem until the bug is fixed
no matter whether dev-ref changes. Therefore, I don't think it
makes sense to block updating dev-ref on this.
> and there are more limitations to tag2upload as you've described in your
> patch,
> which I think are additional reasons not to suggest tag2upload by default for
> everyone, but rather as a special workflow for people who want to experiment
> (and/or use) it.
>
>> +To perform a source-only upload, use the ``git debpush`` program.
> [...]
>> +package maintainers perform. However, there are some cases in which a
>> +source-only upload is possible but ``git debpush`` cannot be used:
>
> ^^ this is what I ment in my last paragraph.
You're right that there are a number of cases we can't handle, but what
you didn't quote here is my sentence
``git debpush`` covers the vast majority of source-only uploads that
Debian package maintainers perform.
which is true. The exceptions really are exceptions -- many, perhaps
most Debian package maintainers will never encounter them.
Of course, I wanted to update our docs with all the relevant cases, so I
described them. But that doesn't change the fact that a general
recommendation to do source-only uploads with 'git debpush' will suit
most contributors just fine, and especially new contributors.
--
Sean Whitton
signature.asc
Description: PGP signature
