commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [All] "Commons Math" is not a component
Date Fri, 22 Dec 2017 15:03:23 GMT
Hi.

[Sorry for not replying earlier; I've been quite diverted
by what happened around the RNG-37 issue[1].]

On Mon, 11 Dec 2017 16:16:34 +0000, Stephen Colebourne wrote:
> This all seems reasonable. One things I'd suggest is getting at least
> one new component to a full release as soon as possible to 
> demonstrate
> that the plan can work.

Except for the "beta" release, a demonstration of that plan has
already been performed, resulting in "Commons RNG"[2]: I extracted
codes from the "random" package of "Commons Math"[3][4], refactored
the API, made a modular project, added functionality and ported new
algorithms from standard implementations in C, increased coverage,
rationalized the test suite, ran benchmarks[5] and external tools[6]
to ensure that neither performance nor correctness was adversely
impacted by the overhaul.
[A beta release was not necessary because the client API was quite
simple and the functionality fairly "shallow" and "narrow" (and test
coverage was over 95%).]

Do you agree that the point was proven?

> This suggests that step 1 involves a full
> release for [numbers]

Whether to do a "beta" release is a general question on this list.
["Commons Text" had a beta release but I don't remember that it had
been useful, lacking beta-testers, IIRC.]
The ultimate goal is to not waste early the "pristine" (unnumbered)
top-level package name.

Anyways, IMHO, a code review of "Numbers" is quite necessary since
the modules were worked on by different people and not all the details
of the porting were specified.[7]

Regards,
Gilles

[1] https://issues.apache.org/jira/browse/RNG-37
[2] https://commons.apache.org/rng
[3] http://markmail.org/message/uiljlf63uucnfyy2
[4] http://markmail.org/message/422klwpqwclp4ru2
[5] 
https://commons.apache.org/proper/commons-rng/userguide/rng.html#a4._Performance
[6] 
https://commons.apache.org/proper/commons-rng/userguide/rng.html#a5._Quality
[7] There already are some identified issues that would impact the
     stability of the API, e.g.
       https://issues.apache.org/jira/browse/NUMBERS-40

> Stephen
>
>
> On 9 December 2017 at 01:59, Gilles <gilles@harfang.homelinux.org> 
> wrote:
>> Hi all.
>>
>> Stephen Colebourne correctly summarized the situation[1]:
>> Project management must be based on life-cycle, not the
>> other way around.
>>
>> Here below, a concrete plan is proposed in answer to the
>> suggestion (of a fork) made by Martijn Verburg[2].
>>
>> 1. Initial (beta?) release of "Commons Numbers".[3][4]
>> 2. Create separate git repositories for functionalities
>>    that have independent life-cycles and move the codes
>>    out of "Commons Math".
>> 3. Modularize "Commons Math" into
>>    a. A set of "supported" modules: functionalities having
>>       undergone a review in order to define a stable API.
>>    b. A set of "experimental"/"beta" modules: functionalities
>>       that have been modified since the last release (e.g.
>>       bug fixes[5]) but are expected to undergo API changes.
>>    c. A "legacy" module for heavily used functionalities known
>>       to harbour difficult design issues.
>> 4. Initial (beta?) release of codes in category (2) as new
>>    components.
>> 5. First non-beta release of "Commons Numbers".
>> 6. Release v4.0 of "Commons Math".
>> 7. First non-beta release of codes in category (2).
>> 8. Progressively move code from category (3c) to (3b) and
>>    from (3b) to (3a), or to (2). And RERO accordingly.
>>
>> Do you (PMC, committers, developers and users) foresee any
>> show-stoppers in the above sequence?
>>
>> Regards,
>> Gilles
>>
>> [1] http://markmail.org/message/w3imqvbf3wphvokj
>> [2] http://markmail.org/message/rribnh3tiikqtllf
>> [3] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git
>> [4] https://issues.apache.org/jira/projects/NUMBERS
>> [5] https://issues.apache.org/jira/projects/MATH


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


Mime
View raw message