You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2010/03/01 19:50:08 UTC
[vote] Declare r917296 as 6.0 Milestone 1
I have created signed source archives for revision r917296 of the
java6 branch and made them available at:
http://people.apache.org/~hindessm/milestones/6.0M1/
Please test these artifacts and then vote for declaring these source
archives as 6.0 Milestone 1.
This vote will be open for at least three days, or until all binding
votes have been cast (if earlier).
If the vote is successful, binary builds from these artifacts will be
made available on the download page.
Regards,
Mark.
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by Tim Ellison <t....@gmail.com>.
+1 from me
Tested using Windows XP SP3 with VS2003. Test results were same as the
5.0M13 test results. Sig, and checksums ok.
Regards,
Tim
On 01/Mar/2010 18:50, Mark Hindess wrote:
> I have created signed source archives for revision r917296 of the
> java6 branch and made them available at:
>
> http://people.apache.org/~hindessm/milestones/6.0M1/
>
> Please test these artifacts and then vote for declaring these source
> archives as 6.0 Milestone 1.
>
> This vote will be open for at least three days, or until all binding
> votes have been cast (if earlier).
>
> If the vote is successful, binary builds from these artifacts will be
> made available on the download page.
>
> Regards,
> Mark.
>
>
>
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by "Jimmy,Jing Lv" <fi...@gmail.com>.
+1 looks fine on my windows xp 32 sp2
2010/3/2 Mark Hindess <ma...@googlemail.com>
>
> I have created signed source archives for revision r917296 of the
> java6 branch and made them available at:
>
> http://people.apache.org/~hindessm/milestones/6.0M1/<http://people.apache.org/%7Ehindessm/milestones/6.0M1/>
>
> Please test these artifacts and then vote for declaring these source
> archives as 6.0 Milestone 1.
>
> This vote will be open for at least three days, or until all binding
> votes have been cast (if earlier).
>
> If the vote is successful, binary builds from these artifacts will be
> made available on the download page.
>
> Regards,
> Mark.
>
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by Oliver Deakin <ol...@googlemail.com>.
+1
I built and tested on Windows XP x86 and see no unexpected failures.
Regards,
Oliver
On 01/03/2010 18:50, Mark Hindess wrote:
> I have created signed source archives for revision r917296 of the
> java6 branch and made them available at:
>
> http://people.apache.org/~hindessm/milestones/6.0M1/
>
> Please test these artifacts and then vote for declaring these source
> archives as 6.0 Milestone 1.
>
> This vote will be open for at least three days, or until all binding
> votes have been cast (if earlier).
>
> If the vote is successful, binary builds from these artifacts will be
> made available on the download page.
>
> Regards,
> Mark.
>
>
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by Nathan Beyer <nd...@apache.org>.
+1
Built and tested on Windows XP SP3, VS2008
On Mon, Mar 1, 2010 at 12:50 PM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> I have created signed source archives for revision r917296 of the
> java6 branch and made them available at:
>
> http://people.apache.org/~hindessm/milestones/6.0M1/
>
> Please test these artifacts and then vote for declaring these source
> archives as 6.0 Milestone 1.
>
> This vote will be open for at least three days, or until all binding
> votes have been cast (if earlier).
>
> If the vote is successful, binary builds from these artifacts will be
> made available on the download page.
>
> Regards,
> Mark.
>
>
>
Re: [general] Release process (was [result][vote]Declare r917296 as
6.0M1)
Posted by sebb <se...@gmail.com>.
On 09/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
>
> In message <4B...@gmail.com>, Tim Ellison writes:
> >
> > 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 :-)
>
> This comment isn't entirely fair.
Thanks!
In all other TLPs that I follow, the process is to create a full
release candidate with hashes and sigs etc. as well as a release tag.
The whole bundle can then be reviewed as an item, and any discrepancies noted.
[For example - the source archive does not match the tag]
Blocking problems are fixed, and the process repeated with a new
release candidate and tag. Other problems may or may not be fixed.
When the release candidate passes, the artifacts can be released, and
the SVN tag is renamed as the release tag.
Obviously, if problems are noticed earlier then they can be reported
earlier, but it is expected that release candidates will fail from
time to time.
I'd just add that fixing AL issues may be a bit of a pain initially,
but should be a one-off.
> Sebb's initial review comments
> were about the binaries which we only created after the release was
> "completed". This is one reason why I had more sympathy for his view
> that the release should be cancelled.
>
> I also appreciate sebb's comments. So, while he could have made them
> by building our source and reviewing the resulting binaries, perhaps we
> should attempt to make this kind of review easier?
>
> It is tricky to see how to do this while still placing the emphasis on
> voting on source releases.
>
> It would be more work but perhaps we should create "minimal" binaries
> (one hdk bundle should be sufficient perhaps one windows and one linux)
> at the start of the feature freeze period?
>
> Any thoughts?
>
> Regards,
>
> Mark.
>
>
>
Re: [general] Release process (was [result][vote]Declare r917296 as 6.0M1)
Posted by Mark Hindess <ma...@googlemail.com>.
In message <3b...@mail.gmail.com>, Natha
n Beyer writes:
>
> On Tue, Mar 9, 2010 at 9:38 AM, Mark Hindess
> <ma...@googlemail.com> wrote:
> >
> > In message <4B...@gmail.com>, Tim Ellison writes:
> >>
> >> 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 :-)
> >
> > This comment isn't entirely fair. Sebb's initial review comments
> > were about the binaries which we only created after the release was
> > "completed". This is one reason why I had more sympathy for his
> > view that the release should be cancelled.
> >
> > I also appreciate sebb's comments. So, while he could have made them
> > by building our source and reviewing the resulting binaries, perhaps
> > we should attempt to make this kind of review easier?
>
> Don't we have binary builds coming out of Hudson periodically?
Indeed. Though they are built from svn directly rather than from svn
via source artifacts, so I worry we'd miss something that would affect
the release.
-Mark.
Re: [general] Release process (was [result][vote]Declare r917296 as
6.0M1)
Posted by Nathan Beyer <nd...@apache.org>.
On Tue, Mar 9, 2010 at 9:38 AM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> In message <4B...@gmail.com>, Tim Ellison writes:
>>
>> 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 :-)
>
> This comment isn't entirely fair. Sebb's initial review comments
> were about the binaries which we only created after the release was
> "completed". This is one reason why I had more sympathy for his view
> that the release should be cancelled.
>
> I also appreciate sebb's comments. So, while he could have made them
> by building our source and reviewing the resulting binaries, perhaps we
> should attempt to make this kind of review easier?
Don't we have binary builds coming out of Hudson periodically?
>
> It is tricky to see how to do this while still placing the emphasis on
> voting on source releases.
>
> It would be more work but perhaps we should create "minimal" binaries
> (one hdk bundle should be sufficient perhaps one windows and one linux)
> at the start of the feature freeze period?
>
> Any thoughts?
>
> Regards,
> Mark.
>
>
>
[general] Release process (was [result][vote]Declare r917296 as 6.0M1)
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4B...@gmail.com>, Tim Ellison writes:
>
> 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 :-)
This comment isn't entirely fair. Sebb's initial review comments
were about the binaries which we only created after the release was
"completed". This is one reason why I had more sympathy for his view
that the release should be cancelled.
I also appreciate sebb's comments. So, while he could have made them
by building our source and reviewing the resulting binaries, perhaps we
should attempt to make this kind of review easier?
It is tricky to see how to do this while still placing the emphasis on
voting on source releases.
It would be more work but perhaps we should create "minimal" binaries
(one hdk bundle should be sufficient perhaps one windows and one linux)
at the start of the feature freeze period?
Any thoughts?
Regards,
Mark.
Re: Distributing milestones
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4B...@gmail.com>, Tim Ellison writes:
>
> On 09/Mar/2010 15:57, Mark Hindess wrote:
> > In message <4B...@gmail.com>, Tim Ellison writes:
> >> On 09/Mar/2010 14:53, Mark Hindess wrote:
> >>> It feels like we have some consensus. So, please can people sanity
> >>> check the binary artifacts in:
> >>>
> >>> http://people.apache.org/~hindessm/milestones/
> >> Will do.
> >
> > Thanks.
>
> The binaries look sane to me. Basic sniff testing works fine.
Okay. I populated the /dist/ tree at 17:20 UTC.
> (It would be advisable to upgrade your signing key to 4096bit at some
> point.)
Yes. That's on my todo list.
Thanks,
-Mark.
Re: Distributing milestones
Posted by Tim Ellison <t....@gmail.com>.
On 09/Mar/2010 15:57, Mark Hindess wrote:
> In message <4B...@gmail.com>, Tim Ellison writes:
>> On 09/Mar/2010 14:53, Mark Hindess wrote:
>>> It feels like we have some consensus. So, please can people sanity
>>> check the binary artifacts in:
>>>
>>> http://people.apache.org/~hindessm/milestones/
>> Will do.
>
> Thanks.
The binaries look sane to me. Basic sniff testing works fine.
(It would be advisable to upgrade your signing key to 4096bit at some
point.)
Regards,
Tim
>>> I'll aim to move them to the /dist/ tree tomorrow or earlier if I
>>> get confirmation that they've been checked.
>> What's the plan for restructuring the dist directory to accommodate
>> the 6.0 milestones?
>>
>> /dist/harmony/milestones/5.0/M13
>> /dist/harmony/milestones/6.0/M1
>>
>> and leave the existing archive directories
>>
>> /dist/harmony/milestones/M1
>> ...
>
> This was the option that I had in mind.
>
> Additionally, I was thinking that I'd probably create symlinks for:
>
> /dist/harmony/milestones/5.0/M1 => ../M1
> /dist/harmony/milestones/5.0/M2 => ../M2
>
> and remove them once they'd made it to the archive. This would mean
> there'd be a single archive URL to reference all the 5.0 milestone
> releases.
>
>> or maybe
>>
>> /dist/harmony/milestones/M13
>> /dist/harmony/milestones/6.0M1
>
> Ick!
>
>> or ??
>>
>>> Thanks for helping move this forward.
>> I'll help to update the download page if that helps.
>
> Excellent. Thanks.
>
> Regards,
> Mark.
>
>
>
Re: Distributing milestones (was: Re: [result] [vote] Declare r917296 as 6.0 Milestone 1)
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4B...@gmail.com>, Tim Ellison writes:
>
> On 09/Mar/2010 14:53, Mark Hindess wrote:
> >
> > It feels like we have some consensus. So, please can people sanity
> > check the binary artifacts in:
> >
> > http://people.apache.org/~hindessm/milestones/
>
> Will do.
Thanks.
> > I'll aim to move them to the /dist/ tree tomorrow or earlier if I
> > get confirmation that they've been checked.
>
> What's the plan for restructuring the dist directory to accommodate
> the 6.0 milestones?
>
> /dist/harmony/milestones/5.0/M13
> /dist/harmony/milestones/6.0/M1
>
> and leave the existing archive directories
>
> /dist/harmony/milestones/M1
> ...
This was the option that I had in mind.
Additionally, I was thinking that I'd probably create symlinks for:
/dist/harmony/milestones/5.0/M1 => ../M1
/dist/harmony/milestones/5.0/M2 => ../M2
and remove them once they'd made it to the archive. This would mean
there'd be a single archive URL to reference all the 5.0 milestone
releases.
> or maybe
>
> /dist/harmony/milestones/M13
> /dist/harmony/milestones/6.0M1
Ick!
> or ??
>
> > Thanks for helping move this forward.
>
> I'll help to update the download page if that helps.
Excellent. Thanks.
Regards,
Mark.
Distributing milestones (was: Re: [result] [vote] Declare r917296
as 6.0 Milestone 1)
Posted by Tim Ellison <t....@gmail.com>.
On 09/Mar/2010 14:53, Mark Hindess wrote:
> It feels like we have some consensus. So, please can people sanity
> check the binary artifacts in:
>
> http://people.apache.org/~hindessm/milestones/
Will do.
> I'll aim to move them to the /dist/ tree tomorrow or earlier if I get
> confirmation that they've been checked.
What's the plan for restructuring the dist directory to accommodate the
6.0 milestones?
/dist/harmony/milestones/5.0/M13
/dist/harmony/milestones/6.0/M1
and leave the existing archive directories
/dist/harmony/milestones/M1
...
or maybe
/dist/harmony/milestones/M13
/dist/harmony/milestones/6.0M1
or ??
> Thanks for helping move this forward.
I'll help to update the download page if that helps.
Regards,
Tim
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4B...@googlemail.com>, Oliver Deakin writes:
>
> Just back from a week's vacation and catching up on this thread...
>
> On 09/03/2010 13:58, Tim Ellison wrote:
> >
> > 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!
No problem. If we were going to redo the release I wanted to be ready
sooner rather than later.
There are still plenty of issues to fix but I might slow down a bit now.
> > On 09/Mar/2010 10:16, Mark Hindess wrote:
> >
> >> <SNIP>
> >>>>
> >>>>>> 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.
>
> +1. It's great that Sebb has raised these issues, but I don't think
> they are blockers for the M1 we have already voted on. I vote for
> fixing them in the M2 release and going ahead with M1 as is (although
> I do agree, the incorrect year in the notice file is annoying).
>
> Were all the errors listed in this thread detected by the RAT tool?
> Would it be possible to automate this tool as part of our Hudson
> builds so we find out about issues as soon as they are introduced?
FYI: you can run rat on the federated build source with:
RAT_HOME=/path/to/rat/built/svn/checkout \
ant -lib $RAT_HOME/target/apache-rat-0.7-SNAPSHOT.jar \
-Drat.home=$RAT_HOME rat
It creates a report in target/rat.report.txt.
> >> 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.
That was my opinion too but it didn't seem right push ahead when the
only other "voice" was opposed.
It feels like we have some consensus. So, please can people sanity
check the binary artifacts in:
http://people.apache.org/~hindessm/milestones/
I'll aim to move them to the /dist/ tree tomorrow or earlier if I get
confirmation that they've been checked.
Thanks for helping move this forward.
Regards,
Mark.
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by Oliver Deakin <ol...@googlemail.com>.
Just back from a week's vacation and catching up on this thread...
On 09/03/2010 13:58, Tim Ellison wrote:
> 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:
>
>> <SNIP>
>>>>
>>>>>> 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.
>
+1. It's great that Sebb has raised these issues, but I don't think they
are blockers for the M1 we have already voted on. I vote for fixing them
in the M2 release and going ahead with M1 as is (although I do agree,
the incorrect year in the notice file is annoying).
Were all the errors listed in this thread detected by the RAT tool?
Would it be possible to automate this tool as part of our Hudson builds
so we find out about issues as soon as they are introduced?
Regards,
Oliver
>
>> 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
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by Tim Ellison <t....@gmail.com>.
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 <25...@mail.gmail.com>,
> sebb writes:
>> On 06/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
>>> In message <25...@mail.gmail.com>,
>>> sebb writes:
>>>> On 06/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
>>>>> Thanks Sebb.
>>>>>
>>>>> In message
>>>>> <25...@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
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
In message <25...@mail.gmail.com>,
sebb writes:
>
> On 06/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > In message <25...@mail.gmail.com>,
> > sebb writes:
> > >
> > > On 06/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
> > > >
> > > > Thanks Sebb.
> > > >
> > > > In message
> > > > <25...@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?
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.
I will *not* be making this decision one way or another until I get some
indication of the opinions of others who voted.
Regards,
Mark.
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by sebb <se...@gmail.com>.
On 06/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
>
> In message <25...@mail.gmail.com>,
>
> sebb writes:
> >
> > On 06/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
> > >
> > > Thanks Sebb.
> > >
> > > In message <25...@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.
> > >
> > >
> > > > 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
>
> > > > 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.
> 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.
>
> > https://issues.apache.org/jira/browse/HARMONY-6462
> >
> > > > 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.
> > > > 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.
>
>
> > > > 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?
>
>
> ?
>
> Regards,
>
> Mark.
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
In message <25...@mail.gmail.com>,
sebb writes:
>
> On 06/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > Thanks Sebb.
> >
> > In message <25...@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.
> >
> >
> > > 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?
> > > 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. 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.
> https://issues.apache.org/jira/browse/HARMONY-6462
>
> > > 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.
> > > 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?
I'll get to the rest when I get more time.
> > > 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?
?
Regards,
Mark.
> > > S///
> > >
> > > On 05/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
> > > >
> > > > +1 votes from Oliver, Ray, Charles, myself, Nathan, Jimmy and
> > > > Tim. No other votes, so the vote passes.
> > > >
> > > > Whoopie! I was beginning to think we'd never make a 6.0M1
> > > > release! ;-)
> > > >
> > > > Thanks for testing the artifacts and voting.
> > > >
> > > > All code bases are now open for commits again.
> > > >
> > > > I have uploaded binaries created from the signed sources to
> > > > the same location that was used for the vote. Please sanity
> > > > check these artifacts.
> > > >
> > > > I've been busy today so I probably wont rush to move the
> > > > 5.0M13 artifacts. I shall now plan to move both the 6.0M1 and
> > > > 5.0M13 files to the /dist/ tree on Sunday afternoon so that we
> > > > can make the release announcements on Monday.
> > > >
> > > > Regards,
> > > > Mark.
> > > >
> > > > In message <20...@d06av04.portsmouth.uk.ibm.com>,
> > > > "Mark Hindess" writes:
> > > > >
> > > > > I have created signed source archives for revision r917296
> > > > > of the java6 branch and made them available at:
> > > > >
> > > > > http://people.apache.org/~hindessm/milestones/6.0M1/
> > > > >
> > > > > Please test these artifacts and then vote for declaring
> > > > > these source archives as 6.0 Milestone 1.
> > > > >
> > > > > This vote will be open for at least three days, or until all
> > > > > binding votes have been cast (if earlier).
> > > > >
> > > > > If the vote is successful, binary builds from these
> > > > > artifacts will be made available on the download page.
> > > > >
> > > > > Regards,
> > > > > Mark.
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by sebb <se...@gmail.com>.
On 06/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
>
> Thanks Sebb.
>
> In message <25...@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.
>
>
> > 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:
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.
>
> > 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.
https://issues.apache.org/jira/browse/HARMONY-6462
> > 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.
>
>
> > 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.
>
>
> > 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
> >
> > working_vm/vm/tests/ncai/funcs/**
>
>
> 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.
>
> > 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.
> The NOTICE year is rather annoying though. What do other
> people think?
>
>
> -Mark
>
>
> > S///
> >
> > On 05/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
> > >
> > > +1 votes from Oliver, Ray, Charles, myself, Nathan, Jimmy and Tim. No
> > > other votes, so the vote passes.
> > >
> > > Whoopie! I was beginning to think we'd never make a 6.0M1 release! ;-)
> > >
> > > Thanks for testing the artifacts and voting.
> > >
> > > All code bases are now open for commits again.
> > >
> > > I have uploaded binaries created from the signed sources to the same
> > > location that was used for the vote. Please sanity check these
> > > artifacts.
> > >
> > > I've been busy today so I probably wont rush to move the 5.0M13
> > > artifacts. I shall now plan to move both the 6.0M1 and 5.0M13 files
> > > to the /dist/ tree on Sunday afternoon so that we can make the release
> > > announcements on Monday.
> > >
> > > Regards,
> > > Mark.
> > >
> > > In message <20...@d06av04.portsmouth.uk.ibm.com>,
> > > "Mark Hindess" writes:
> > > >
> > > > I have created signed source archives for revision r917296 of the
> > > > java6 branch and made them available at:
> > > >
> > > > http://people.apache.org/~hindessm/milestones/6.0M1/
> > > >
> > > > Please test these artifacts and then vote for declaring these source
> > > > archives as 6.0 Milestone 1.
> > > >
> > > > This vote will be open for at least three days, or until all binding
> > > > votes have been cast (if earlier).
> > > >
> > > > If the vote is successful, binary builds from these artifacts will be
> > > > made available on the download page.
> > > >
> > > > Regards,
> > > > Mark.
> > >
> > >
> > >
> >
>
>
>
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
Thanks Sebb.
In message <25...@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.
> 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.
> 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.
> 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.
> 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.
> 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
>
> working_vm/vm/tests/ncai/funcs/**
Will have to have a closer look at these but I suspect most are just
missing headers.
> 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. The NOTICE year is rather annoying though. What do other
people think?
-Mark
> S///
>
> On 05/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > +1 votes from Oliver, Ray, Charles, myself, Nathan, Jimmy and Tim. No
> > other votes, so the vote passes.
> >
> > Whoopie! I was beginning to think we'd never make a 6.0M1 release! ;-)
> >
> > Thanks for testing the artifacts and voting.
> >
> > All code bases are now open for commits again.
> >
> > I have uploaded binaries created from the signed sources to the same
> > location that was used for the vote. Please sanity check these
> > artifacts.
> >
> > I've been busy today so I probably wont rush to move the 5.0M13
> > artifacts. I shall now plan to move both the 6.0M1 and 5.0M13 files
> > to the /dist/ tree on Sunday afternoon so that we can make the release
> > announcements on Monday.
> >
> > Regards,
> > Mark.
> >
> > In message <20...@d06av04.portsmouth.uk.ibm.com>,
> > "Mark Hindess" writes:
> > >
> > > I have created signed source archives for revision r917296 of the
> > > java6 branch and made them available at:
> > >
> > > http://people.apache.org/~hindessm/milestones/6.0M1/
> > >
> > > Please test these artifacts and then vote for declaring these source
> > > archives as 6.0 Milestone 1.
> > >
> > > This vote will be open for at least three days, or until all binding
> > > votes have been cast (if earlier).
> > >
> > > If the vote is successful, binary builds from these artifacts will be
> > > made available on the download page.
> > >
> > > Regards,
> > > Mark.
> >
> >
> >
>
Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by sebb <se...@gmail.com>.
The NOTICE file is out of date:
Apache Harmony
Copyright 2006, 2009 The Apache Software Foundation.
There's a META-INF directory with N&L files in tools-src.jar but not
in tools.jar
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
There are a lot of source files that don't have AL headers, for example:
working_classlib/depends/libs/build/fetch-awt-depends.sh
working_classlib/doc/harmony.css
working_classlib/doc/hydoxygen.css
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
working_vm/vm/tests/ncai/funcs/**
Perhaps some of these are not ASF source, but it looks like many of them are.
S///
On 05/03/2010, Mark Hindess <ma...@googlemail.com> wrote:
>
> +1 votes from Oliver, Ray, Charles, myself, Nathan, Jimmy and Tim. No
> other votes, so the vote passes.
>
> Whoopie! I was beginning to think we'd never make a 6.0M1 release! ;-)
>
> Thanks for testing the artifacts and voting.
>
> All code bases are now open for commits again.
>
> I have uploaded binaries created from the signed sources to the same
> location that was used for the vote. Please sanity check these
> artifacts.
>
> I've been busy today so I probably wont rush to move the 5.0M13
> artifacts. I shall now plan to move both the 6.0M1 and 5.0M13 files
> to the /dist/ tree on Sunday afternoon so that we can make the release
> announcements on Monday.
>
> Regards,
> Mark.
>
> In message <20...@d06av04.portsmouth.uk.ibm.com>,
> "Mark Hindess" writes:
> >
> > I have created signed source archives for revision r917296 of the
> > java6 branch and made them available at:
> >
> > http://people.apache.org/~hindessm/milestones/6.0M1/
> >
> > Please test these artifacts and then vote for declaring these source
> > archives as 6.0 Milestone 1.
> >
> > This vote will be open for at least three days, or until all binding
> > votes have been cast (if earlier).
> >
> > If the vote is successful, binary builds from these artifacts will be
> > made available on the download page.
> >
> > Regards,
> > Mark.
>
>
>
[result] [vote] Declare r917296 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
+1 votes from Oliver, Ray, Charles, myself, Nathan, Jimmy and Tim. No
other votes, so the vote passes.
Whoopie! I was beginning to think we'd never make a 6.0M1 release! ;-)
Thanks for testing the artifacts and voting.
All code bases are now open for commits again.
I have uploaded binaries created from the signed sources to the same
location that was used for the vote. Please sanity check these
artifacts.
I've been busy today so I probably wont rush to move the 5.0M13
artifacts. I shall now plan to move both the 6.0M1 and 5.0M13 files
to the /dist/ tree on Sunday afternoon so that we can make the release
announcements on Monday.
Regards,
Mark.
In message <20...@d06av04.portsmouth.uk.ibm.com>,
"Mark Hindess" writes:
>
> I have created signed source archives for revision r917296 of the
> java6 branch and made them available at:
>
> http://people.apache.org/~hindessm/milestones/6.0M1/
>
> Please test these artifacts and then vote for declaring these source
> archives as 6.0 Milestone 1.
>
> This vote will be open for at least three days, or until all binding
> votes have been cast (if earlier).
>
> If the vote is successful, binary builds from these artifacts will be
> made available on the download page.
>
> Regards,
> Mark.
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
+1
Built and tested on linux x86/64 and x86. Debian packages built on
etch/x86 and etch/x86_64 and tested.
Tested with eclipse, our build and dacapo benchmarks.
Regards,
-Mark
In message <20...@d06av04.portsmouth.uk.ibm.com>,
"Mark Hindess" writes:
>
>
> I have created signed source archives for revision r917296 of the
> java6 branch and made them available at:
>
> http://people.apache.org/~hindessm/milestones/6.0M1/
>
> Please test these artifacts and then vote for declaring these source
> archives as 6.0 Milestone 1.
>
> This vote will be open for at least three days, or until all binding
> votes have been cast (if earlier).
>
> If the vote is successful, binary builds from these artifacts will be
> made available on the download page.
>
> Regards,
> Mark.
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4B...@gmail.com>, Tim Ellison writes:
>
> Please may I have a bit of time to test this? I expect to have my
> results by tomorrow and will decide based on that.
Sure. Let's extend the vote for 6.0M1 for a day.
Regards,
Mark.
> On 01/Mar/2010 18:50, Mark Hindess wrote:
> > I have created signed source archives for revision r917296 of the
> > java6 branch and made them available at:
> >
> > http://people.apache.org/~hindessm/milestones/6.0M1/
> >
> > Please test these artifacts and then vote for declaring these source
> > archives as 6.0 Milestone 1.
> >
> > This vote will be open for at least three days, or until all binding
> > votes have been cast (if earlier).
> >
> > If the vote is successful, binary builds from these artifacts will be
> > made available on the download page.
> >
> > Regards,
> > Mark.
> >
> >
> >
>
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by Tim Ellison <t....@gmail.com>.
Please may I have a bit of time to test this? I expect to have my
results by tomorrow and will decide based on that.
Thanks,
Tim
On 01/Mar/2010 18:50, Mark Hindess wrote:
> I have created signed source archives for revision r917296 of the
> java6 branch and made them available at:
>
> http://people.apache.org/~hindessm/milestones/6.0M1/
>
> Please test these artifacts and then vote for declaring these source
> archives as 6.0 Milestone 1.
>
> This vote will be open for at least three days, or until all binding
> votes have been cast (if earlier).
>
> If the vote is successful, binary builds from these artifacts will be
> made available on the download page.
>
> Regards,
> Mark.
>
>
>
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by Charles Lee <li...@gmail.com>.
+1
On Wed, Mar 3, 2010 at 5:20 PM, Ray Chen <cl...@gmail.com> wrote:
> +1
> I built and tested on Linux x86, see no unexpected failures.
>
> On Tue, Mar 2, 2010 at 2:50 AM, Mark Hindess
> <ma...@googlemail.com> wrote:
> >
> > I have created signed source archives for revision r917296 of the
> > java6 branch and made them available at:
> >
> > http://people.apache.org/~hindessm/milestones/6.0M1/
> >
> > Please test these artifacts and then vote for declaring these source
> > archives as 6.0 Milestone 1.
> >
> > This vote will be open for at least three days, or until all binding
> > votes have been cast (if earlier).
> >
> > If the vote is successful, binary builds from these artifacts will be
> > made available on the download page.
> >
> > Regards,
> > Mark.
> >
> >
> >
>
>
>
> --
> Regards,
>
> Ray Chen
>
--
Yours sincerely,
Charles Lee
Re: [vote] Declare r917296 as 6.0 Milestone 1
Posted by Ray Chen <cl...@gmail.com>.
+1
I built and tested on Linux x86, see no unexpected failures.
On Tue, Mar 2, 2010 at 2:50 AM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> I have created signed source archives for revision r917296 of the
> java6 branch and made them available at:
>
> http://people.apache.org/~hindessm/milestones/6.0M1/
>
> Please test these artifacts and then vote for declaring these source
> archives as 6.0 Milestone 1.
>
> This vote will be open for at least three days, or until all binding
> votes have been cast (if earlier).
>
> If the vote is successful, binary builds from these artifacts will be
> made available on the download page.
>
> Regards,
> Mark.
>
>
>
--
Regards,
Ray Chen