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
