db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: 10.3 Release Notes
Date Mon, 09 Jul 2007 23:47:10 GMT
On 7/9/07, Oystein Grovlen - Sun Norway <Oystein.Grovlen@sun.com> wrote:
> Daniel John Debrunner wrote:
> > This is an open source release, the release note applies just as much to
> > the source code as the libraries. Probably even the test issues should
> > have been listed.
> >
> > It might be better to split the changes section into two (or more)
> > sections, e.g. changes in the user functionality, or possibly have a
> > "users" release note and a "project" release note.
> Splitting the changes into different sections so that there is a
> separate section for "Bugs Fixed" is a good idea.
> Even if the this is an open source release, I am not sure I see what
> value it adds to list every change in the release notes.  Might as well
> just refer people to JIRA.  (People will have to go there any way to
> understand what the issues are about.)
> --
> Øystein
One of the hardest and most time-consuming things in preparing the
release was creating the Release Notes.
We have the release notes generator...But it presumes xml reports to
have been magically created, and it does not have a mechanism to
identify the new features.

I got some of the magic by using org.apache.derbyBuild.JiraConnector,
which uses JIRA's XML search option, but JIRA XML searches appear
quite limited - how do you do 'or'?  How do you do exclude?
No fun at all.

In past releases, we had the 'CHANGES' file, but because it seemed to
list the same bugs as the Release-Notes I removed it. This may have
been the wrong thing to do...(every apache project needs to log the
changes somehow).

A big problem is also lack of standard usage in JIRA.
Take sub-tasks - include them or not? What if the master task is still
open because of 1 or 2 sub issues or tasks are still open? (e.g. 1478,
although that's an improvement, not a bug).
In other master issues, changes have gone in for both the master task
and the subtask. What to do?
Should issues get forced closed, with more work continuing in a
subsequent bug while work is still going on when changes *have* gone
How about issues where there are links, rather than subtasks,
indicating one issue is 'part of' another; should the ones that are
'part of' not go in the release notes?

Another concern is our practice for 'affects'. Because it is not
required to annotate whether a bug is confirmed to exist or not in a
previous release, or, for that matter, to even annotate the 'affects'
at all, some bugs marked affects 10.3 might have been around before...
So, creating a list of only bugs that existed before and have been
fixed now, is particularly hard to compile in an automated way.

Note, by the way, that Dan brought up a similar concern re the release
notes (DERBY-2840).

Anyway, if we need another release round, I can modify the release notes.
Otherwise, I'm inclined to leave them as is...Is that OK?

If we do change them, what *should* be in them, then?

I gather:
- A section for 'new features' - without splitting into categories
    The ReleaseNotesGenerator needs to be adjusted for this new section
- A section for bug fixes - I assume only type bug and improvement?
With only those that do *not* have 'affects'? Excluding any test issues, web site
components...? Should build isssues be in?
- Reinstate the CHANGES file, which basically will be a listing of
*all* issues with fix in 10.3.* (at this time).


View raw message