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 Oystein Grovlen - Sun Norway <Oy...@Sun.COM> on 2007/07/09 16:07:12 UTC
10.3 Release Notes
Thanks for all your work on making the 10.3 release, Myrna. I have
downloaded the release candidate and plan to do some ad-hoc testing of it.
I looked at the release note and I found the CHANGES section a bit
confusing. It lists a lot of issues that are not relevant to users
(e.g, code issues (e.g, renaming of internal classes), subtasks for
implementing new features, bug fixes to new features, improvements in
build system, procedural issues). Would it not have been better to make
a list of bug issues that only affects earlier releases? As it is now,
the list of changes is so long and contain so much irrelevant issues
that I am afraid most users will be reluctant to look at it.
--
Øystein
Re: 10.3 Release Notes
Posted by Kathey Marsden <km...@sbcglobal.net>.
Myrna van Lunteren wrote:
> On 7/13/07, Kathey Marsden <km...@sbcglobal.net> wrote:
>> Myrna van Lunteren wrote:
>> > I took advantage of the need for some time for the blockers and
>> > revised the Release Notes manually...
>> >
>> Where do I find these release notes?
>>
>> Kathey
>>
>>
> Attached in a follow up mail. See:
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200707.mbox/%3cc25576af0707130802h4220e4c2i54d3f5233a2f5983@mail.gmail.com%3e
>
>
High Myrna,
The release notes look good on a brief look. It would be great if we
could highlight some of the know critical and regression issues, e.g
2436, 2437, 2892, 2896, 2905
I think it is good to have the bugs fixed on 10.3 feature work out,
since they have never existed in a released product.
Thanks for all your work on this.
Kathey
Re: 10.3 Release Notes
Posted by Myrna van Lunteren <m....@gmail.com>.
On 7/13/07, Kathey Marsden <km...@sbcglobal.net> wrote:
> Myrna van Lunteren wrote:
> > I took advantage of the need for some time for the blockers and
> > revised the Release Notes manually...
> >
> Where do I find these release notes?
>
> Kathey
>
>
Attached in a follow up mail. See:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200707.mbox/%3cc25576af0707130802h4220e4c2i54d3f5233a2f5983@mail.gmail.com%3e
Myrna
Re: 10.3 Release Notes
Posted by Kathey Marsden <km...@sbcglobal.net>.
Myrna van Lunteren wrote:
> I took advantage of the need for some time for the blockers and
> revised the Release Notes manually...
>
Where do I find these release notes?
Kathey
Re: 10.3 Release Notes
Posted by Daniel John Debrunner <dj...@apache.org>.
Myrna van Lunteren wrote:
> On 7/16/07, Oystein Grovlen - Sun Norway <Oy...@sun.com> wrote:
>> Sorry that ASAP for me is a bit late for you, but I wonder whether these
>> JIRAs should also have been called out as New Features and/or had
>> Release Note calling out changes that may affect applications:
>>
>>
> It is a too late, yes...(unless we need another candidate).
Well someone would have to have the itch to write release notes.
No-point in holding up a release for something that doesn't exist.
Dan.
Re: 10.3 Release Notes
Posted by Myrna van Lunteren <m....@gmail.com>.
On 7/16/07, Oystein Grovlen - Sun Norway <Oy...@sun.com> wrote:
> Sorry that ASAP for me is a bit late for you, but I wonder whether these
> JIRAs should also have been called out as New Features and/or had
> Release Note calling out changes that may affect applications:
>
> DERBY-2331 Disallow code in installed jars from resolving classes in the
> org.apache.derby.* namespace except for public apis.
>
> DERBY-2330 Disallow user-defined SQL routines to resolve to entry points
> (methods in classes) in the org.apache.derby.* namespace
>
> DERBY-2152 Support diagnostic vti tables that take parameters, such as
> SpaceTable
>
> DERBY-1953 Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER
> statement optional
>
> DERBY-1623 Add ANSI TRIM implementation
>
> --
> Øystein
>
It is a too late, yes...(unless we need another candidate).
I can only mention that I asked about the first 2 and was told they
did not need a release note.
Myrna
Re: 10.3 Release Notes
Posted by Myrna van Lunteren <m....@gmail.com>.
On 7/16/07, Oystein Grovlen - Sun Norway <Oy...@sun.com> wrote:
>[...snip...] I wonder whether these
> JIRAs should also have been called out as New Features and/or had
> Release Note calling out changes that may affect applications:
>
> DERBY-2331 Disallow code in installed jars from resolving classes in the
> org.apache.derby.* namespace except for public apis.
>
> DERBY-2330 Disallow user-defined SQL routines to resolve to entry points
> (methods in classes) in the org.apache.derby.* namespace
>
> DERBY-2152 Support diagnostic vti tables that take parameters, such as
> SpaceTable
>
> DERBY-1953 Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER
> statement optional
>
> DERBY-1623 Add ANSI TRIM implementation
>
> --
> Øystein
>
With RN for 10.3.1.3. I added DERBY-2152, DERBY-1953, and DERBY-1623
to the list of new features.
Again I was faced with some inconsistencies, in that some of the items
on the list of new features are actually marked as improvements...Very
hard to decide what to put on the list and what not.
I decided that the issues currently on the list have been specifically
called for addition by the community, either through emails, or
through placement on the DerbyTenThreeRelease wiki page, so as you
called for them, I could put them on...
But DERBY-2330 and DERBY-2331 are more of a taking away of
functionality than adding, so I decided not to put them in the new
features list.
As to warranting a dedicated release note for those 2, like Dan said,
someone would have had to write a note.
Myrna
Re: 10.3 Release Notes
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Myrna van Lunteren wrote:
> I took advantage of the need for some time for the blockers and
> revised the Release Notes manually...
>
> 1. I went through and wherever it seemed an issue would have existed
> beforeI left it in the CHANGES section; if it looked like it was new
> with 10.3 and fixed in 10.3 I took it out of the release notes.
>
> 2. I removed the sections 'Big' 'Small' 'Non functional improvements'
> from the New Features section. I didn't have a clue how to order them,
> so just left it...I moved the SYCS_UTIL procedures from the CHANGES to
> the New Features.
>
> I'll make a separate CHANGES document that will list *all* issues with
> fix in for 10.3* if it looks like this Release Notes is a more useful
> document.
>
> Please provide input asap...
Sorry that ASAP for me is a bit late for you, but I wonder whether these
JIRAs should also have been called out as New Features and/or had
Release Note calling out changes that may affect applications:
DERBY-2331 Disallow code in installed jars from resolving classes in the
org.apache.derby.* namespace except for public apis.
DERBY-2330 Disallow user-defined SQL routines to resolve to entry points
(methods in classes) in the org.apache.derby.* namespace
DERBY-2152 Support diagnostic vti tables that take parameters, such as
SpaceTable
DERBY-1953 Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER
statement optional
DERBY-1623 Add ANSI TRIM implementation
--
Øystein
Re: 10.3 Release Notes
Posted by Myrna van Lunteren <m....@gmail.com>.
Forgot to attach attempt at revised release notes.
Myrna
Re: 10.3 Release Notes
Posted by Myrna van Lunteren <m....@gmail.com>.
I took advantage of the need for some time for the blockers and
revised the Release Notes manually...
1. I went through and wherever it seemed an issue would have existed
beforeI left it in the CHANGES section; if it looked like it was new
with 10.3 and fixed in 10.3 I took it out of the release notes.
2. I removed the sections 'Big' 'Small' 'Non functional improvements'
from the New Features section. I didn't have a clue how to order them,
so just left it...I moved the SYCS_UTIL procedures from the CHANGES to
the New Features.
I'll make a separate CHANGES document that will list *all* issues with
fix in for 10.3* if it looks like this Release Notes is a more useful
document.
Please provide input asap...
Thx,
Myrna
Re: 10.3 Release Notes
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Myrna van Lunteren wrote:
> 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 acknowledge that making release notes are a time consuming task, and
making release notes will always be a compromise between effort and
quality. I guess the question we should ask is how can we get
sufficient accuracy without making the work too time-consuming.
In addition to the issues you raise, I feel that one major problem
with generated release notes is that the summaries for JIRA issues
often do say much about what have been fixed. I guess there are two
alternatives we can try to improve that:
1. Urge the responsible developer to make sure the summary is
descriptive.
2. Only include issues with specific release notes attached. This
means that one will require such release notes all for issues that
should be mentioned in the release note, not just for issues with
application impact.
Alternative 2 implies that the responsible developer for an issue will
also be given the responsibility to decide whether an issue should be
included in the release note or not.
Maybe we should make the rule that only issues with the release note
required field checked will be included in the release note. This
would free the release manager from the burden of deciding what should
be part of the release note, at the risk of reduced quality due to
developers not marking their issues the way they are supposed to.
> 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).
The advantage of a CHANGES file is that not everything needs to be
included in the release note. It gives more freedom to create a
release notes that is useful to Derby users.
>
> 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
> in?
> 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.
I think if it was well defined how release notes were generated, one
could give more responsibility to individual developers and make them
do the necessary work to make an issue appear in the release note.
(E.g., Developer: "The bug I fixed is not listed in the release note!"
Release Manager: "You need to mark it as affects 10.2 to make it show
up").
I think it would also help if the Release Manager, several times in
the weeks prior to a release generated the release note and posted it
on derby-dev and urged the developers to check that the issues they
have been working on is properly listed.
>
> 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?
I am not going to insist on anything, but I feel that a list of fixed
bugs that are automatically generated based on what affects earlier
releases would be much more useful (even if it may be less accurate)
than the current list.
>
> 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
Yes, definitely. For future releases, I suggest that we generate this
based on issues that are marked as new features and that has an
attached release note. This release note should then describe the
implemented feature. For this release, it seems that some new
features are marked improvement, instead. I feel that any changes in
functionality or interfaces (small or large) should be marked as 'new
features'.
> - A section for bug fixes - I assume only type bug and improvement?
I am not sure about improvements. Many of them are code internal
issues (e.g., renaming of class, restructuring of code) which is not
very relevant to users.
> With only those that do *not* have 'affects
> 10.3.0.0/10.3.1.0/10.3.1.1'?
I think this should be "only those that *do* have affects 10.2
releases". We do not want to leave out issues that are marked as both
affecting both 10.2 and 10.3.
> Excluding any test issues, web site components...? Should build
> issues be in?
Personally, I do not care for build issues. Documentation issues
seems to be documented at a too detailed level. I do not think users
care want to be informed about corrections of typos etc (at least not
through references to JIRA issues), but would like to know about new
"Documentation features" (e.g., a new manual, a new topic, a
significantly improved coverage of a topic).
> - Reinstate the CHANGES file, which basically will be a listing of
> *all* issues with fix in 10.3.* (at this time).
Sounds good.
On previous (closed-source) projects I have worked on, it has often
been an issue whether the release notes needs to be generated when the
release candidate is built or if we can edit them afterwards.
Generally, QA and Release Engineering did not like the idea of later
repackaging the release to include the release notes since it meant
that the delivered packages would not be the same as the one that
was tested. Engineering, on the other hand, having fixed bugs etc
until the final deadline, would like to be able to use the test period
to work on the release notes. Sometimes we solved this by putting the
release notes on the web instead of in the delivered packages, but I
guess we have already decided that we will not do it this way for
Derby. This problem is even bigger with automatically generated
release notes since many developers, unless they generate them
themselves, will not look at the release notes until it is too late to
change them.
Thanks for all your work with this release,
--
Øystein
Re: 10.3 Release Notes
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Myrna van Lunteren wrote:
>
>> 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?
>
> If only we had a SQL database with XML capabilities ...
>
> Dan.
Very soon we will be able to deploy a VTI against the JIRA reports and
we will be able to AND, OR, and NOT to our heart's content.
-Rick
Re: 10.3 Release Notes
Posted by Daniel John Debrunner <dj...@apache.org>.
Myrna van Lunteren wrote:
> 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?
If only we had a SQL database with XML capabilities ...
Dan.
Re: 10.3 Release Notes
Posted by Myrna van Lunteren <m....@gmail.com>.
On 7/9/07, Oystein Grovlen - Sun Norway <Oy...@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
in?
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
10.3.0.0/10.3.1.0/10.3.1.1'? 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).
Myrna
Re: 10.3 Release Notes
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
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
Re: 10.3 Release Notes
Posted by Daniel John Debrunner <dj...@apache.org>.
Oystein Grovlen - Sun Norway wrote:
> Thanks for all your work on making the 10.3 release, Myrna. I have
> downloaded the release candidate and plan to do some ad-hoc testing of it.
>
> I looked at the release note and I found the CHANGES section a bit
> confusing. It lists a lot of issues that are not relevant to users
> (e.g, code issues (e.g, renaming of internal classes), subtasks for
> implementing new features, bug fixes to new features, improvements in
> build system, procedural issues). Would it not have been better to make
> a list of bug issues that only affects earlier releases?
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.
Dan.