On Mon, 21 Aug 2017 10:52:28 -0700, Ralph Goers wrote:
On Aug 21, 2017, at 4:39 AM, Gilles <gil...@harfang.homelinux.org> wrote:

On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:
Am 20.08.2017 um 23:11 schrieb Ralph Goers <ralph.go...@dslextreme.com>:

I have to agree with Jochen and am -1 to this proposal. I have stated before that I don’t want to see Commons become the placeholder for all the Math related components. If Math has stuff that can’t be maintained then create a MathLegacy project in the sandbox and move the stuff there.

I’ve also already argued in that direction.

I gave technical arguments in favour of the proposal (cf. first
post in this thread).

People opposing it give none.
A sudden "allergy" of some PMC members to "math"-related code
does not warrant rejecting non-obsolete code.[1]

A good start would be to answer this question: Why is it bad (or
worse than the current situation) to have this "new" component?

Technical arguments are not required since this is basically a
housekeeping issue.

It is not, unless you consider that doing some ground work for
an (Apache) community to grow around an objectively useful piece
of code is not worth trying.

I’m not sure why I would answer your last question since you are
clearly going to have a different opinion.

My opinion is based on technical arguments; so why shouldn't
yours too?
Maybe those arguments can then convince me that I should let
it down (and that over 10 years of volunteering work here were
basically a waste of time).

But many of us believe that
Math is a great name for a project that contains math subcomponents,
rather than wading through a bunch of different Commons projects.

I've already answered to this argument. Here is some of the
reasoning:
1. "Math" is not a well-defined project name.  It is much,
   much, much, too broad.  It was the source of endless
   managements problems for "Commons Math", on to the fork
   itself.
2. "Commons Math" contains such loosely related things that
   grouping them hardly makes more sense than declaring that
   all "Commons" components should be modules of a unique
   maven project.
3. It is very unlikely that such a diversity of codes can be
   maintained by people who are able or willing to maintain
   all of it.
4. This has led to swaths of codes being developed without
   any review whatsoever.  Confidence in them solely resided
   in the expertise of its developer (no plural intended).
5. The sole consensus on global development that could be
   reached was on including more and more code that would
   become unmaintainable once the developer responsible for
   would leave (as _proven_ by the facts, since the fork).

And on, and on...

Eventually you are going to want Commons Statistics, Commons
Transforms, Commons Primes, etc. or things that are even more
specific.

No. *I* do not want it.
The only thing I want is to release _good_ components.
"Commons Math" has good code in it, but is a bad "component".
[I've tried to show with "Commons RNG" what (I think) is a
good component: narrow focus, modular, simple API and usage.]

Other programming languages eco-systems successfully follow
an approach based on (really) small components; why would you
want "Commons Math" to remain this monolithic beast?

All of these should be modules under Math. To be honest, I’m
really not clear why Commons Numbers was approved as I’ve never heard
anyone talk about complex numbers or fractions in anything but a
mathematical concept.

Again, arguing that all things pertaining to "a mathematical
concept" should belong to a single library is no more sensible
than, for example, assuming that all logging frameworks should
all be modules of a unique library...

I get that what you are really trying to do is kill Commons Math off
piece by piece. I just don’t agree with doing that.

The "Commons Math" component was killed off by those who
decided to fork it. Period.

Long before that, I had indicated that some change was
desirable (IMHO); but the course was set by the majority
of regular contributors, who were able to maintain the
various pieces. That was fair.
But, since the fork, who belongs to that category?
Why do you want to pretend that a healthy "Commons Math"
component exists, when big parts of it are not maintained
and that no slight refactoring is needed to fix some of
the reported issues?
Did I understand correctly that moving the whole of "Commons
Math" to "dormant" is your most generous offer to those of
us who try to find a way forward for some of the most useful
code that it contains?

Gilles


Ralph





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

Reply via email to