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!
