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 > >
