Re: 2 months and no upload for pkg
Daniel Pocock writes ("Re: 2 months and no upload for pkg"):
> There is one package I recently uploaded where I meant to use a
> repackaged tarball to get rid of an embedded binary toolchain JAR. This
> is a more nasty mistake of course but thanks to the diligence of the FTP
> masters it was spotted.
Perhaps you were just unlucky. If so then one REJECT out of many
ACCEPTs is not going to be a problem for you. If you were not just
unlucky then the expected error rate in your NEW uploads is too high.
It is your responsibility to fix that, not the responsibility of the
rest of the project to help you, or to deal with the fallout, or to
bear the costs of unnecessary re-review.
> This also brings up one other concern about a procedure that
> deliberately defers processing of some items in the NEW queue:
My proposal does not deliberately defer processing of any NEW items.
I'm proposing _prioritising_ NEW processing, biasing it in favour of
(a crude predictor of) packages likely to be ACCEPTed and therefore
likely to quickly improve Debian by their presence.
> it may give an advantage to derivative distributions that are
> cherry-picking the best things from NEW and appear to be getting
> them faster than Debian.
I don't understand why you think this is less likely to be a problem
with the packages that my proposal prioritises than with the packages
tht my proposal deprioritises.
It is true that long NEW processing queues is a big problem. But it
appears that a substantial amount of core team effort is being used to
deal with poor submissions. If we can fix that, we can fix the long
queue.
Ian.
Reply to: