Re: On Bugs

[Roland Rosenfeld <roland@spinnaker.de>]

Anthony Towns <aj@azure.humbug.org.au> wrote:

> important   any other bug which makes the package unsuitable for release. 

> I'd like to get this changed. I think a much, much better definition would
> be as follows:

> important   any other bug which is a severe violation of Debian policy
>             (violates a must directive)

Bad idea.  How do you define "severe violation"?  IMHO it is a very
severe violation of policy, if a package doesn't provide man pages for
all binaries in PATH.  But with your new definition of important 10%
(or more?) of the packages have at least one important bug because of
missing man pages.

I personally think, that the current definition of "important" is
okay, the only problem is, that there are so many "normal" bugs open
for ages, that many submitters try to emphasize their bug reports by
setting them "important" while the bug doesn't make the package
"unsuitable for release".

I fear that the real problem is, that some maintainers "forget" to do
regular housekeeping in the BTS.  Maybe some maintainers don't know,
that there are web pages available, which collect the bugs by
maintainer?  Last week I checked the bugs I submitted in the past and
was shocked how many of them were still open.  Some of them were
already fixed in the packages, but the maintainer had forgotten to
close the bug reports.  Some trivial to fix bugs weren't attached for
months or years (maybe we should ping the maintainers and assign
packages without an active maintainer to WNPP?).  The peak of all was
one of my "manpage missing" bug reports, where some diligent guy
provided all missing man pages (~10) one year ago, but the maintainer
of the package didn't add them to the package (while the package was
actively maintained by him).  I cannot understand it.

> One thing this means is that a lot of important bugs that aren't
> policy violations will get downgraded back to normal. This doesn't
> mean they should be ignored,

But when you have a look at the age of some trivial to fix "normal"
bugs, you see, that some maintainers seem to ignore "normal" bug
reports.  I also don't understand it, but that's what the BTS is
showing me.

> We've got almost 11,000 open, unique, non-wishlist bugs at the
> moment. That's a lot. Probably unacceptably many [0].

Some housekeeping (closing old bugs, which are already fixed, either
by maintainer or upstream, applying patches, which are provided in the
bug reports,...) would reduce this number a lot.  But this is a job,
which has to be done by the maintainers (IMHO only the maintainer or
the bug submitter should close bug reports)...
11000 bug reports cannot be processed by one single person, but we
have to divide this job to _all_ maintainers (especially every
maintainer for his packages).
But I don't have an idea how to motivate all maintainers to do their
housekeeping job...

> So what would be nice is seeing lots of those fixed. Maybe we should
> have some bugsquash months instead of just bugsquash weekends.

Does a bugsquash allow to NMU normal or wishlist bugs?  If I remember
policy correct, a NMU is only allowed to do minimal changes to the
packages to fix RC bugs, but it's quite hard to do the housekeeping
job, which would fix tons of bugs with a little bit diligence...

> At the very least anyone with some spare time on their hands might
> like to help with merging duplicate reports

Another point of housekeeping.  Why are there maintainers, who don't
merge the bug reports of their packages?  This doesn't take much time
for 10-20 packages, but it takes much time for 11000 bugs.

> and sending in patches to existing easily fixed bugs.

But does it make sense to send in patches, if the maintainer doesn't
merge them into the package?  There are many bugs older a year with
patches, which are simply ignored by the maintainer.  It's quite
frustrating...

Tschoeeee

        Roland

-- 
 * roland@spinnaker.de * http://www.spinnaker.de/ *