On 5/27/14, 11:14 AM, Benedikt Ritter wrote: > > Send from my mobile device > >> Am 16.05.2014 um 18:45 schrieb Luc Maisonobe <l...@spaceroots.org>: >> >> Hi Benedikt, >> >> Le 16/05/2014 09:09, Benedikt Ritter a écrit : >>> Hi Luc >>> >>> >>> 2014-05-15 0:17 GMT+02:00 Luc Maisonobe <l...@spaceroots.org>: >>> >>>> Le 14/05/2014 20:18, Luc Maisonobe a écrit : >>>>> Le 11/05/2014 11:55, Luc Maisonobe a écrit : >>>>>> Hi all, >>>>>> >>>>>> As I am not sure this message will be recovered after mail outage, I >>>>>> send it again, with an update of final date. >>>>>> >>>>>> I would like to call a vote to release Commons Math 3.3 based on RC3. >>>>> >>>>> This vote has passed with the following tally: >>>>> >>>>> - Luc +1 >>>>> - Gary -0 >>>>> - Phil +1 >>>>> - Thomas +1 >>>>> - Gilles +1 >>>>> >>>>> I will publish what I can (I guess promoting the maven artifacts has to >>>>> be done by Thomas) and send the announcement. >>>> For your information, I have published everything except site and maven >>>> artifacts. >>>> >>>> Concerning the site, it is a nightmare to publish. We have a huge set of >>>> files due to javadoc, plus testapidoc (I really don't know what this is >>>> for), plus coverage, plus source xref, plus test source xref ... There >>>> are more than 20000 files in the site and it is more than 470M. >>>> >>>> After two hours and an half, the big commit simply failed with a proxy >>>> error (and I am not behind a proxy here, so I don't know were it is). >>>> I understand the rationale behind svnpubsub (security, no shell access >>>> on the server, auditing, logs ...), but it clearly does not scale when >>>> tools regenerate huge amounts of files that are all changed at once and >>>> are all sent in one big commit. I feel this method is an abuse of svn, >>>> its not designed for this kind of transfers. >>>> >>>> I give up for tonight. >>> you can checkout the location of the site from >>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/, >>> build the site locally and move it to the checkout. this way you can make >>> smaller commits by just committing sub directories. It is tedious, but >>> maybe it works better this way? >> This is what I finally did yesterday. It took several hours to complete ... >> >> I really think something we are doing something wrong here. The source >> is a single archive less than 5 Mb large. From this, various maven >> plugins (javadoc, source xref, jacoco ...) produce tens of thousands of >> files and create a folder hierarchy about 470Mb large. So basically I >> donwload 5Mb, expand it to 470Mb, and write them back to the other side >> of the atlantic and I do it using an extremelly slow protocol : svn. I >> do have a broadband connection, but during the transfer it was almost >> idle as svn transfered at only about 40kbps, despite the line could >> support much higher bandwidth. >> >> I had the feeling I was filling a swimming pool with a teaspoon ... >> >> I am sure there can be something better to upload huge amounts of data, >> even if at the end svn is used to store everything. Having svn between >> the staging area and the production server is perhaps a good idea, I >> don't know. However, using svn for 20000 files/470Mb that are >> automatically generated from a small 5Mb source from the other side of >> the Earth is really cumbersome. > Hi, > > maybe we should talk to infra about this? Maybe they can provide a service > where one can upload an archive containing the site, that gets extracted and > committed to svn?
I kind of like (and have used) your idea of just checking the whole mess out from svn, making local mods and checking back in. works4me. Phil > > Bene > >> best regards, >> Luc >> >>> HTH >>> Benedikt >>> >>> >>>> Luc >>>> >>>>> Thanks to everyone >>>>> Luc >>>>> >>>>>> Changes since RC2: >>>>>> >>>>>> * reverted javadoc fixes for Java 8 >>>>>> >>>>>> Note: >>>>>> >>>>>> Commons Math 3.3 does compile with Java 8, but creating the site will >>>>>> not work due to some incompatibilities: >>>>>> >>>>>> * javadoc: known doclint issue >>>>>> * findbugs: not ready for java 8 >>>>>> >>>>>> >>>>>> Math 3.3 RC3 is available for review here: >>>>>> https://dist.apache.org/repos/dist/dev/commons/math/ >>>>>> (svn revision 5295) >>>>>> >>>>>> Maven artifacts are here: >>>> https://repository.apache.org/content/repositories/orgapachecommons-1027/org/apache/commons/commons-math3/3.3/ >>>>>> Details of changes since 3.2 are in the release notes: >>>> https://dist.apache.org/repos/dist/dev/commons/math/RELEASE-NOTES.txt >>>> http://people.apache.org/builds/commons/math/3.3/RC3/changes-report.html >>>>>> The tag is here: >>>> https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_3_RC3 >>>>>> (svn revision 1593137) >>>>>> >>>>>> Site: >>>>>> http://people.apache.org/builds/commons/math/3.3/RC3/ >>>>>> (note the apidocs for the 3.3 release will be added with the release) >>>>>> >>>>>> Clirr Report (compared to 3.2): >>>> http://people.apache.org/builds/commons/math/3.3/RC3/clirr-report.html >>>>>> (note that there are 4 false positives where the signature of a >>>>>> method has changed such that the parameter type is now the superclass of >>>>>> the previous type) >>>>>> >>>>>> RAT Report: >>>> http://people.apache.org/builds/commons/math/3.3/RC3/rat-report.html >>>>>> Findbugs Report: >>>>>> http://people.apache.org/builds/commons/math/3.3/RC3/findbugs.html >>>>>> >>>>>> KEYS: >>>>>> http://www.apache.org/dist/commons/KEYS >>>>>> >>>>>> Please review the release candidate and vote. >>>>>> >>>>>> Note that the artifacts have been prepared by Thomas (thanks to him!) >>>>>> and he delegated the vote to me. So the signatures correspond to his key >>>>>> and not mine. >>>>>> >>>>>> This vote will close no sooner that 72 hours from now, that is >>>>>> 2014-05-14T10:00:00Z (this is UTC time). >>>>>> >>>>>> [ ] +1 Release these artifacts >>>>>> [ ] +0 OK, but... >>>>>> [ ] -0 OK, but really should fix... >>>>>> [ ] -1 I oppose this release because... >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >> > --------------------------------------------------------------------- > 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
