Dag H. Wanvik wrote:
I have started looking a bit at our outstanding open bugs with a view
to doing some bug fixing, and fiddling with the VTI(*) tool described
in "Wiki: HowToRunJiraVTIReports" to try to understand categories and
distributions.
Thanks!
I have seen that you have recently (again, thanks!!) been going over
older bugs and am interested in your your status on that work.
I went through the 1155 open issues and resolved what I could, closing
Cannot Reproduce if we haven't seen it for 6 months or more. I
unassigned issues that have had no activity for a year. I marked some
issues HighValueFix based on the highly subjective criteria at:
http://wiki.apache.org/db-derby/HighValueFixCandidates. I also tagged
some issues as new comer. I didn't look at closing issues that had been
resolved, since that doesn't directly impact the reports I look at.
In full disclosure, I have to admit that about 1/2 way through the
process I realized that the Jira report repaginates when you move to the
next page, so I think I might have missed a few issues, due to this,
but I didn't have the stomach to go back through them all to see what I
missed.
I am also interested to learn what people see as the most common
problems are with the current issue data base including our system of
categories and flags, including but not limited to:
- unreproducable or stale issues
I think we should resolve these Cannot Reproduce if we have received no
new information for six months.
I think we should make more aggressive use of 'Later' and 'Won't Fix'
for issues which we think are just not going to get fixed any time
soon. Issues can always be reopened if someone wants to pick them up.
Since this analysis is highly subjective, I think the best way to do
this is to put a comment in the issue with your intent and then resolve
it a few weeks later if nobody balks.
- category vs flag movement of some information (e.g. newcomer), is
there a backlog of such issues we could all help move forward?
As Knut suggested, I think a bulk update and removal of the categories
and tracking issues like DERBY-310 is appropriate. Perhaps Rick or
someone with existing powers can give you authority to do this if you
don't have it already.
- what categories/flags seem/are hard to use correctly? E.g. what
constitutes a "crash"? (JVM stops, Derby server becomes unavailable,
replications stops etc..) Would it be useful to try to tighten
definitions up?
I notice the document "The business of filing apache derby issues in
Jira" is a bit dated (it's also in pdf, I think if would be preferable
to have it moved to html for quicker access). On the other hand, our
wiki page "Tips for filing Apache Derby Bugs" is a bit on the brief
side.. Should we try to update our docs in this area to get better
quality filing?
I think ideally all content should move to the Wiki for easy update and
just have a link or two from the website.
It could, perhaps, be useful to have separate, simplified docs for
users, so developers docs could be more exhaustive and authoritative?
Sounds good.
Would it be helpful to try to coordinate our work wrt triaging the
existing bugs in any way? Could a Wiki page be helpful?
I made the Wiki page, http://wiki.apache.org/db-derby/DerbyJiraReports
to help individuals maintain Jira. The page has links for individuals
or global reports for those who might feel a bit more ambitious.
Theoretically if everyone looked at the individual reports periodically
we would be able to keep Jira tidy. I had hoped that HighValueFix would
be a way for us to converge on a good list of bugs to fix with this
distributed analysis. I had thought it would be about 10% of our bug
backlog but it has grown to a larger list. I had hoped to see other
developers marking issues HighValue or objecting to issues that I had
marked that way, but so far it is sort of a list of Kathey's favorites.
I am not sure if anyone besides me uses it.
It might be interesting to have a quarterly IRC review of the
HighValueFix list. Before the meeting , everyone reviews issues and
puts them on the HighValueFix list if they think they belong there based
on the criteria at
http://wiki.apache.org/db-derby/HighValueFixCandidates (or modified
criteria) and then in the meeting we can go through the list and take
issues off if everyone agrees they don't belong there. We could
strictly adhere to the 10% mark in the meeting so the list doesn't get
too big. Perhaps in the meeting we could also get volunteers to pick up
important issues.
It seems we ca 450 open code bugs, it would be nice if we could try to
get that down a bit before we make an update release for 10.5!! :)
I am seeing only 355 (still too many)
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&type=1&pid=10594&component=12310670&component=11407&component=12312171&component=11409&component=11400&component=11690&component=11410&component=12312050&component=11411&component=11415&component=11408&component=11412&component=11414&resolution=-1&sorter/field=issuekey&sorter/order=DESC
Am I missing some components?
Unfortunately I no longer see the Jira global filters since Jira was
upgraded.
Ok, enough questions, I just wanted to get a little discussion around
the state of our bug database before we dive into it again :)
Thanks for initiating the discussion. Jira is our quality view on Derby
and unfortunately, right now that view is a bit fuzzy. It will be great
to clean it up.
Kathey
