Re: NEW processing
On Wed, 03 Dec 2008, Clint Adams wrote:
> I don't understand the logical connection here. IMO, NEW processing
> should be a rubber stamp,
It shouldn't need to be more than this, because packages shouldn't be
uploaded with problems that can be trivially identified at NEW
processing time. However, considering some of the rejects which have
recently been discussed here, that appears not to be the case.
> with only the checking required to satisfy whatever our needs are
> for liability purposes.
This is the minimum required check, I think; if ftpmasters want to
check more things and/or find more issues as they're doing this check,
more power to them.
It may be useful to consider:
1) balancing the length of the checks with the queue length and
available NEW processors
2) reducing the checks made on new binary packages (renames, removals,
and additions); libraries may be a special case
3) automatically rejecting new source packages from NEW with
un-overridden lintian errors; send mail on warnings suggesting a new
upload fixing them
4) identifying and/or educating uploaders who upload packages which
5) indicating the current status of a package in the queue and who is
checking it out
6) indicating who has been processing NEW packages so they get cookies
for doing this relatively thankless task
1: I'm not intimately familiar with NEW processing, so some of these
may already be being done.
An elephant: A mouse built to government specifications.
-- Robert Heinlein _Time Enough For Love_ p244