I think this is plain simple - as long as noone of the committers has time for it and has fun in doing so, nothing will happen. This is open source development and this means, things are not done because someone "forces" you to do them. Work is done because someone has fun in doing so.
I don't want to force anybody. But what about a bug handling guideline? Is there something similar for the Apache community in general? And my comment was more about updating the bug stati correctly. Only patches should be handled in a specified time, because they should be really appreciated. If they are ignored in the patcher's point of view, he will get frustrated and won't get involved further in the project.
I confess that our bug list could be shorter but there are successful
(Apache) projects with much longer bug lists.
It's correct that we should at least check the severity of a bug, but
even this is in most cases a personal perception. E.g. if someone
enters a bug with severity blocker, I look at the bug and say "No,
it's only a minor bug" and change it, what do you think might happen
then? I guess 70% then would say, "No, it's a blocker" and change again. Hmm..
Independent of this discussion: We have at the moment 4 blockers: http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=Blocker&product=Cocoon+2&order=Bug+Number
1. Vadim, 2002-09-21: "Blocking 2.1 release"
2. Berin, 2002-07-11 (bug reporter)
3. 2002-11-07, uncommented
4. caching issue, last comment written by you only 5 days ago, waiting for user actions
IMHO only the last one is acceptable.
But the good news is: we decreased our bug list from approx 130 to approx 100 in three weeks! So, if everyone helps in continuing this work we could be bug free in two months :)
A very good start of cause - and you seem to work on bugs at the moment too ;-)
Joerg
