On Wed, Dec 03, 2008 at 03:41:29PM +0200, Kalle Kivimaa wrote: > Then, if you've also made sure that you don't get any lintian warnings > and your debian-directory is clear (especially debian/rules), the whole > process is pretty painless.
I submit that lintian warnings are entirely out of scope for the task the project has entrusted to the ftp team, and that mentioning this at all as a factor in making the NEW queue "painless" indicates there's a problem with the process as implemented. - lintian *warnings* are those points that even the lintian maintainers are not confident are always indicative of bugs. There's really no reason for the ftp team to look at these as a condition for NEW acceptance. - Even with lintian errors, there are many that are definitely bugs but which should not be grounds for a reject from the archive because they're *minor* bugs, and the ftp team should not be in the business of enforcing lintian cleanness as a condition of acceptance into the archive because this is (and always will be) a false measure of package quality.[1] - To the extent that bugginess tests are enforced by the ftp team, they should be *symmetric*. If a bug wouldn't be grounds for kicking the package out of the archive, it also shouldn't be grounds for the ftp team to block it from reaching the archive. Anything else is a waste of time, both for the ftp team (who then have to do multiple reviews of a package for trivial bugs) and for the maintainer (who has to reprioritize their package work according to artificial, externally imposed rules in order to accomodate the queue processing requirements), and it gets in the way of real-world feedback from actual users of the package. If the ftp team have the time and are inclined to give packages more than the minimum review on the way through NEW, that's great! More QA, and more eyeballs, are always to our benefit, and if maintainers are generally failing to use lintian on their own packages that's also something that's worth knowing. But apart from a very narrowly scoped set of critical issues (the boundaries of which should be discussed, and decided, by the project as a whole), such bugs found in review should *not* be grounds for package rejection. They should be handled asynchronously via bug reports, just like other developers do when they find bugs as part of QA reviews. All of this is true whether or not reviewing lintian output happens to account for the majority of NEW queue processing time. The ftp team should not be unilaterally imposing new requirements on packages reaching the archive, they should not be making a bottleneck of themselves by turning minor bugs into blockers, and they should definitely not be assuming a paternal role of telling Debian developers, their *peers*, how to maintain their packages in general. If the current ftp team doesn't agree with these principles, then I think a GR is probably needed to set the record straight. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] [1] This is potentially addressed by Russ's comments about lintian 2.0's improved flexibility; but if you're worrying over lintian warnings, then it's clear this facility is not in use yet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
