Apache Commons › Commons - Dev

[All] "Commons Math" is not a component

Classic

List

Threaded

6 messages Options

Gilles Sadowski

[All] "Commons Math" is not a component

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: [hidden email]
For additional commands, e-mail: [hidden email]

Martijn Verburg

Re: [All] "Commons Math" is not a component

This sounds like an approach analogous to the incubator modules in OpenJDK
itself.

Hopefully this will suit both worlds. Those who want the complete bundle
can do so, those who want discrete modules can do so.

Cheers,
Martijn

On 9 December 2017 at 01:59, Gilles <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

garydgregory

Re: [All] "Commons Math" is not a component

In reply to this post by Gilles Sadowski

I think I have some issues WRT "supported" and "unsupported" code that I
have mentioned on this list in the past but I do not want to stand in the
way of work getting done. So go for it. Our community will voice, hack and
vote I hope, with as much energy, diligence, and perseverance as you have
shown, which I admire and command you for greatly.

Gary

On Dec 8, 2017 18:59, "Gilles" <[hidden email]> wrote:

jodastephen

Re: [All] "Commons Math" is not a component

In reply to this post by Gilles Sadowski

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. This suggests that step 1 involves a full
release for [numbers]

Stephen

On 9 December 2017 at 01:59, Gilles <[hidden email]> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

garydgregory

Re: [All] "Commons Math" is not a component

On Dec 11, 2017 09:17, "Stephen Colebourne" <[hidden email]> 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. This suggests that step 1 involves a full
release for [numbers]

Right, get the plan in motion, one step at a time and let the community
iterate and opine.

Gary

Stephen

On 9 December 2017 at 01:59, Gilles <[hidden email]> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Gilles Sadowski

Re: [All] "Commons Math" is not a component

In reply to this post by jodastephen

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 <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]