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] |
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] > > |
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: > 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] > > |
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: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
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: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
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] |
Free forum by Nabble | Edit this page |