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: [RESULT] [VOTE] Release Math 3.3 based on RC3 (second run after mail outage)
Date Tue, 27 May 2014 18:21:01 GMT
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 <luc@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 <luc@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-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
>>
>> ---------------------------------------------------------------------
>> 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