Exactly! On Thu, Jun 9, 2016 at 10:54 PM Ralph Goers <ralph.go...@dslextreme.com> wrote:
> Given how few Math committees there are, that would require going into the > incubator. > > Ralph > > > On Jun 9, 2016, at 6:24 PM, James Carman <ja...@carmanconsulting.com> > wrote: > > > > TLP TLP TLP! > > > > You can split it up into whatever you want. > > > >> On Sun, Jun 5, 2016 at 8:49 PM Gilles <gil...@harfang.homelinux.org> > wrote: > >> > >> Hello. > >> > >> Commons Math as it was in the last official release (v3.6.1) and > >> consequently as it is in the current development branch has > >> become unmaintainable. > >> > >> This conclusion is unavoidable when looking at the following: > >> 1. codebase statistics (as of today): > >> * src/main/java 90834 lines of Java code (882 files) > >> * src/test/java 95595 lines of Java code (552 files) > >> * src/userguide/java 3493 lines of Java code (19 files) > >> 2. number of posts on the "dev" ML (related to [Math]) in the > >> last 2 months: > >> * Gilles 74 > >> * Artem Barger 20 > >> * sebb 15 > >> * Rob Tompkins 9 > >> * Eric Barnhill 7 > >> * 19 other people 46 > >> 3. development/maintenance activity in the last 4 months: > >> * commits by Gilles 133 > >> * commits by others 12 > >> > >> According to JIRA, among 180 issues currently targeted for the > >> next major release (v4.0), 139 have been resolved (75 of which > >> were not in v3.6.1). > >> > >> So, on the one hand, a lot of work has been done already, but > >> on the other, a lot remains. > >> Some issues have been pending for several years, in particular > >> those that required a major refactoring (e.g. in the packages > >> "o.a.c.m.linear" and "o.a.c.m.optim"). > >> > >> The remaining work is unlikely to be completed soon since the > >> fork of Commons Math has drastically reduced the development > >> capacity. > >> > >> Moreover, as whole areas of the codebase have become in effect > >> unsupported, it would be deceiving to release a version 4.0 of > >> Commons Math that would include all of it. > >> > >> Of course, anyone who wishes to maintain some of these codes > >> (answer user questions, fix bugs, create enhancements, etc.) > >> is most welcome to step forward. > >> > >> But I'm not optimistic that the necessary level of support can > >> be achieved in the near future for all the codebase. > >> Waiting for that to happen would entail that code that could > >> be in a releasable state soon will be on hold for an indefinite > >> time. > >> > >> The purpose of this post is to initiate a discussion about > >> splitting Commons Math, along the following lines: > >> 1. Identify independent functionality that can be maintained > >> even by a small (even a 1-person) team within Commons and > >> make it a new component. > >> 2. Identify functionality that cannot be maintained anymore > >> inside Commons and try to reach out to users of this > >> functionality, asking whether they would be willing to > >> give a helping hand. > >> If there is sufficient interest, and a new development > >> team can form, that code would then be transferred to the > >> Apache "incubator". > >> > >> There are numerous advantages to having separate components > >> rather than a monolithic library: > >> * Limited and well-defined scope > >> * Immediate visibility of purpose > >> * Lower barrier to entry > >> * Independent development policy > >> * Homogeneous codebase > >> * Independent release schedule > >> * Foster a new community around the component > >> > >> According to the most recent development activity, the likely > >> candidates for becoming a new component are: > >> * Pseudo-random numbers generators (package "o.a.c.m.rng") > >> * Complex numbers (package "o.a.c.m.complex") > >> * Clustering algorithms (package "o.a.c.m.ml.clustering") > >> > >> Other potential candidates: > >> * "FastMath" (which should be renamed to something like > >> "AccurateMath", cf. reports about slowness of some of > >> the functions) > >> * Special functions (package "o.a.c.m.special") > >> * Selected "utilities" (package "o.a.c.m.util") > >> > >> > >> Best regards, > >> Gilles > >> > >> > >> --------------------------------------------------------------------- > >> 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 > >
