harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Date Tue, 09 Mar 2010 13:58:31 GMT
Sorry for coming late to this thread, I hope I've caught up on the
progress made so far, and let me start by saying "thanks" for addressing
these single-handedly!

On 09/Mar/2010 10:16, Mark Hindess wrote:
> In message <25aac9fc1003061424k3b553399pb22caa75b6d87487@mail.gmail.com>,
> sebb writes:
>> On 06/03/2010, Mark Hindess <mark.hindess@googlemail.com> wrote:
>>> In message <25aac9fc1003060444j7b9b083fgdf5b2fb7b3dbfe6@mail.gmail.com>,
>>> sebb writes:
>>>> On 06/03/2010, Mark Hindess <mark.hindess@googlemail.com> wrote:
>>>>> Thanks Sebb.
>>>>>
>>>>> In message
>>>>> <25aac9fc1003051528k696407f1q198446e344cd1622@mail.gmail.com>,
>>>>>
>>>>> sebb writes:
>>>>>> The NOTICE file is out of date:
>>>>>>
>>>>>> Apache Harmony
>>>>>> Copyright 2006, 2009 The Apache Software Foundation.
>>>>>
>>>>> Fixed in trunk source trees. Merges should fix the other
>>>>> instances.
> 
> Merges done so these should be fixed.
> 
>>>>>> There's a META-INF directory with N&L files in tools-src.jar
>>>>>> but not in tools.jar
>>>>> Which tools.jar in which artifact is missing
>>>>> N&L files?  Looking at the jar tasks in
>>>>> working_jdktools/modules/{jre,jdk}tools/build.xml both the
>>>>> tools.jar and tools-src.jar tasks look to have the manifest
>>>>> elements I'd expect and looking at a sample of the artifacts the
>>>>> jdk/lib/tools.jar and jre/ lib/tools.jar files seem to have the
>>>>> N&L files.
>>>> Sorry, my mistake, they do have META-INF directories and N&L
>>>> files.
>>>>
>>>> However the following Manifest entry is wrong:
>>>>
>>>> Implementation-URL: http://incubator.apache.org/harmony
>>>>
>>>> jdtstup*.jar have the same obsolete entries in their Manifests:
>>> Fixed in r919839.
>>>
>>>> Ideally all the META-INF entries should be added together at the
>>>> beginning of the archive - at present the Manifest is first, and N&L
>>>> are last. Definitely not a blocker.
>>> Aside from aesthetics, why?
>> So they appear first when listing the jar to draw attention to them.
>>
>> See also:
>>
>> http://www.apache.org/dev/apply-license.html#new
> 
> Fair enough.  Fixed.
> 
>>>>>  > The MANIFEST.MF files should ideally contain details for the
>>>>>  > following headers:
>>>>>  >
>>>>>  > Specification-Title
>>>>>  > Specification-Version
>>>>>  > Specification-Vendor
>>>>>  > Implementation-Title
>>>>>  > Implementation-Version
>>>>>  > Implementation-Vendor
>>>>>  > Implementation-Vendor-Id
>>>>>  >
>>>>>  > Not relevant for source jars:
>>>>>  > X-Compile-Source-JDK
>>>>>  > X-Compile-Target-JDK
>>>>>
>>>>>
>>>>> These will take a bit more effort; A JIRA should probably be targeted
to
>>>>>  the next release to cover this task.
>>>> Only the Specification-Vendor and X-Compile headers are missing, so
>>>> probably quite easy to add these.
>>> You'd think it would be quite easy, with only 120 <jar> tasks to
>>> correct.
>> Oh - I'd assumed there was just one common routine to do this.
> 
> I've fixed most of these except Specification-Vendor.  I'll do this
> before the 5.0M14/6.0M2 releases.
> 
>>> However, I'm not exactly sure what X-Compile headers would be
>>> appropriate for modules like pack200.jar which have some code compiled
>>> with 1.4/1.4 and some compiled with 1.5/1.5.  I'd welcome your opinion.
>> Never come across that before.
>>
>> In a jar, I think the header is most useful for recording the target
>> JVM version. So if the jar can only be run using Java 1.5, use that.
>> If it can be run on both, then perhaps use both.
>>
>> The header values are only used for documentation, so you could use:
>>
>> 1.5 (parts 1.4)
>>
>> for source and target.
> 
> Done.  Thanks.
> 
>>>> https://issues.apache.org/jira/browse/HARMONY-6462
> 
> I'll leave this open until I've fixed the Specification-Vendor entries.
> 
>>>>>> There are a lot of source files that don't have AL headers, for
>>>>>> example:
>>>>>>
>>>>>> working_classlib/depends/libs/build/fetch-awt-depends.sh
>>>>> This one is trivial and can be removed now.  I wont do it right away
>>>>> because I think the README in the same directory also needs work too.
>>> I've removed the script but left the README to be addressed later.
>>>
>>>>>> working_classlib/doc/harmony.css
>>>>>> working_classlib/doc/hydoxygen.css
>>>>> I'm not sure whether these are generated.  Certainly according to
>>>>> google, the hydoxygen.css comment "end styling for detailed member
>>>>> documentation" appears in non-ALv2 files, though some ALv2 files too.
>>> I'm still not sure about these.
>> Who created it? If it was created at the ASF, then it should have the
>> AL header.  If not, then it probably needs to be mentioned in the N &
>> L files (perhaps it is already) and it would do no harm to add short
>> comment in the file itself, not least to avoid questions later.
> 
> Sorry, I meant I wasn't sure about them because I'd not looked at the
> history rather than because I wasn't sure what to do.  I have now and
> they are fixed.
> 
>>>>>> working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/java/sql/SQLClientInfoExceptionTest.java
>>>>>> working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/javax/sql/StatementEventTest.java
>>>>>> working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/javax/sql/rowset/MockNClob.java
>>>>>> working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/javax/sql/rowset/MockRowId.java
>>>>>> working_classlib/modules/sql/src/test/java/org/apache/harmony/sql/tests/javax/sql/rowset/MockSQLXML.java
>>> Fixed in r919849.
>>>
>>>>>> working_vm/vm/tests/ncai/funcs/**
>>> Fixed in r919853 subject to merging from trunk.
>>>
>>>>> Will have to have a closer look at these but I suspect most are
>>>>> just missing headers.
>>>> https://issues.apache.org/jira/browse/HARMONY-6463 - JIRA with the
>>>> full list attached.
> 
>>> Aside: Quite a few of the files RAT complains about are empty except
>>> for whitespace.  Perhaps RAT should skip these?
>> Yes, it should. RAT has some false positives.
>>
>>> I'll get to the rest when I get more time.
> 
> I've done most of these now.
> 
> Can you take a look at the latest artifacts at:
> 
>   http://people.apache.org/~hindessm/sebb/
> 
> Do these look better?
> 
>>>>>> Perhaps some of these are not ASF source, but it looks like
>>>>>> many of them are.
>>>>> I'm assuming most of these shouldn't stop the already-voted-for
>>>>> releases.
>>>> IMO having so many missing AL headers is a blocker.
>>> Thanks for the clarification.  I assumed you thought that or you
>>> wouldn't have raised these issues on a [vote] thread. ;-)
>>>
>>> I was really soliciting the opinions of the others who voted and
>>> Harmony PMC members.
>>>
>>>>> The NOTICE year is rather annoying though.  What do other people
>>>>> think?
>>> ?
> 
> I'd still *really* like the opinions of the others who voted and Harmony
> PMC members.  Do you think this should block the already-voted-for
> release?

No.  I don't see which of these would invalidate the release we already
voted.  I appreciate sebb's review and comments.  It would have been
good to hear them during the two week freeze leading up to the vote
rather than after the vote was concluded :-)

The comments are in the most part valid (order of entries in a JAR is a
bit extreme IMHO), and the most important are probably missing standard
headers.  Even so, these are informational and do not alter the status
of the code in the release, so it is correct to fix them so we are in
adherence of the foundation policy, but they should not block 6.0M1.

> I think stopping an already-voted-for release sets a bad precedent
> Testing should happen before/during the vote and if more time is
> required then people should ask (as Tim did).  However, also I want to
> make a good release.

We all do, and again, all constructive comments are welcome.  Each
release has known issues, there is a call to make on what should block
us making progress.

> I will *not* be making this decision one way or another until I get some
> indication of the opinions of others who voted.

My opinion is release 6.0M1 as originally voted.  Fix these issues in
the open stream and thank contributors for making M2 so much better.

Regards,
Tim

Mime
View raw message