On Mon, 6 Jun 2016 11:39:49 -0700, Ralph Goers wrote:
Although I am not involved in Math I find myself wondering if we
shouldn’t just step back and take a breath before rushing into
anything.
There isn't any rush, modularization (as many other things, like
e.g. to stop sticking to Java 5) has been in the pipe-line for
months (years maybe).
It may be that the approach being recommended is the correct
one, but it also may be that there are other people waiting in the
wings that we are unaware of.
How do you suggest that we reach out to them?
[In the most recent debates about the development (e.g. what Java
version to support for the next major release), nobody showed up on
the "dev" ML outside the usual suspects (the regular committers and
one or two other people who had been participating in the discussions
then, but don't seem to be interested anymore).]
Moreover, I am willing to personally experiment with the RNG classes
on which I've been working a lot since last December.
That code is completely new (never released), so nobody can possibly
come up to complain that it should have stayed inside Commons Math.
Gilles
Ralph
On Jun 6, 2016, at 10:57 AM, Benedikt Ritter <brit...@apache.org>
wrote:
Hello Gilles,
I think ApacheCon Europe would be a good opportunity to spread the
word
about this.
Benedikt
Gilles <gil...@harfang.homelinux.org> schrieb am Mo., 6. Juni 2016
um
02:49 Uhr:
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
