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
http://developer.skolelinux.no/~pere/debian-NEW.html
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
MfG
Goswin
Reply to: