Re: list what's in the NEW queue?
On Thursday 03 February 2005 16:05, Wouter Verhelst wrote:
> Op do, 03-02-2005 te 15:44 +0100, schreef Frederik Dannemare:
> > On Thursday 03 February 2005 14:45, Steve Langasek wrote:
> > > Increasing the rate at which new packages flow into unstable is
> > > NOT something that should be a priority when we're trying to get
> > > the RC bug count down in preparation of a release. Show me that
> > > there are enough people working on release-critical issues for
> > > sarge,
> >
> > You're probably right there's not.
>
> Parse error.
:-)
I meant to indicate that: no, I cannot show that enough people are
working on rc bugs.
> > > which
> > > requires no imprimatur from the DPL, before you start throwing
> > > packages that have never even been tested by their maintainer at
> > > us faster than we already get them.
> >
> > I see your point if it is really the case that uploads are being
> > done without proper testing from the maintainer himself/herself.
>
> His point is still valid even if all maintainers do proper testing.
> You can't be expected as a maintainer to be able to test /every/
> possible or impossible situation in which a package could be used.
> And then I'm not even talking about packages that should conflict
> with eachother but don't, because the maintainer of the new package
> didn't know that a file in his package happens to have the same name
> as a different file in a completely unrelated package...
True, but why would it necessarily affect sarge? The maintainer (and
others) would soon discover the problem of conflicting files and a rc
bug would be filed, thereby preventing the issue from entering sarge,
right? Speaking of this, I actually had a package last week involved in
this very situation, and it never came to be a sarge rc issue.
But, yes, I do understand there may be many other concerns as well. I
just wish /somehow/ there was different handling of new packages
depending on their "expected" impact. I realise this would require a
lot of extra work if done manually. Maybe it could be (semi-)automated
somehow by checking against different aspects of a package. E.g. if an
incoming package has Priority: optional - Section: Games - Impact: low
(new fantasy field) and only a single binary + man page, then this
package slips into the LOWIMPACT NEW queue which requires no further
(nor manual) invervention. Other more 'dangerous' (potentially)
packages would be dispatched to a HIGHIMPACT NEW queue for further
examination by the ftp-masters.
Yeah, wishful thinking, I know. But that the same time it is not
optimal, IMHO, that extremely trivial or 'very low impact' packages get
stuck in a huge queue. Take something akin to a mozilla-firefox-locale
package or my mcdp package, for instance.
Best regards,
--
Frederik Dannemare | mailto:frederik@dannemare.net
http://qa.debian.org/developer.php?login=Frederik+Dannemare
http://frederik.dannemare.net | http://www.linuxworlddomination.dk
Reply to: