Absence of a component could be avoided if we could remove this option
from the user that enters the report (so there is somebody assigned to
it, even if it is the wrong person) but it doesn't seem possible in
JIRA.
I don't think it is bad to have unscheduled reports, as long as there is
periodic review to schedule tasks. It is equally bad to use the next
release as a dumping ground and move around deferred tasks from release
to release.
I totally agree proper/periodic review is needed to categorize the
importance of tasks. There was a proposal by Andrig to do this monthly
but we didn't follow up properly.
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf
Of Adrian Brock
Sent: Friday, September 22, 2006 5:56 PM
To: jboss-development
Subject: [JBoss-dev] House keeping in JIRA - bug reports
Until JBoss-4.0.4 I made a regular check of JIRA using two
queries. After that release as an experiment I stopped doing
it to see what kind of state we would be in by the 4.0.5 release.
Bugs without fix versions:
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hid
e&requestId=12310183
All bugs should either be
* assigned to the currently being worked on release
* deferred to a later release
* closed as not bugs or incomplete description
Bugs should never be left unscheduled.
Bugs without components:
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?mode=hid
e&requestId=12310202
Which probably means that nobody has even looked at them.
It is very important that for each release we have analysed
all bugs and decided their importance.
61 bugs that are not scheduled (i.e. importance undetermined)
11 bugs without components (not even validated at the most
basic level)
is not good!
Just choosing one at random (the oldest one with "affects
4.0.4") falls into both categories. There is no evidence it
was ever looked at:
http://jira.jboss.com/jira/browse/JBAS-3406
It was raised on the 20th of July (over two months ago).
Obviously, the user doesn't consider a MalformedObjectName
exception as telling him the format is invalid nor has he
read the javadoc for that class which links him to valid
query formats. :-)
So this is obviously a trival "user friendly" bug where an
invalid name should forward to a page explaining the
ObjectName format.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development