Re: Nitpicking in the NEW queue.
Raphael Hertzog <email@example.com> writes:
> On Tue, 03 Sep 2013, Luca Falavigna wrote:
>> 2013/9/3 Paul Wise <firstname.lastname@example.org>:
>> > Reading Charles' mail I had a thought; how about accepting buggy
>> > packages (unless the issues make them non-distributable) and file RC
>> > and other bugs if there are DFSG or other issues?
>> Although this could be possible, a second upload would be needed
>> anyway (hopefully in a very short timeframe), so reuploading a fixed
>> package to NEW would avoid wasting bandwith and disk space on mirrors
>> and snapshot.d.o.
>> Usually, rejected packages are fast-tracked when reuploaded to avoid
>> letting them slip at the bottom of the queue. Simply reply to
>> rejection mail (or ping us in IRC) informing us a fixed package has
>> been reuploaded to the NEW queue.
> This is not a good trade off. You're loosing out valuable ftpmasters time
> for minor bandwith and disk issues (that kind of supplementary upload will
> not change much in the global amount of bandwith and disk consumed).
> I find pabs's idea rather good. And if you really care about a second check,
> you can do that once you get the bug closure notification.
I disagree. A second review by the same ftpmaster is usually fast and
painless and requires less time and effort overall than doing the bug
handling dance. I've done both, and my experience so far was that
REJECT+reupload worked much better in most cases.
That it also keeps the archive a tinsy bit cleaner is just an added