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<[email protected]>  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!

Reply via email to