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 Rick Hillegas <ri...@oracle.com> on 2012/06/01 00:10:22 UTC
[VOTE] 10.9.1.0 release
Please test-drive the 10.9.1.0 candidate, then vote on whether to accept
it as a Derby release. The candidate lives at:
http://people.apache.org/~rhillegas/10.9.1.0/
The polls close at 5:00 pm San Francisco time on Thursday, June 21.
10.9.1.0 is a feature release, described in greater detail here:
http://wiki.apache.org/db-derby/DerbyTenNineOneRelease
Thanks to everyone who contributed to this release.
Regards,
-Rick
Re: [VOTE] 10.9.1.0 release
Posted by Kristian Waagan <kr...@oracle.com>.
On 01.06.2012 00:10, Rick Hillegas wrote:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to
> accept it as a Derby release.
The results provided by the community looks good, +1.
I've also used the release candidate with a few apps without finding any
serious issues.
Thanks,
--
Kristian
Re: [VOTE] 10.9.1.0 release
Posted by Lily Wei <li...@gmail.com>.
+1 to 10.9
Thanks,
Lily
On Jun 19, 2012, at 7:13 AM, Katherine Marsden <km...@sbcglobal.net> wrote:
> On 6/18/2012 6:13 PM, Bryan Pendleton wrote:
>> On 05/31/2012 03:10 PM, Rick Hillegas wrote:
>>> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept it
>>
>
> I did some testing on z/os and discovered a couple minor encoding issues but no show stoppers.
> +1 to 10.9
>
>
Re: [VOTE] 10.9.1.0 release
Posted by Mamta Satoor <ms...@gmail.com>.
+1.
I did some adhoc testing and did buddy testing for DERBY-5501.
Mamta
On Tue, Jun 19, 2012 at 7:13 AM, Katherine Marsden
<km...@sbcglobal.net> wrote:
> On 6/18/2012 6:13 PM, Bryan Pendleton wrote:
>>
>> On 05/31/2012 03:10 PM, Rick Hillegas wrote:
>>>
>>> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept
>>> it
>>
>>
>
> I did some testing on z/os and discovered a couple minor encoding issues but
> no show stoppers.
> +1 to 10.9
>
>
Re: [VOTE] 10.9.1.0 release
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 6/18/2012 6:13 PM, Bryan Pendleton wrote:
> On 05/31/2012 03:10 PM, Rick Hillegas wrote:
>> Please test-drive the 10.9.1.0 candidate, then vote on whether to
>> accept it
>
I did some testing on z/os and discovered a couple minor encoding issues
but no show stoppers.
+1 to 10.9
Re: [VOTE] 10.9.1.0 release
Posted by Bryan Pendleton <bp...@gmail.com>.
On 05/31/2012 03:10 PM, Rick Hillegas wrote:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept it
+1
Thanks to everyone in the Derby community for another fine effort!
bryan
Re: [VOTE] 10.9.1.0 release
Posted by Kim Haase <ca...@oracle.com>.
+1
The documentation in the release is correct. I filed DERBY-5795 for a
missing-stylesheets problem that has been in every release for quite a
while -- not anything that would hold up the release.
Kim
On 05/31/12 06:10 PM, Rick Hillegas wrote:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept
> it as a Derby release. The candidate lives at:
>
> http://people.apache.org/~rhillegas/10.9.1.0/
>
> The polls close at 5:00 pm San Francisco time on Thursday, June 21.
>
> 10.9.1.0 is a feature release, described in greater detail here:
> http://wiki.apache.org/db-derby/DerbyTenNineOneRelease
>
> Thanks to everyone who contributed to this release.
>
> Regards,
> -Rick
>
>
Re: [VOTE] 10.9.1.0 release
Posted by Rick Hillegas <ri...@oracle.com>.
Platform test results look good. Most checklist items have been
addressed. Thanks, everyone.
+1
On 5/31/12 3:10 PM, Rick Hillegas wrote:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to
> accept it as a Derby release. The candidate lives at:
>
> http://people.apache.org/~rhillegas/10.9.1.0/
>
> The polls close at 5:00 pm San Francisco time on Thursday, June 21.
>
> 10.9.1.0 is a feature release, described in greater detail here:
> http://wiki.apache.org/db-derby/DerbyTenNineOneRelease
>
> Thanks to everyone who contributed to this release.
>
> Regards,
> -Rick
>
>
Re: [VOTE] 10.9.1.0 release
Posted by Kristian Waagan <kr...@oracle.com>.
On 04.06.12 17:08, Kristian Waagan wrote:
> I don't know what causes these differences, but Rick built the RC on OS
> X with a Java 6 compiler, whereas I built the sources on Solaris 11 with
> a Java 7 compiler. As a third data point I checked this with Java 7u4 on
> Linux, and here too I got an extra checkcast instruction compared to the
> RC. So this seems to be a difference between the Java 6 and Java 7
> compilers used.
FYI, I mixed up the compiler versions used. What I described above was
with a Java 6 compiler, and that resulted in a total of six differing
classes.
When using a Java 7 compiler, 34 classes end up with a different
representation when disassembled. The differences here include the ones
from above, but there are also other changes.
--
Kristian
Re: [VOTE] 10.9.1.0 release
Posted by Rick Hillegas <ri...@oracle.com>.
Patch derby-5688-10-aa-moreFilesInSourceDistro.diff adds the missing
files to source distributions. This patch has been applied to trunk,
10.9, and 10.8.
Thanks,
-Rick
On 6/4/12 8:54 AM, Rick Hillegas wrote:
> Thanks for running these experiments, Kristian. Some comments inline...
>
> On 6/4/12 8:08 AM, Kristian Waagan wrote:
>> On 01.06.12 00:10, Rick Hillegas wrote:
>>> Please test-drive the 10.9.1.0 candidate, then vote on whether to
>>> accept
>>> it as a Derby release. The candidate lives at:
>>>
>>> http://people.apache.org/~rhillegas/10.9.1.0/
>>
>> Thanks for driving the release process of 10.9, Rick!
>>
>> As one step of the testing, I decided to check if I can verify that
>> you have actually provided the bits from the 10.9 branch. There are
>> two things that need to be ascertained:
>> o That the sources are indeed the sources for 10.9.1.0.
>> o That the class files have actually been built from correct sources.
>>
>> The very first thing I did was to verify the checksums and the
>> signatures for the files I downloaded.
> Thanks. Would you mind verifying checksums and signatures for the
> remaining artifacts and then update the appropriate checklist item
> here: http://wiki.apache.org/db-derby/TenNineOneChecklist We need
> someone other than the release manager to sign off on that task.
>>
>> For the first part I simply compared the contents of the source
>> bundle with the 10.9 repository at the relevant revision. All files
>> except STATUS matched, but here the only difference was a localized
>> timestamp. This is a result of the variable substitution feature in
>> Subversion, and can be safely ignored:
>> 2c2
>> < Last modified at [$Date: 2012-05-23 14:34:52 -0700 (Wed, 23 May
>> 2012) $] by $Author: rhillegas $.
>> ---
>> > Last modified at [$Date: 2012-05-23 23:34:52 +0200 (Wed, 23 May
>> 2012) $] by $Author: rhillegas $.
>> ^^^^^^ ./STATUS
>>
>> I also discovered that the following files exist in the repository,
>> but not in the source bundle (for brevity I've removed the directory
>> listings and only included actual files):
>> 2d1
>> < ./.gitignore
>> 4804d4802
>> < ./releaseSummary.xml
>> 4852,4855d4849
>> < ./tools/l10n/build.xml
>> < ./tools/l10n/LocCompare.java
>> < ./tools/l10n/README
>> 4858,4882d4851
>> < ./tools/release/jirasoap/pom.xml
>> <
>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/DerbyVersion.java
>> <
>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueLister.java
>> <
>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueListerAntWrapper.java
>> < ./tools/release/jirasoap/src/main/wsdl/jirasoapservice-v2.wsdl
>> < ./tools/release/notices/felix.txt
>> < ./tools/release/notices/initialgrant.txt
>> < ./tools/release/notices/jdbcstubs.txt
>> < ./tools/release/notices/nisttestgrant.txt
>> < ./tools/release/notices/preamble.txt
>> < ./tools/release/notices/separator.txt
>> < ./tools/release/notices/xalan.txt
>> < ./tools/release/templates/releaseNote.html
>> < ./tools/release/templates/releaseSummaryTemplate.xml
>>
>> Is this as expected?
> I'll look into this. For the record, I have successfully built the
> docs and the jars from the source distribution so I think that we have
> built a "complete enough" release candidate. But it would be better if
> the source distribution contained the files above. Most of them are
> used for building an official Derby release, a task which can only be
> performed by the Derby community--the release building scripts will
> fail if they are run by someone who is not a Derby committer.
>>
>>
>> Things got a little more interesting for step two. Simply comparing
>> the JARs won't work, for instance there are some meta data in there
>> that will make them look different unless certain parts of the build
>> environments match. Also, I suspect the SVN revision number must be
>> set somehow if building from the source bundle (i.e. "exported" vs
>> actual revision number).
>> I ended up extracting the files in the JARs, and comparing them
>> one-by-one. I tried simple diff, but ended up disassembling the class
>> files and comparing the resulting output.
>> Overall things looked ok, but for some reason the following class
>> files differ:
>> ./org/apache/derby/iapi/services/cache/ClassSizeCatalog.class
>> ./org/apache/derby/impl/sql/compile/ResultColumnList.class
>> ./org/apache/derby/impl/sql/execute/HashTableResultSet.class
>> ./org/apache/derby/impl/sql/execute/IndexRowToBaseRowResultSet.class
>> ./org/apache/derby/impl/sql/execute/WindowResultSet.class
>> ./org/apache/derby/impl/sql/execute/ProjectRestrictResultSet.class
>>
>> Given such a small number of differences with this approach, I dug a
>> little deeper. My findings:
>> o ClassSizeCatalog: different ordering
>> o ResultSetColumnList: one extra checkcast instruction in my class
>> o HashTableResultSet: two extra checkcast instructions in my class
>> o IndexRowToBaseRowResultSet: one extra checkcast instruction in my
>> class
>> o WindowsResultSet: one extra checkcast instruction in my class
>> o ProjectRestrictResultSet: one extra checkcast instruction in my class
>>
>> I don't know what causes these differences, but Rick built the RC on
>> OS X with a Java 6 compiler, whereas I built the sources on Solaris
>> 11 with a Java 7 compiler. As a third data point I checked this with
>> Java 7u4 on Linux, and here too I got an extra checkcast instruction
>> compared to the RC. So this seems to be a difference between the Java
>> 6 and Java 7 compilers used.
>>
>> In any case, it looks like the release candidate is indeed produced
>> by building the sources from the 10.9 branch at revision 1344872 :)
>>
>>
> Good to know. Thanks!
>
Re: [VOTE] 10.9.1.0 release
Posted by Rick Hillegas <ri...@oracle.com>.
On 6/4/12 10:57 AM, Mamta Satoor wrote:
> Hi Rick,
>
> I downloaded the release and did some basic testing and that testing went fine.
>
> Mamta
Thanks, Mamta. Feel free to update the 10.9.1 checklist with your
results if any of your tests correspond to items there:
http://wiki.apache.org/db-derby/TenNineOneChecklist
Thanks,
-Rick
> On Mon, Jun 4, 2012 at 8:54 AM, Rick Hillegas<ri...@oracle.com> wrote:
>> Thanks for running these experiments, Kristian. Some comments inline...
>>
>>
>> On 6/4/12 8:08 AM, Kristian Waagan wrote:
>>> On 01.06.12 00:10, Rick Hillegas wrote:
>>>> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept
>>>> it as a Derby release. The candidate lives at:
>>>>
>>>> http://people.apache.org/~rhillegas/10.9.1.0/
>>>
>>> Thanks for driving the release process of 10.9, Rick!
>>>
>>> As one step of the testing, I decided to check if I can verify that you
>>> have actually provided the bits from the 10.9 branch. There are two things
>>> that need to be ascertained:
>>> o That the sources are indeed the sources for 10.9.1.0.
>>> o That the class files have actually been built from correct sources.
>>>
>>> The very first thing I did was to verify the checksums and the signatures
>>> for the files I downloaded.
>> Thanks. Would you mind verifying checksums and signatures for the remaining
>> artifacts and then update the appropriate checklist item here:
>> http://wiki.apache.org/db-derby/TenNineOneChecklist We need someone other
>> than the release manager to sign off on that task.
>>
>>> For the first part I simply compared the contents of the source bundle
>>> with the 10.9 repository at the relevant revision. All files except STATUS
>>> matched, but here the only difference was a localized timestamp. This is a
>>> result of the variable substitution feature in Subversion, and can be safely
>>> ignored:
>>> 2c2
>>> < Last modified at [$Date: 2012-05-23 14:34:52 -0700 (Wed, 23 May 2012) $]
>>> by $Author: rhillegas $.
>>> ---
>>>> Last modified at [$Date: 2012-05-23 23:34:52 +0200 (Wed, 23 May 2012) $]
>>>> by $Author: rhillegas $.
>>> ^^^^^^ ./STATUS
>>>
>>> I also discovered that the following files exist in the repository, but
>>> not in the source bundle (for brevity I've removed the directory listings
>>> and only included actual files):
>>> 2d1
>>> < ./.gitignore
>>> 4804d4802
>>> < ./releaseSummary.xml
>>> 4852,4855d4849
>>> < ./tools/l10n/build.xml
>>> < ./tools/l10n/LocCompare.java
>>> < ./tools/l10n/README
>>> 4858,4882d4851
>>> < ./tools/release/jirasoap/pom.xml
>>> <
>>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/DerbyVersion.java
>>> <
>>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueLister.java
>>> <
>>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueListerAntWrapper.java
>>> < ./tools/release/jirasoap/src/main/wsdl/jirasoapservice-v2.wsdl
>>> < ./tools/release/notices/felix.txt
>>> < ./tools/release/notices/initialgrant.txt
>>> < ./tools/release/notices/jdbcstubs.txt
>>> < ./tools/release/notices/nisttestgrant.txt
>>> < ./tools/release/notices/preamble.txt
>>> < ./tools/release/notices/separator.txt
>>> < ./tools/release/notices/xalan.txt
>>> < ./tools/release/templates/releaseNote.html
>>> < ./tools/release/templates/releaseSummaryTemplate.xml
>>>
>>> Is this as expected?
>> I'll look into this. For the record, I have successfully built the docs and
>> the jars from the source distribution so I think that we have built a
>> "complete enough" release candidate. But it would be better if the source
>> distribution contained the files above. Most of them are used for building
>> an official Derby release, a task which can only be performed by the Derby
>> community--the release building scripts will fail if they are run by someone
>> who is not a Derby committer.
>>
>>>
>>> Things got a little more interesting for step two. Simply comparing the
>>> JARs won't work, for instance there are some meta data in there that will
>>> make them look different unless certain parts of the build environments
>>> match. Also, I suspect the SVN revision number must be set somehow if
>>> building from the source bundle (i.e. "exported" vs actual revision number).
>>> I ended up extracting the files in the JARs, and comparing them
>>> one-by-one. I tried simple diff, but ended up disassembling the class files
>>> and comparing the resulting output.
>>> Overall things looked ok, but for some reason the following class files
>>> differ:
>>> ./org/apache/derby/iapi/services/cache/ClassSizeCatalog.class
>>> ./org/apache/derby/impl/sql/compile/ResultColumnList.class
>>> ./org/apache/derby/impl/sql/execute/HashTableResultSet.class
>>> ./org/apache/derby/impl/sql/execute/IndexRowToBaseRowResultSet.class
>>> ./org/apache/derby/impl/sql/execute/WindowResultSet.class
>>> ./org/apache/derby/impl/sql/execute/ProjectRestrictResultSet.class
>>>
>>> Given such a small number of differences with this approach, I dug a
>>> little deeper. My findings:
>>> o ClassSizeCatalog: different ordering
>>> o ResultSetColumnList: one extra checkcast instruction in my class
>>> o HashTableResultSet: two extra checkcast instructions in my class
>>> o IndexRowToBaseRowResultSet: one extra checkcast instruction in my class
>>> o WindowsResultSet: one extra checkcast instruction in my class
>>> o ProjectRestrictResultSet: one extra checkcast instruction in my class
>>>
>>> I don't know what causes these differences, but Rick built the RC on OS X
>>> with a Java 6 compiler, whereas I built the sources on Solaris 11 with a
>>> Java 7 compiler. As a third data point I checked this with Java 7u4 on
>>> Linux, and here too I got an extra checkcast instruction compared to the RC.
>>> So this seems to be a difference between the Java 6 and Java 7 compilers
>>> used.
>>>
>>> In any case, it looks like the release candidate is indeed produced by
>>> building the sources from the 10.9 branch at revision 1344872 :)
>>>
>>>
>> Good to know. Thanks!
Re: [VOTE] 10.9.1.0 release
Posted by Mamta Satoor <ms...@gmail.com>.
Hi Rick,
I downloaded the release and did some basic testing and that testing went fine.
Mamta
On Mon, Jun 4, 2012 at 8:54 AM, Rick Hillegas <ri...@oracle.com> wrote:
> Thanks for running these experiments, Kristian. Some comments inline...
>
>
> On 6/4/12 8:08 AM, Kristian Waagan wrote:
>>
>> On 01.06.12 00:10, Rick Hillegas wrote:
>>>
>>> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept
>>> it as a Derby release. The candidate lives at:
>>>
>>> http://people.apache.org/~rhillegas/10.9.1.0/
>>
>>
>> Thanks for driving the release process of 10.9, Rick!
>>
>> As one step of the testing, I decided to check if I can verify that you
>> have actually provided the bits from the 10.9 branch. There are two things
>> that need to be ascertained:
>> o That the sources are indeed the sources for 10.9.1.0.
>> o That the class files have actually been built from correct sources.
>>
>> The very first thing I did was to verify the checksums and the signatures
>> for the files I downloaded.
>
> Thanks. Would you mind verifying checksums and signatures for the remaining
> artifacts and then update the appropriate checklist item here:
> http://wiki.apache.org/db-derby/TenNineOneChecklist We need someone other
> than the release manager to sign off on that task.
>
>>
>> For the first part I simply compared the contents of the source bundle
>> with the 10.9 repository at the relevant revision. All files except STATUS
>> matched, but here the only difference was a localized timestamp. This is a
>> result of the variable substitution feature in Subversion, and can be safely
>> ignored:
>> 2c2
>> < Last modified at [$Date: 2012-05-23 14:34:52 -0700 (Wed, 23 May 2012) $]
>> by $Author: rhillegas $.
>> ---
>> > Last modified at [$Date: 2012-05-23 23:34:52 +0200 (Wed, 23 May 2012) $]
>> > by $Author: rhillegas $.
>> ^^^^^^ ./STATUS
>>
>> I also discovered that the following files exist in the repository, but
>> not in the source bundle (for brevity I've removed the directory listings
>> and only included actual files):
>> 2d1
>> < ./.gitignore
>> 4804d4802
>> < ./releaseSummary.xml
>> 4852,4855d4849
>> < ./tools/l10n/build.xml
>> < ./tools/l10n/LocCompare.java
>> < ./tools/l10n/README
>> 4858,4882d4851
>> < ./tools/release/jirasoap/pom.xml
>> <
>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/DerbyVersion.java
>> <
>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueLister.java
>> <
>> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueListerAntWrapper.java
>> < ./tools/release/jirasoap/src/main/wsdl/jirasoapservice-v2.wsdl
>> < ./tools/release/notices/felix.txt
>> < ./tools/release/notices/initialgrant.txt
>> < ./tools/release/notices/jdbcstubs.txt
>> < ./tools/release/notices/nisttestgrant.txt
>> < ./tools/release/notices/preamble.txt
>> < ./tools/release/notices/separator.txt
>> < ./tools/release/notices/xalan.txt
>> < ./tools/release/templates/releaseNote.html
>> < ./tools/release/templates/releaseSummaryTemplate.xml
>>
>> Is this as expected?
>
> I'll look into this. For the record, I have successfully built the docs and
> the jars from the source distribution so I think that we have built a
> "complete enough" release candidate. But it would be better if the source
> distribution contained the files above. Most of them are used for building
> an official Derby release, a task which can only be performed by the Derby
> community--the release building scripts will fail if they are run by someone
> who is not a Derby committer.
>
>>
>>
>> Things got a little more interesting for step two. Simply comparing the
>> JARs won't work, for instance there are some meta data in there that will
>> make them look different unless certain parts of the build environments
>> match. Also, I suspect the SVN revision number must be set somehow if
>> building from the source bundle (i.e. "exported" vs actual revision number).
>> I ended up extracting the files in the JARs, and comparing them
>> one-by-one. I tried simple diff, but ended up disassembling the class files
>> and comparing the resulting output.
>> Overall things looked ok, but for some reason the following class files
>> differ:
>> ./org/apache/derby/iapi/services/cache/ClassSizeCatalog.class
>> ./org/apache/derby/impl/sql/compile/ResultColumnList.class
>> ./org/apache/derby/impl/sql/execute/HashTableResultSet.class
>> ./org/apache/derby/impl/sql/execute/IndexRowToBaseRowResultSet.class
>> ./org/apache/derby/impl/sql/execute/WindowResultSet.class
>> ./org/apache/derby/impl/sql/execute/ProjectRestrictResultSet.class
>>
>> Given such a small number of differences with this approach, I dug a
>> little deeper. My findings:
>> o ClassSizeCatalog: different ordering
>> o ResultSetColumnList: one extra checkcast instruction in my class
>> o HashTableResultSet: two extra checkcast instructions in my class
>> o IndexRowToBaseRowResultSet: one extra checkcast instruction in my class
>> o WindowsResultSet: one extra checkcast instruction in my class
>> o ProjectRestrictResultSet: one extra checkcast instruction in my class
>>
>> I don't know what causes these differences, but Rick built the RC on OS X
>> with a Java 6 compiler, whereas I built the sources on Solaris 11 with a
>> Java 7 compiler. As a third data point I checked this with Java 7u4 on
>> Linux, and here too I got an extra checkcast instruction compared to the RC.
>> So this seems to be a difference between the Java 6 and Java 7 compilers
>> used.
>>
>> In any case, it looks like the release candidate is indeed produced by
>> building the sources from the 10.9 branch at revision 1344872 :)
>>
>>
> Good to know. Thanks!
Re: [VOTE] 10.9.1.0 release
Posted by Rick Hillegas <ri...@oracle.com>.
Thanks for running these experiments, Kristian. Some comments inline...
On 6/4/12 8:08 AM, Kristian Waagan wrote:
> On 01.06.12 00:10, Rick Hillegas wrote:
>> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept
>> it as a Derby release. The candidate lives at:
>>
>> http://people.apache.org/~rhillegas/10.9.1.0/
>
> Thanks for driving the release process of 10.9, Rick!
>
> As one step of the testing, I decided to check if I can verify that
> you have actually provided the bits from the 10.9 branch. There are
> two things that need to be ascertained:
> o That the sources are indeed the sources for 10.9.1.0.
> o That the class files have actually been built from correct sources.
>
> The very first thing I did was to verify the checksums and the
> signatures for the files I downloaded.
Thanks. Would you mind verifying checksums and signatures for the
remaining artifacts and then update the appropriate checklist item here:
http://wiki.apache.org/db-derby/TenNineOneChecklist We need someone
other than the release manager to sign off on that task.
>
> For the first part I simply compared the contents of the source bundle
> with the 10.9 repository at the relevant revision. All files except
> STATUS matched, but here the only difference was a localized
> timestamp. This is a result of the variable substitution feature in
> Subversion, and can be safely ignored:
> 2c2
> < Last modified at [$Date: 2012-05-23 14:34:52 -0700 (Wed, 23 May
> 2012) $] by $Author: rhillegas $.
> ---
> > Last modified at [$Date: 2012-05-23 23:34:52 +0200 (Wed, 23 May
> 2012) $] by $Author: rhillegas $.
> ^^^^^^ ./STATUS
>
> I also discovered that the following files exist in the repository,
> but not in the source bundle (for brevity I've removed the directory
> listings and only included actual files):
> 2d1
> < ./.gitignore
> 4804d4802
> < ./releaseSummary.xml
> 4852,4855d4849
> < ./tools/l10n/build.xml
> < ./tools/l10n/LocCompare.java
> < ./tools/l10n/README
> 4858,4882d4851
> < ./tools/release/jirasoap/pom.xml
> <
> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/DerbyVersion.java
> <
> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueLister.java
> <
> ./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueListerAntWrapper.java
> < ./tools/release/jirasoap/src/main/wsdl/jirasoapservice-v2.wsdl
> < ./tools/release/notices/felix.txt
> < ./tools/release/notices/initialgrant.txt
> < ./tools/release/notices/jdbcstubs.txt
> < ./tools/release/notices/nisttestgrant.txt
> < ./tools/release/notices/preamble.txt
> < ./tools/release/notices/separator.txt
> < ./tools/release/notices/xalan.txt
> < ./tools/release/templates/releaseNote.html
> < ./tools/release/templates/releaseSummaryTemplate.xml
>
> Is this as expected?
I'll look into this. For the record, I have successfully built the docs
and the jars from the source distribution so I think that we have built
a "complete enough" release candidate. But it would be better if the
source distribution contained the files above. Most of them are used for
building an official Derby release, a task which can only be performed
by the Derby community--the release building scripts will fail if they
are run by someone who is not a Derby committer.
>
>
> Things got a little more interesting for step two. Simply comparing
> the JARs won't work, for instance there are some meta data in there
> that will make them look different unless certain parts of the build
> environments match. Also, I suspect the SVN revision number must be
> set somehow if building from the source bundle (i.e. "exported" vs
> actual revision number).
> I ended up extracting the files in the JARs, and comparing them
> one-by-one. I tried simple diff, but ended up disassembling the class
> files and comparing the resulting output.
> Overall things looked ok, but for some reason the following class
> files differ:
> ./org/apache/derby/iapi/services/cache/ClassSizeCatalog.class
> ./org/apache/derby/impl/sql/compile/ResultColumnList.class
> ./org/apache/derby/impl/sql/execute/HashTableResultSet.class
> ./org/apache/derby/impl/sql/execute/IndexRowToBaseRowResultSet.class
> ./org/apache/derby/impl/sql/execute/WindowResultSet.class
> ./org/apache/derby/impl/sql/execute/ProjectRestrictResultSet.class
>
> Given such a small number of differences with this approach, I dug a
> little deeper. My findings:
> o ClassSizeCatalog: different ordering
> o ResultSetColumnList: one extra checkcast instruction in my class
> o HashTableResultSet: two extra checkcast instructions in my class
> o IndexRowToBaseRowResultSet: one extra checkcast instruction in my
> class
> o WindowsResultSet: one extra checkcast instruction in my class
> o ProjectRestrictResultSet: one extra checkcast instruction in my class
>
> I don't know what causes these differences, but Rick built the RC on
> OS X with a Java 6 compiler, whereas I built the sources on Solaris 11
> with a Java 7 compiler. As a third data point I checked this with Java
> 7u4 on Linux, and here too I got an extra checkcast instruction
> compared to the RC. So this seems to be a difference between the Java
> 6 and Java 7 compilers used.
>
> In any case, it looks like the release candidate is indeed produced by
> building the sources from the 10.9 branch at revision 1344872 :)
>
>
Good to know. Thanks!
Re: [VOTE] 10.9.1.0 release
Posted by Kristian Waagan <kr...@oracle.com>.
On 01.06.12 00:10, Rick Hillegas wrote:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept
> it as a Derby release. The candidate lives at:
>
> http://people.apache.org/~rhillegas/10.9.1.0/
Thanks for driving the release process of 10.9, Rick!
As one step of the testing, I decided to check if I can verify that you
have actually provided the bits from the 10.9 branch. There are two
things that need to be ascertained:
o That the sources are indeed the sources for 10.9.1.0.
o That the class files have actually been built from correct sources.
The very first thing I did was to verify the checksums and the
signatures for the files I downloaded.
For the first part I simply compared the contents of the source bundle
with the 10.9 repository at the relevant revision. All files except
STATUS matched, but here the only difference was a localized timestamp.
This is a result of the variable substitution feature in Subversion, and
can be safely ignored:
2c2
< Last modified at [$Date: 2012-05-23 14:34:52 -0700 (Wed, 23 May 2012)
$] by $Author: rhillegas $.
---
> Last modified at [$Date: 2012-05-23 23:34:52 +0200 (Wed, 23 May 2012)
$] by $Author: rhillegas $.
^^^^^^ ./STATUS
I also discovered that the following files exist in the repository, but
not in the source bundle (for brevity I've removed the directory
listings and only included actual files):
2d1
< ./.gitignore
4804d4802
< ./releaseSummary.xml
4852,4855d4849
< ./tools/l10n/build.xml
< ./tools/l10n/LocCompare.java
< ./tools/l10n/README
4858,4882d4851
< ./tools/release/jirasoap/pom.xml
<
./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/DerbyVersion.java
<
./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueLister.java
<
./tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueListerAntWrapper.java
< ./tools/release/jirasoap/src/main/wsdl/jirasoapservice-v2.wsdl
< ./tools/release/notices/felix.txt
< ./tools/release/notices/initialgrant.txt
< ./tools/release/notices/jdbcstubs.txt
< ./tools/release/notices/nisttestgrant.txt
< ./tools/release/notices/preamble.txt
< ./tools/release/notices/separator.txt
< ./tools/release/notices/xalan.txt
< ./tools/release/templates/releaseNote.html
< ./tools/release/templates/releaseSummaryTemplate.xml
Is this as expected?
Things got a little more interesting for step two. Simply comparing the
JARs won't work, for instance there are some meta data in there that
will make them look different unless certain parts of the build
environments match. Also, I suspect the SVN revision number must be set
somehow if building from the source bundle (i.e. "exported" vs actual
revision number).
I ended up extracting the files in the JARs, and comparing them
one-by-one. I tried simple diff, but ended up disassembling the class
files and comparing the resulting output.
Overall things looked ok, but for some reason the following class files
differ:
./org/apache/derby/iapi/services/cache/ClassSizeCatalog.class
./org/apache/derby/impl/sql/compile/ResultColumnList.class
./org/apache/derby/impl/sql/execute/HashTableResultSet.class
./org/apache/derby/impl/sql/execute/IndexRowToBaseRowResultSet.class
./org/apache/derby/impl/sql/execute/WindowResultSet.class
./org/apache/derby/impl/sql/execute/ProjectRestrictResultSet.class
Given such a small number of differences with this approach, I dug a
little deeper. My findings:
o ClassSizeCatalog: different ordering
o ResultSetColumnList: one extra checkcast instruction in my class
o HashTableResultSet: two extra checkcast instructions in my class
o IndexRowToBaseRowResultSet: one extra checkcast instruction in my class
o WindowsResultSet: one extra checkcast instruction in my class
o ProjectRestrictResultSet: one extra checkcast instruction in my class
I don't know what causes these differences, but Rick built the RC on OS
X with a Java 6 compiler, whereas I built the sources on Solaris 11 with
a Java 7 compiler. As a third data point I checked this with Java 7u4 on
Linux, and here too I got an extra checkcast instruction compared to the
RC. So this seems to be a difference between the Java 6 and Java 7
compilers used.
In any case, it looks like the release candidate is indeed produced by
building the sources from the 10.9 branch at revision 1344872 :)
--
Kristian
>
> The polls close at 5:00 pm San Francisco time on Thursday, June 21.
>
> 10.9.1.0 is a feature release, described in greater detail here:
> http://wiki.apache.org/db-derby/DerbyTenNineOneRelease
>
> Thanks to everyone who contributed to this release.
>
> Regards,
> -Rick
>
Re: [VOTE] 10.9.1.0 release
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@oracle.com> writes:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to
> accept it as a Derby release.
The test results look good, and the release candidate contains many
useful fixes and improvements. +1 to release it.
Thanks,
--
Knut Anders
Re: [VOTE] 10.9.1.0 release
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Myrna van Lunteren <m....@gmail.com> writes:
> +1 to making this a release. Thanks for the herding Rick - and thanks
> everyone for all the work.
+1
Dag
Re: [VOTE] 10.9.1.0 release
Posted by Myrna van Lunteren <m....@gmail.com>.
On Thu, May 31, 2012 at 3:10 PM, Rick Hillegas <ri...@oracle.com> wrote:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept it
> as a Derby release. The candidate lives at:
>
> http://people.apache.org/~rhillegas/10.9.1.0/
>
> The polls close at 5:00 pm San Francisco time on Thursday, June 21.
>
> 10.9.1.0 is a feature release, described in greater detail here:
> http://wiki.apache.org/db-derby/DerbyTenNineOneRelease
>
> Thanks to everyone who contributed to this release.
>
> Regards,
> -Rick
>
+1 to making this a release. Thanks for the herding Rick - and thanks
everyone for all the work.
Myrna
Re: [VOTE] 10.9.1.0 release
Posted by Mike Matrigali <mi...@sbcglobal.net>.
I worked with mamta on sequence and identity testing and results look as
expected. All platform tests I have seen look good for a release. All
looks good for a release. Thanks, rick.
+1
On 5/31/2012 3:10 PM, Rick Hillegas wrote:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to accept
> it as a Derby release. The candidate lives at:
>
> http://people.apache.org/~rhillegas/10.9.1.0/
>
> The polls close at 5:00 pm San Francisco time on Thursday, June 21.
>
> 10.9.1.0 is a feature release, described in greater detail here:
> http://wiki.apache.org/db-derby/DerbyTenNineOneRelease
>
> Thanks to everyone who contributed to this release.
>
> Regards,
> -Rick
>
>
Re: [VOTE] 10.9.1.0 release
Posted by Rick Hillegas <ri...@oracle.com>.
On 5/31/12 3:10 PM, Rick Hillegas wrote:
> Please test-drive the 10.9.1.0 candidate, then vote on whether to
> accept it as a Derby release. The candidate lives at:
>
> http://people.apache.org/~rhillegas/10.9.1.0/
>
> The polls close at 5:00 pm San Francisco time on Thursday, June 21.
>
> 10.9.1.0 is a feature release, described in greater detail here:
> http://wiki.apache.org/db-derby/DerbyTenNineOneRelease
>
> Thanks to everyone who contributed to this release.
>
> Regards,
> -Rick
>
>
Note that the release generation script still produces an eclipse plugin
even though we decided that we won't publish this artifact with the 10.9
release. Now would be a good time for an eclipse user to volunteer to
produce plugins and figure out where they should be published on the
eclipse website. I assume that publication has to follow the Derby
community's vote on 10.9.1.
Thanks,
-Rick