On 26/03/2010, Phil Steitz <phil.ste...@gmail.com> wrote: > sebb wrote: > > On 26/03/2010, Phil Steitz <phil.ste...@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.
In which case I suggest at least adding the current Javadocs at the head of the list (and perhaps drop the oldest). > > > > 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-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org