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 <[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!
