db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: [VOTE] 10.9.1.0 release
Date Mon, 04 Jun 2012 18:05:16 GMT
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<rick.hillegas@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!


Mime
View raw message