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