Re: NEW processing
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/
slangasek@ubuntu.com vorlon@debian.org
[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.
Reply to: