commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [VOTE] Release Commons Math 2.1 based on RC2
Date Fri, 26 Mar 2010 10:52:27 GMT
sebb wrote:
> On 26/03/2010, Phil Steitz <phil.steitz@gmail.com> wrote:
>> Tag:
>>  http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_1_RC2/
> 
> Some files were missing SVN:EOL (applied to trunk)
> 
Good catch.  Lets all make sure we have our svn clients configured
to add these
(http://www.apache.org/dev/version-control.html#https-svn-config)
> 1 missing AL header (applied to trunk).

Yikes!  Sorry I missed that.
> 
> Notice was still 2009 - fixed in trunk.
> 
Thanks for fixing this.

>>  Distributions:
>>  http://people.apache.org/~psteitz/math-2.1-RC2/
> 
> No SHA1 hashes, seems odd as the Mvn dist has them.
> (Not a blocker, can be added later)

We only link and mirror the md5s on dist/, so I see no reason to
include sha1 hashes for the official release tars/zips.
> 
> Builds and tests OK on 1.5 and 1.6; I got one failure in one of the
> runs of RandomDataTest but that is just my luck!
> 
>>  Maven artifacts:
>>  http://people.apache.org/~psteitz/math-2.1-RC2/maven/
> 
> However these do have both SHA1 and MD5 hashes.
> 
>>  Documentation bundled with the binary distribution:
>>  http://people.apache.org/~psteitz/math-2.1-RC2/docs/
> 
> Looks good.
> 
>>  Output of maven:site run against the source distribution:
>>  http://people.apache.org/~psteitz/math-2.1-RC2/site/
> 
> Not a blocker, but it's confusing to have the Javadocs for the
> previous releases near the top, and the Javadocs for 2.1 buried low
> down.
> 
> If possible, I would put the old docs under a separate heading much
> further down.

I don't care much about this.  If others agree, we can rearrange.
Users may be used to the current setup though and annoyed by the change.
> 
> Also, does it make sense to publish the RAT report?
> Surely that is mainly (only) needed for release checking?

I agree; but to get rid of it we have to open up the argument of
what reports belong in the commons-parent pom.  Personally, I would
get rid of all of them (precisely for this reason - you can't get
rid of anything included there); but I understand the other viewpoint.
> 
>>  Votes, please.  This vote will close in 72 hours, 0200 GMT 29-March 2010
>>
>>
>>  [ ] +1 Release these artifacts
>>  [ ] +0 OK, but...
>>  [ ] -0 OK, but really should fix...
> 
> -0 - missing AL header and Notice year.
> 
> Might also be an idea to remove the mantissa and experimental
> directory trees from the SVN tag, as they don't form part of the
> release?

Crap.  Forgot to do that.  Will omit from the RC3 tag.
> 
> Better yet, can we move them out of trunk, e.g. into a branch (or the
> bit bucket?)

Moving to branches would be a good idea, IMO.  What do others think?

Thanks for the review.

Phil
> 
>>  [ ] -1 I oppose this release because...
>>
>>  Thanks!
>>
>>  Phil
>>
>>  P.S.: I would appreciate it if an OSGi expert could review the
>>  generated material in the jar manifest and assure us that we will
>>  not get complaints on its suitability.
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>  For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message