Re: Updated proposal for improving the FTP NEW process
Am Montag, den 05.03.2018, 14:27 +0000 schrieb Chris Lamb:
> Hi Gert,
>
> > (1) Given that all new source package come with an ITP bug, when a
> > package must be rejected, the FTP team could CC this bug in the
> > rejection message.
>
> Do you have any concrete suggestions for packages that are "Just
> Visiting" NEW, such as ones adding, say, a python3-foo, a -doc, a
> SONAME bump, first upload to experimental, etc. etc.? They do not
> have ITP bugs.
The only option I see for doing this in the BTS would be to ask the ftp
team to file the reject messages as a new bug against the source
package. I refrained from proposing this because this would mean filing
a bug against a package version that is not yet available in Debian.
Since the re-upload to NEW would have the same version like the version
the bug is filed against, the BTS might get a hiccup. For that reason I
originally proposed doing this with the salsa issue tracker.
Apart from that it is my experience that packages that do not introduce
new source packages usually pass NEW a lot faster, and are less prone
to errors that result in a reject by the FTP team.
> I have no real idea about the stats on this but my gut feel is that
> this applies to at _least_ half of packages that pass through NEW.
> (The current items in the NEW queue will be rather misleading on
> this point.)
Specifically targeted at the new SO-version case, Steve Robbins
proposed to reword the policy that *only* uploads that introduce new
SOURCE packages go through NEW.
I have to admid though, that I'm not sure whether this should apply to
all library packages. For instance another big package I co-maintain,
insighttoolkit4, introduces a new SO version at least every year, but
which each such version bump upstream also adds many files that may
have varying copyright that require an update of d/copyright. Giving
packages like this a free pass might not be such a good idea.
Best,
Gert
Reply to: