On Mon, 05 Mar 2018 at 14:27:31 +0000, Chris Lamb wrote:
> > (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.
In principle there'd be nothing to stop us from having a policy that
NEW packages must close a bug that justifies the split/rename, even
if that bug is Severity: wishlist and was opened by the maintainer?
(e.g. "should have Python 3 version", "should split out documentation"
or "new upstream version" - although in some cases it would be annoying
for maintainers to have to wait for the BTS to send back a bug number
before they could upload.)
Another possibility would be for these packages to not get a
copyright/licensing check, just a sanity-check that their package names
are not polluting the package namespace any more than they were already.
Are binary-NEW packages more likely to violate the DFSG than randomly
chosen packages? I'm not a ftp team member, so I don't have the overview
you do; but in my experience, undermaintained packages rotting in the
archive seem to be *more* likely to have copyright/licensing issues than
actively-maintained packages that get uploaded and might have to pass
through binary-NEW, if only because ftp team review has got more careful
over time, so undermaintained packages were probably accepted under a less
careful regime. If the goal is to trigger periodic copyright/licensing
review of already-accepted packages, perhaps that should be orthogonal
to protecting the package namespace, and should act on packages in the
archive regardless of whether they are binary-NEW or not?
(In general, as I've said before, I think we are probably creating
more copyright/licensing work for ourselves than we really need to,
and I'd be pleased to see the burden placed on both the ftp team and
maintainers reduce.)
> first upload to experimental
Is this a thing? I wasn't aware that the first upload to experimental
for a package that was previously only in unstable triggered a visit to
NEW. (Although when I've uploaded to experimental for the first time, it
has often been to break out a separate binary package without blocking
unstable, so it would have gone to NEW anyway.)
smcv
