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] 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 get rejected 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 Don Armstrong 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 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
