10.7.1 release notes and buddy testing

[Rick Hillegas <ri...@oracle.com>]

Hello everyone,

The first draft of the 10.7.1 release notes are ready for review: 
https://svn.apache.org/viewvc/db/derby/code/trunk/RELEASE-NOTES.html?view=co 
Please let me know how I can improve these.

Thanks to Knut for signing up for buddy-testing. We still need some more 
volunteers: 
http://wiki.apache.org/db-derby/DerbyTenSevenOneRelease#A10.7.1_Work

Thanks,
-Rick

Re: 10.7.1 release notes and buddy testing

[Myrna van Lunteren <m....@gmail.com>]

On Fri, Nov 12, 2010 at 12:14 PM, Rick Hillegas
<ri...@oracle.com> wrote:
> Dag H. Wanvik wrote:
>>
>> - bug fixes: should we include Test category bugs at all? I am not sure
>>  that is interesting to end users.
>>
>
> I blow hot and cold on this one. We seem to have settled into the pattern of
> including a lot of bug fixes which most users are not interested in,
> including:
>
> 1) fixes to the tests and build scripts
>
> 2) fixes to bugs which were corrected in the mainline before a user ever saw
> them
>
> 3) incremental subtasks of features
>
> It might be worth re-opening the discussion about what should go into the
> release notes for 10.8. I can imagine oddball users and loosely involved
> developers who might be interested in all of the above topics, but I agree
> that most users would consider these issues to be noise which obscures the
> signal in the release notes.
>
> One good property of noisy release notes is that the JIRA filter is easy to
> write. If we want a tighter filter, then I would like to insist that the
> filter be expressible in JIRA. I would argue that post-processing the JIRA
> results is a brittle, time-consuming task which isn't worth the effort.
>
> Thanks,
> -Rick
>
I think somewhere - perhaps in the rules for an apache release? - it
is implied/stated that you need to include a list of *all* changes to
the source code (with the .src distribution?) for a release. Testing
code, build code, code that hasn't been released yet are all still
code, no?
This is why in the past we in the past we've had a separate changes file.

We've done away with the changes file, and have included all changes
into the release notes.

On the one hand, I can see that having a file with changes, with
explanations etc, (i.e. release notes) relevant only to users of the
binaries would be nice.
On the other hand, it's cumbersome and confusing to have to drag
around 2 files of changes.

I think we've gone back and forth on this issue a couple of times already...
I have no strong opinions either way. I wonder how other projects handle this.

Myrna

Re: 10.7.1 release notes and buddy testing

[Rick Hillegas <ri...@oracle.com>]

Dag H. Wanvik wrote:
> Hi,
>
> thanks for preparing the release notes, Rick! Some notes
>
> - title: Derby -> Apache Derby. Same in first line in overview.
> - new features, bullet one: "privileges" and "permissions" are both
>   used in the same sentence. Choose one form, I suggest privileges.
>   Bullet five: "remote clients" -> Applications using the Derby network
>   client driver
> - unicode -> Unicode
> - ascii -> ASCII
>
> - bug fixes: should we include Test category bugs at all? I am not sure
>   that is interesting to end users.
>   
I blow hot and cold on this one. We seem to have settled into the 
pattern of including a lot of bug fixes which most users are not 
interested in, including:

1) fixes to the tests and build scripts

2) fixes to bugs which were corrected in the mainline before a user ever 
saw them

3) incremental subtasks of features

It might be worth re-opening the discussion about what should go into 
the release notes for 10.8. I can imagine oddball users and loosely 
involved developers who might be interested in all of the above topics, 
but I agree that most users would consider these issues to be noise 
which obscures the signal in the release notes.

One good property of noisy release notes is that the JIRA filter is easy 
to write. If we want a tighter filter, then I would like to insist that 
the filter be expressible in JIRA. I would argue that post-processing 
the JIRA results is a brittle, time-consuming task which isn't worth the 
effort.

Thanks,
-Rick

> - issues:
>
>   DERBY-4786: It is a big confusing that we speak of Derby 10.4 and
>   higher, when one would expect to see 10.7. I guess this is because we
>   have backported it... Note required?
>
>   DERBY-4777: The wording implies that user could rely on particular SQL
>   states from Derby. In general, I believed we make no such guarantees. If
>   that is still the case, a caveat is in order, I think.
>   E.g. ".... in Client mode, 'ERROR 42X30' should be expected."
>
>   DERBY-4577: "Summary of change" is logically backwards: It states that
>   the changes is that "An update statement will fail with..."  The real
>   change is "On a new database, an UPDATE statement will no longer ever
>   give "nospc.U". On an old database, after calling SYSCS_COMPRESS_TABLE
>   on it, an UPDATE statement will no longer ever give "nospc.U"... The
>   problem applies for section "Symptoms seen..".
>
>   insures -> ensures
>
> Thanks,
> Dag
>
>
>
>
>   

Re: 10.7.1 release notes and buddy testing

[Rick Hillegas <ri...@oracle.com>]

Thanks for the detailed comments, Dag. I have updated the release notes, 
incorporating most of your recommendations.

Cheers,
-Rick

Dag H. Wanvik wrote:
> Hi,
>
> thanks for preparing the release notes, Rick! Some notes
>
> - title: Derby -> Apache Derby. Same in first line in overview.
> - new features, bullet one: "privileges" and "permissions" are both
>   used in the same sentence. Choose one form, I suggest privileges.
>   Bullet five: "remote clients" -> Applications using the Derby network
>   client driver
> - unicode -> Unicode
> - ascii -> ASCII
>
> - bug fixes: should we include Test category bugs at all? I am not sure
>   that is interesting to end users.
> - issues:
>
>   DERBY-4786: It is a big confusing that we speak of Derby 10.4 and
>   higher, when one would expect to see 10.7. I guess this is because we
>   have backported it... Note required?
>
>   DERBY-4777: The wording implies that user could rely on particular SQL
>   states from Derby. In general, I believed we make no such guarantees. If
>   that is still the case, a caveat is in order, I think.
>   E.g. ".... in Client mode, 'ERROR 42X30' should be expected."
>
>   DERBY-4577: "Summary of change" is logically backwards: It states that
>   the changes is that "An update statement will fail with..."  The real
>   change is "On a new database, an UPDATE statement will no longer ever
>   give "nospc.U". On an old database, after calling SYSCS_COMPRESS_TABLE
>   on it, an UPDATE statement will no longer ever give "nospc.U"... The
>   problem applies for section "Symptoms seen..".
>
>   insures -> ensures
>
> Thanks,
> Dag
>
>
>
>
>   

Re: 10.7.1 release notes and buddy testing

["Dag H. Wanvik" <da...@oracle.com>]

Hi,

thanks for preparing the release notes, Rick! Some notes

- title: Derby -> Apache Derby. Same in first line in overview.
- new features, bullet one: "privileges" and "permissions" are both
  used in the same sentence. Choose one form, I suggest privileges.
  Bullet five: "remote clients" -> Applications using the Derby network
  client driver
- unicode -> Unicode
- ascii -> ASCII

- bug fixes: should we include Test category bugs at all? I am not sure
  that is interesting to end users.
- issues:

  DERBY-4786: It is a big confusing that we speak of Derby 10.4 and
  higher, when one would expect to see 10.7. I guess this is because we
  have backported it... Note required?

  DERBY-4777: The wording implies that user could rely on particular SQL
  states from Derby. In general, I believed we make no such guarantees. If
  that is still the case, a caveat is in order, I think.
  E.g. ".... in Client mode, 'ERROR 42X30' should be expected."

  DERBY-4577: "Summary of change" is logically backwards: It states that
  the changes is that "An update statement will fail with..."  The real
  change is "On a new database, an UPDATE statement will no longer ever
  give "nospc.U". On an old database, after calling SYSCS_COMPRESS_TABLE
  on it, an UPDATE statement will no longer ever give "nospc.U"... The
  problem applies for section "Symptoms seen..".

  insures -> ensures

Thanks,
Dag