commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [Math] Commons Math (r)evolution
Date Fri, 10 Jun 2016 01:24:18 GMT
TLP TLP TLP!

You can split it up into whatever you want.

On Sun, Jun 5, 2016 at 8:49 PM Gilles <gilles@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message