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
