[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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://frederik.dannemare.net | http://www.linuxworlddomination.dk

Reply to: