On Tue, 5 Sep 2017 14:33:55 +0200, Emmanuel Bourg wrote:
Le 4/09/2017 à 15:30, Gilles a écrit :
I see it as a fundamental one: Why should codes unrelated
by scope be artificially tied together by management rules
(such as design, supported language version, release schedule,
etc.)?[1]
Because they share the same general scope of being math related.
This is what CM was about, and it did not work out well.
Been there, done that.
The
design and the supported language version can be different for each
module.
Which project would start on the premises of a non-uniform
design among its modules?
It makes sense if the projects are different and can be
supported by different teams (even if there can be overlaps
of course).
Why do you "prefer" multi-module, independently of the subject
matters being talked about?
I already explained twice in this thread.
You did not because you left out the _why_ you don't agree
that "Mathematics" is too broad a scope for a programming
project.
At least a project which we could handle here at "Commons"
(being a home for small, focused, components).
CM was proven not to be a viable component for "Commons" in
several ways: some decided to leave "Commons", some proposed
to adapt our expectations to match the "Commons" eco-system
(code-wise and community-wise, as I've explained in more than
one way).
A few others still insist that what led to much disappointment
should be pursued.
Same cause, same consequences.
Please comment on my suggestion to create a single maven project
for the whole of "Commons". I'd agree that this suggestion is
ridiculous; yet some of you do the same proposal for "everything
math-related".
If you want to use an absurd proposal to prove your point let me try
that game too: Please comment on my suggestion to create multiple
components out of every Java package defined in the Commons
components.
You, not me, are advocating for an absurd proposal whose
logical consequence would allow including the whole of
mathematics in a single maven project.
I start from the subject matter in order to define scope.
This has nothing to do with what you are presenting here
(which is indeed absurd too).
If you had been contributing to the math codes (plural), you
perhaps would have understood that it creates more management
problems than it solves.[4]
Please use foot references for external links only, your messages are
unreadable if we have to go back and forth to understand them.
Again, I have to stress on what happened that led me to propose
a new "Commons RNG": obvious improvements to the CM code base
were outrightly rejected based on demonstrably false statements;
i.e. the objections were not technical but for the convenience
of one user.
I still think that splitting RNG into its own component was a good
move.
I'm less happy with Numbers, I'd have preferred a module from a
renovated "CM5" project started from scratch as I'm suggesting now
for
Geometry.
Good for "RNG", bad for "Numbers"... Where is the logic?
Even so, how long did it take the PMC to see that "Commons
RNG" was a good move?
If "Commons RNG" was a good move, you could have the minimal
trust that maybe, just maybe, I might be right with a quite
limited set of similar suggestions resulted from an identical
reasoning.
Do you think that I enjoy contradicting you on these matters?
I'm starting to think that you enjoy rhetoric,
I'm not. But you seem on to try and blur my true position, with
undertones that I'd be more "talking" than "doing".
All evidences are there: the ML archives, the bugs, the fork,
the new components (released and in-progress).
But you look only at a couple of "mechanical" advantages of
having N-1 components rather than N.
probably more than
seeking compromise unfortunately.
And this accusation, yet again. :-/
Surely you do not have a clear memory of more than 10 years of
day-to-day CM development; I did compromise on very wrong (IMO)
decisions.
And I have taken more than my share implementing some of those
wrong decisions, trusting that the others would do their part.
Did you notice the result?
Errare humanum est, perseverare diabolicum.
Do they want to implement another plan? What plan?
Here is my counter-proposal:
1. Refactor Commons Math as a multi-module project, bump to version 5
2. Create two modules: geometry and legacy
3. Release Commons Math 5, without the legacy module
4. Spin-off new modules from the legacy module when needed
And I'm willing to help at least for the steps 1 and 2.
I'm not sure I understand your intended level of implication.
[Changing the directory structure of the repository is the
trivial part of the process. Stopping there is like shoving
dust under carpet to pretend that the floor is clean.]
I propose that "Commons Numbers" and "Commons Geometry" be
components (with their own set of modules); and, from the
rest of CM code, we'd have
1. easy "module" candidates like:
o.a.c.m.distribution (unidimensional)
o.a.c.m.ml
o.a.c.m.genetic
2. less easy ones (cyclic dependencies or dependencies on
"legacy", non-trivial issues, lack of support), such as
parts of
o.a.c.m.analysis
o.a.c.m.analysis.integration
o.a.c.m.distribution (multidimensional)
o.a.c.m.fitting
o.a.c.m.optim
o.a.c.m.ode
o.a.c.m.filter
3. "legacy" (refactoring issues, lack of support) for
o.a.c.m.linear
o.a.c.m.stat
Some of the modules should in principle be separate components
too, but this depends on the developers who had volunteered
to populate them...
Let's hear from people who actually intend to work. What
are they willing to do for the result which they would like
to see?
Personally, as I've said recently, I'm not willing to be the
one supposed to handle tasks "3." and "4." for the years to
come. Been there, done that.
Gilles
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
