You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kathey Marsden <km...@sbcglobal.net> on 2009/05/19 00:22:59 UTC
10.5.2 Maintenance release planning
Now that everyone has started to catch their breath from 10.5.1.1, I
think that it would be good to start planning for a 10.5 maintenance
release. I think a good target date would be Monday, July 27, with
release candidate two weeks before. This would give enough time to get
initial feedback from 10.5.1.1 and hopefully address any serious issues
as well as fix a number of other bugs. I am willing to manage the release.
Does this date sound good to others? I noticed Rick doing some initial
work on localization. Is there a chance we will have localized messages
by mid July?
Thanks
Kathey
Re: 10.5.2 Maintenance release planning
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> That's the target date which I suggested to our localization team.
> They did not balk at that date so I think it is likely we will have
> localizations around then. In case the localizations are a little
> late, I hope you can be flexible about the release date.
>
I am going on vacation Aug 15 for two weeks, so I am hoping to get it
put to bed well before then. Hopefully it will all work out.
Kathey
Re: 10.5.2 Maintenance release planning
Posted by Rick Hillegas <Ri...@Sun.COM>.
Kathey Marsden wrote:
> Now that everyone has started to catch their breath from 10.5.1.1, I
> think that it would be good to start planning for a 10.5 maintenance
> release. I think a good target date would be Monday, July 27, with
> release candidate two weeks before. This would give enough time to
> get initial feedback from 10.5.1.1 and hopefully address any serious
> issues as well as fix a number of other bugs. I am willing to manage
> the release.
Hi Kathey,
Thanks for volunteering to cat-herd the maintenance release.
>
> Does this date sound good to others? I noticed Rick doing some
> initial work on localization. Is there a chance we will have localized
> messages by mid July?
That's the target date which I suggested to our localization team. They
did not balk at that date so I think it is likely we will have
localizations around then. In case the localizations are a little late,
I hope you can be flexible about the release date.
Looks like Dag is putting some thought into how to triage our bugs.
Thanks, Dag!
Regards,
-Rick
>
> Thanks
>
> Kathey
Re: 10.5.2 Maintenance release planning
Posted by Kristian Waagan <Kr...@Sun.COM>.
Kathey Marsden wrote:
[ snip ]
> Does this date sound good to others?
Yes, I think we have a few issues that warrant a maintenance release.
I do expect some people will be away on vacation before July 27th, but
hopefully we'll manage to get a fair amount of fixes in.
Kathey, thanks for taking on the role as release manager :)
--
Kristian
Re: 10.5.2 Maintenance release planning
Posted by Kathey Marsden <km...@sbcglobal.net>.
Kathey Marsden wrote:
> Now that everyone has started to catch their breath from 10.5.1.1, I
> think that it would be good to start planning for a 10.5 maintenance
> release. I think a good target date would be Monday, July 27, with
> release candidate two weeks before. This would give enough time to
> get initial feedback from 10.5.1.1 and hopefully address any serious
> issues as well as fix a number of other bugs. I am willing to manage
> the release.
>
I would like to proceed with this schedule despite the fact that there
are a lot of vacations in July and the jury duty notice I just got in
the mail. We already have a number of great fixes and some more close
to completion. I don't think this will require the same rigor of
testing as 10.5.1. If needed, we can delay a bit and I can pass the
torch to someone else. The release candidate target would be Tuesday,
July 14. That will give us almost six weeks for what I hope will be an
intense bug fixing effort.
Please let me know if you have any objections, otherwise I will make the
Wiki page this afternoon.
Kathey
Re: 10.5.2 Maintenance release planning
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
> Knut Anders Hatlen <Kn...@Sun.COM> writes:
>
>> Kathey Marsden <km...@sbcglobal.net> writes:
>>
>>> Now that everyone has started to catch their breath from 10.5.1.1, I
>>> think that it would be good to start planning for a 10.5 maintenance
>>> release. I think a good target date would be Monday, July 27, with
>>> release candidate two weeks before. This would give enough time to
>>> get initial feedback from 10.5.1.1 and hopefully address any serious
>>> issues as well as fix a number of other bugs. I am willing to manage
>>> the release.
>
> In deed, thanks, Kathey!
>
> 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.
>
> 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 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
>
> - category vs flag movement of some information (e.g. newcomer), is
> there a backlog of such issues we could all help move forward?
> When all are converted we should remove unneeded components.
I don't think there's any issues stopping someone with JIRA superpowers
from doing it now. It should be a fairly simple bulk update, setting the
newcomer/performance/... flag on the issues with the corresponding
component, and then remove the component. After on, we should probably
also go through the issues and see if some of them ended up with no
component (for example if they only had the performance component set
before).
> - 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?
Yes, I think that would make sense. "Crash" is used inconsistently, I
think. Some use that flag if their application got an SQLExceptions,
whereas others understand the way you suggested above. Perhaps we should
also have some guidelines to help us decide whether a bug is a "High
Value Fix" or not.
> 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?
+1 to move this information to html.
> It could, perhaps, be useful to have separate, simplified docs for
> users, so developers docs could be more exhaustive and authoritative?
+1
> Would it be helpful to try to coordinate our work wrt triaging the
> existing bugs in any way? Could a Wiki page be helpful?
It would at least be useful to document how the flags are used, but that
could be done in one of the existing documents/pages describing the
filing of bug reports. What other coordination did you have in mind?
--
Knut Anders
Re: 10.5.2 Maintenance release planning
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Kathey Marsden <km...@sbcglobal.net> writes:
> Rick Hillegas wrote:
>> 9:00 am PDT is 6:00 pm in Norway. That's in the middle of suppertime
>> for a humane society which actually values its families. How about
>> 7:00 am PDT?
>>
> That is time for my son's breakfast and school preparation. Can we
> split the difference at 8:00am PDT?
That's fine with me. Hopefully I won't be too jet lagged after
returning from S.F. on Sunday.
Dag
Re: 10.5.2 Maintenance release planning
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> 9:00 am PDT is 6:00 pm in Norway. That's in the middle of suppertime
> for a humane society which actually values its families. How about
> 7:00 am PDT?
>
That is time for my son's breakfast and school preparation. Can we
split the difference at 8:00am PDT?
Kathey
Re: 10.5.2 Maintenance release planning
Posted by Rick Hillegas <Ri...@Sun.COM>.
Kathey Marsden wrote:
> If it works for you, I will plan a meeting for Monday, June 8, for 9a
> PDT. Hopefully, that's not too late in the day in Norway. If that
> works, I will send out a separate mail invitation for that.
9:00 am PDT is 6:00 pm in Norway. That's in the middle of suppertime for
a humane society which actually values its families. How about 7:00 am PDT?
Regards,
-Rick
Re: 10.5.2 Maintenance release planning
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dag H. Wanvik wrote:
> Would a flag indicating that a repro is available make it easier to
> identify such issues?
>
That sounds useful. We should just make it clear that 'Reproduction
Available' or maybe 'Reproduction Attached' means a reproduction
attached to the issue, not just that someone, somewhere can reproduce
with their application.
> I am not sure how we would use the "Later" flag.
We have one issue marked 'Later', DERBY-1615, because Kristian thought
it really only appropriate for a Major (11.0) release. Maybe we should
just adopt that narrow definition for 'Later'.
> we have some serious backlog here.
>
>
!!!! *Absolutely* !!!!
>> It might be interesting to have a quarterly IRC review of the
>> HighValueFix list.
> I think this is a great idea.
If it works for you, I will plan a meeting for Monday, June 8, for 9a
PDT. Hopefully, that's not too late in the day in Norway. If that
works, I will send out a separate mail invitation for that.
Kathey
Re: 10.5.2 Maintenance release planning
Posted by Rick Hillegas <rh...@apache.org>.
>> 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.
>
>+1
>
>No, I don't have such powers (yet).
I have added Knut and Dag to the jira-administrators group.
Regards,
-Rick
--
View this message in context: http://www.nabble.com/10.5.2-Maintenance-release-planning-tp23606435p23671781.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.
Re: 10.5.2 Maintenance release planning
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Thanks for your reply, Kathey!
Please see comments inlined.
Kathey Marsden <km...@sbcglobal.net> writes:
> I think we should resolve these Cannot Reproduce if we have received
> no new information for six months.
+1
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.
+1
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.
+1
> 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
coordinate!
+1
> 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.
Dag
Re: 10.5.2 Maintenance release planning
Posted by Kathey Marsden <km...@sbcglobal.net>.
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
Re: 10.5.2 Maintenance release planning
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Knut Anders Hatlen <Kn...@Sun.COM> writes:
> Kathey Marsden <km...@sbcglobal.net> writes:
>
>> Now that everyone has started to catch their breath from 10.5.1.1, I
>> think that it would be good to start planning for a 10.5 maintenance
>> release. I think a good target date would be Monday, July 27, with
>> release candidate two weeks before. This would give enough time to
>> get initial feedback from 10.5.1.1 and hopefully address any serious
>> issues as well as fix a number of other bugs. I am willing to manage
>> the release.
In deed, thanks, Kathey!
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.
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 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
- category vs flag movement of some information (e.g. newcomer), is
there a backlog of such issues we could all help move forward?
When all are converted we should remove unneeded components.
- 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?
It could, perhaps, be useful to have separate, simplified docs for
users, so developers docs could be more exhaustive and authoritative?
Would it be helpful to try to coordinate our work wrt triaging the
existing bugs in any way? Could a Wiki page be helpful?
(*) Btw, the current VTI tools needs some more "intelligence" for
handling the flags correctly, I think (I tried to add columns for
"customfieldvalues" to VTIs.java in the @XMLRow tag for
apacheVanillaJiraReport, but there are many such in the XML output by
JIRA so some work would be needed in parsing these to allow better
queries.
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!! :)
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,
Dag
Re: 10.5.2 Maintenance release planning
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Kathey Marsden <km...@sbcglobal.net> writes:
> Now that everyone has started to catch their breath from 10.5.1.1, I
> think that it would be good to start planning for a 10.5 maintenance
> release. I think a good target date would be Monday, July 27, with
> release candidate two weeks before. This would give enough time to
> get initial feedback from 10.5.1.1 and hopefully address any serious
> issues as well as fix a number of other bugs. I am willing to manage
> the release.
Hi Kathey,
Thanks for volunteering! The proposed target date sounds good to
me. 10.5.1.1 had many useful new features that were not tested much by
real users before the release, so it would be great to have a
maintenance release fairly soon that fixes the new issues that have/will
come up now that 10.5 is out.
--
Knut Anders