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