Hi Martijn.
On Tue, 5 Dec 2017 23:45:43 +0000, Martijn Verburg wrote:
Can this project be forked to a new domain over on GitHub (under the
existing Apache license),
It is allowed, of course. However, I think that it is the
last option to consider, because it will further dilute the
community that has an interest in the "Commons Math" codebase.
For developers and for users, there are practical advantages
in keeping the spin-off projects within "Commons".
It is even a more appropriate place than a TLP!
[In this evaluation, I of course do not account for the
negative stance of part of the PMC.]
split up and then continued in that case?
The work had started.
Did you have a look at "Commons RNG"[1] and "Commons Numbers"[2]?
Both were spun off the development version of "Commons Math"[3].
IMO, current priority is to have an initial (beta?) release of
"Commons Numbers". There is a list of issues in the bug-tracking
system:
https://issues.apache.org/jira/projects/NUMBERS
An important test must pass (before a release can make sense):
All the code that was "moved" (to "Numbers") must be removed
from "Math", and functionalities of the latter must be adapted
to depend on "Numbers".
Afterwards, a probably easy task would be to create another
generally useful component out of the "o.a.c.math4.geometry"
package (no other part of CM depends on it and it has almost
no dependencies on any other CM class).
Another easy move would be the code in package "o.a.c.math4.ml"
(zero cross-dependencies). [Although developer and user of that
package, I admit that the functionality might currently be too
limited to warrant a component.]
Less easy (but quite useful) would be a component based on a
selection of the functionalities in package "o.a.c.math4.analysis"
(root solver, interpolation, integration).
The rest of CM is either too advanced or with cross-dependencies
not easy to untangle and/or too many issues to solve, in order
to create good components, given the scarce human resources...
Next, we can tackle tasks on CM itself:
- make modules for functionality that is free of issues and
supported, and
- make a "legacy" module for everything else.
Then, we head toward a long-overdue release.
Opinions on the plan is appreciated, and help to make progress
(forward!) is most welcome.
Regards,
Gilles
[1] https://git1-us-west.apache.org/repos/asf?p=commons-rng.git
[2] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git
[3] https://git1-us-west.apache.org/repos/asf?p=commons-math.git
Cheers,
Martijn
On 3 December 2017 at 11:51, Gilles <gil...@harfang.homelinux.org>
wrote:
On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
On Fri, Dec 1, 2017 at 2:26 PM, Gilles
<gil...@harfang.homelinux.org>
wrote:
There hasn't been any progress towards a decision.
There isn't even a consensus on one of the central tenets of
Apache ("Those who do the work..."): how sad/strange (?).
Those who do the work are welcome to decide on their own, if they
do
not involve others.
The conditional is not part of the well-known mantra.
The issue here is to answer the question of what to do with
a non-trivial code base. My stance is to try and fix the
problem(s), a.o. difficult management, by rooting out its
main cause: CM has become an aggregate of components with
completely different subject matters, scopes, designs,
efficiencies, provisions for extension, etc.
[An array of issues which "maven" modules will not solve.]
We are seemingly faced with a choice between:
1. Maintain CM as the huge library that it is now.
2. Incrementally create maintainable components.
A long time has passed since these alternatives were first
exposed, only proving that none of the people who informally
chose option(1) invested work to make it a reality.
Refusing option (2) not only "involves others"; it is harming
them (very real people, having done a lot of work here, on
that code base).
Establishing a new commons component doesn't
qualify, IMO.
True; that's why we are stalled, despite that a majority
of the PMC did not explicitly oppose option (2).
A handful of PMC people prefer to let the code base become
"dormant" rather than give any chance to an alternate view.
[If, say, you looked at the "Commons RNG" project, and
concluded that, decidedly, this is not how a component
should look like, then I could perhaps fathom out where
those reservations come from.]
Gilles
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
