harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [result] [vote] Declare r917296 as 6.0 Milestone 1
Date Tue, 09 Mar 2010 14:53:01 GMT

In message <4B965812.2030105@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:


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.


View raw message