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