On Mon, Jun 6, 2016 at 3:49 AM, Gilles <gil...@harfang.homelinux.org> wrote:
>
> 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).
>
Huh, it's above of 75% completion :)
> 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.
>
I can try to cover some of these and maintain relevant code parts.
>
> 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.
>
> What exactly missing to provide reasonable support, apart of
course of people who left?
> 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".
>
> 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")
>
>
I think that clustering part could be generalized to ML package as a
whole.
Best regrads,
Artem Barger.
