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

Re: list what's in the NEW queue?

Frederik Dannemare <frederik@dannemare.net> writes:

> 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. 

All truely new packages could be put into experimental.

> 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. 

Maybe some more transparency for the NEW queue would also shed a
better light on the situation. There are package in NEW that are very
old and skiped several/many NEW runs without getting accepted or
rejected. Some might even be orphaned by their uploaders by now.

It could be helpfull if the inofficial NEW listing on
could list a progress status like: "license problem, needs fix" for
mplayer or "suspicious at first glance, needs second look" if
something didn't make it on a NEW run directly.

At least I would like to know whats up with mplayer now that ffmpeg is
in Debian.

> 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: