Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]
On Tue, Jul 09, 2019 at 01:33:49PM +0100, Sean Whitton wrote:
> Hello,
>
> On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote:
>
> > I would go even further and drop the (manual) NEW queue for binary-NEW
> > packages.
> > Is there a good reason why new binary packages need manual processing by
> > the FTP team? Couldn't this be fully automated?
>
> The three things the FTP team check[1] are worth doing again for
> binary-NEW packages. In order: there are often lots of new files in an
> upload that ends up in binary-NEW so there might be licensing issues; a
> new binary package means a new member of the binary package namespace;
> it's good to have a second pair of eyes look at your SONAME bump etc.
>
> [1] https://ftp-master.debian.org/REJECT-FAQ.html right at the top
>
I've always wondered about this.
Why is it, then, that binary-NEW still applies if there have been no
source files added/removed? (A SONAME bump possibly being necessitated
by some change that does not involve adding/removing/renaming source
files.)
Following on that, what about a package that does add/remove source
files (perhaps many) without a SONAME bump or other change that results
in a new binary package?
It seems like reviewing the package name space on introduction of a new
binary package and an additional review of a SONAME bump are good things
and the binary-NEW criteria seem to fit. However, the "there might be
new source files with licensing issues" does not seem to be a good fit
for binary-NEW criteria. Not to say that it matters much in the context
of binary-NEW. But if catching potential licensing issues associated
with large source changes is in fact something which the FTP team wishes
to be able to do, it probably warrants a different filter than "adds a
new binary package to the archive" in order to be effective.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: