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 03:00:10 GMT
Exactly!
On Thu, Jun 9, 2016 at 10:54 PM Ralph Goers <ralph.goers@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 <james@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 <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
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> 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