On Mon, 19 Sep 2016 07:03:44 -0400, Rob Tompkins wrote:
On Sep 18, 2016, at 7:22 AM, Gilles <gil...@harfang.homelinux.org> wrote:


On Sat, 17 Sep 2016 16:07:41 +0200, Jörg Schaible wrote:
Hi Rob,

Rob Tompkins wrote:


Given that the long term goals of commons-math are fairly uncertain, I would like to attempt working with some short term goals. The hope here is to think about questions along the lines of: "what can be done today/this week/this month,” with the goal aiming at chipping away at what I’ll call, for lack of a better term, technical debt. I have a couple of thoughts and am curious to see what folks generally think here. Here are some ideas
that immediately come to mind:

Items achievable in a few hours:
Move to the develop branch to the master branch.
Get travis-ci/coveralls working for pull requests.

Given the lack of comments here, that feels like a "go for it.” But,
I am curious what the code in “master” represents? I ask because it
seems that it’s drifted considerably from the release of 3.6.1.

If I do go down this road, I probably would keep the current master
branch around for a while labeled as “master-old-<dateOfChange>” (or
something along those lines).

Items achievable in a few days:
Deprecation of the packages that duplicate functionality with commons-rng.

+1 ... normally. However, IIRC correctly, Gilles once said that all the RNG
stuff was never part of a release.

The package
was created in the development branch (released CM code was from
the "MATH_3_X" branch) intended for work towards v4.0 (which
started in early 2015, by removing long deprecated codes).

It was a complete rewrite (with fixes, extensions, additions, and
removals) of code from
which has existed for a long time, and was named
in branch MATH_3_X

IIUC, Rob means to deprecate, in branch "MATH_3_X", codes in
that could be replaced by equivalent functionality defined
in Commons RNG.

A minor release of CM3 would warn users about the changes to
If they use the functionality from
in their own codes, they will already be able to upgrade
(to Commons RNG).
But if they use CM3 generators as arguments in calls to CM3,
then no replacements will be available, as only (unreleased)
CM4 can be (and has been) upgraded to depend on Commons RNG.

This would precisely be the idea. If we are intent on modularization,
then we should slim down the commons-math library such that it
contains no duplications from other commons components.

I'm not sure that everyone say the same thing.
Slimming down of CM4 has been done.
Functionality can be deprecated in CM3, but replacing it in the same
way as in CM4 cannot be performed completely (some of it is breaking)
and it is a huge waste of time (better spent IMO at resolving the
backlog in CM4, and striding towards modularization, of course).

Lastly given those ideas, does anyone else have any ideas for what we
can do right now on commons-math?

"Commons RNG-Utils" (cf. other post).




P.S. Your +1 vote was a pleasant surprise; thanks!

In that case this code can be simply

Obvious bug fixes.

Items achievable in a month(s) or so.
A release 3.6.2 with the deprecation of the overlap with commons-rng. Some solidifying of the more base level functionality such that we might
be able to rely upon commons-math as the core of the mathematical
functionality for commons generally (if we do indeed intend to have
modularized mathematical commons functionality).

All that said, these are just thoughts, and I’m completely open ended on direction here but want to avoid letting the project sit latent for too long. I was just thinking that with so much uncertainty for the project, it might be better to just be intentionally short sighted with the hopes of gaining some momentum and let natural evolution begin to take place.
What do you guys think?

Fine. Thanks for taking responsibility.


To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to