Frederik Dannemare <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > http://qa.debian.org/developer.php?login=Frederik+Dannemare > http://frederik.dannemare.net | http://www.linuxworlddomination.dk MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
