db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: 10.5.2 Maintenance release planning
Date Tue, 19 May 2009 17:39:26 GMT

Thanks for your reply, Kathey!

Please see comments inlined.

Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> I think we should resolve  these Cannot Reproduce if we have received
> no new information for six months.


Would a flag indicating that a repro is available make it easier to
identify such issues? Sounds like sifting through 1100+ issues is a
bit tiresome ;-)

> 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.

I am not sure how we would use the "Later" flag. What would the
criteria be? I have a clearer sense of what "Won't fix" means; the
procedure you suggest is fine with me. This being open source, we as a
community aren't really making any guarantees in the first place...  I
guess what I am saying i that all issues not assigned are per
definition "Later". 

> 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.


No, I don't have such powers (yet).

> I think ideally all content should move to the Wiki for easy update
> and just have a link or two from the website.


> I made the Wiki page, http://wiki.apache.org/db-derby/DerbyJiraReports
> to help individuals maintain  Jira.  

Thanks for that link; I have seen it before, but I missed it this time.
Seems a good start!

> 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.

And even with only you (in the main) using it it has got too long.. ;)
Maybe that indicates that we have some serious backlog here.

> 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.

I think this is a great idea. It would give us an opportunity to


> I am seeing only 355 (still too many)

Sorry, I had a bit too many components in my query. 355 is right. If I
add Performance and Regression Test Failure to your set of categories,
I get 404.


View raw message