db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: 10.5.2 Maintenance release planning
Date Tue, 19 May 2009 15:11:58 GMT
Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:

> Knut Anders Hatlen <Knut.Hatlen@Sun.COM> writes:
>
>> Kathey Marsden <kmarsdenderby@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

Mime
View raw message