commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Commons Math (r)evolution
Date Fri, 10 Jun 2016 07:53:44 GMT
Hi.

On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:
> Hi Gilles,
>
> Gilles wrote:
>
> [snip]
>
>> _Some_ developer(s) should be able to support whatever is in
>> development.
>> Otherwise how can it be deemed "in development"?
>>
>> Just today, two issues were reported on JIRA:
>>    https://issues.apache.org/jira/browse/MATH-172
>>    https://issues.apache.org/jira/browse/MATH-1375
>>
>> They, unfortunately, illustrate my point.
>
> No, it does not.
>
> MATH-172 is about an enhancement. Unfortunately no-one can currently
> implement it, so we have to wait until someone can or the issue stays 
> simply
> unresolved again. You've requested for help and that was the proper 
> action.
> However, there has been no problem to release 3.0 in this state, so 
> why
> should it be a problem now for 4.0?

Because the context has changed: in 3.0 there was support, now there 
isn't.

> MATH-1735 is a bug report for a problem which is currently not 
> reproducible.
> Again you did the right action, but without more input and without a
> possibility to reproduce the problem, there's not much we can do. 
> Again, why
> should this issue prevent a release of 4.0?

The code in question should not have been in CM. [That was my position 
back
then (cf. archive).]

And every bug report for it is a reminder that unmaintainable code 
should
not be released.

>> Moreover what could be true for VFS is not for CM where there are 
>> many,
>> many different areas that have nothing in common (except perhaps 
>> some
>> ubiquitous very-low utilities which might be worth their own 
>> component
>> to serve as a, maybe "internal", dependency).
>>
>> Also, compare the source basic statistics (lines of code):
>>                VFS      CM
>> Java code    24215   90834
>> Unit tests    8926   95595
>>
>> All in all, CM is more than 5 times larger than VFS (not even 
>> counting
>> documentation).
>
> Any why is size suddenly a problem?

Not suddenly.
I've raised this issue for years.  Please look at the archives!

> [snip]
>
>>>> That's why I strongly favour cutting this monolith into pieces
>>>> with a limited scope.
>>>
>>> Nobody objects, but if you look at vfs, it is still *one* Apache
>>> Commons
>>> component, just with multiple artifacts. All these artifacts are
>>> released
>>> *together*.
>>
>> Sorry I'm lost, I looked there:
>>    http://commons.apache.org/proper/commons-vfs/download_vfs.cgi
>>
>> And, it seems that all the functionality is in a single JAR.
>> [Other files contain the sources, tests, examples.]
>
> Then look at commons-weaver.
>
>> Anyways, it is obvious that, in VFS, there is a well defined scope
>> (a unifying rationale).
>>
>> No such thing in CM.
>>
>> What I want to achieve is indeed to create a set of components that 
>> are
>> more like VFS!
>
> Fine. But talk about artifacts, not components. Apache Commons Math 
> is still
> *one* component of Apache Commons. It does not matter if you divide 
> the code
> into different artifacts as long as anything is released together.

I know.

What you can't seem to get to is that I consider it a bad idea to 
release
unsupported code.

I think that "I do not know (and nobody else does)" is not an 
acceptable
answer to user requests.
If we _know_ that some parts of the code would be unsupported (such 
that it
would elicit this kind of answer for bug reports), then it's 
_deceiving_ to
release that code.

> Individual release cycles for the different parts can only happen if 
> Math is
> TLP, but not in Apache Commons. We will certainly not allow and 
> create again
> any sub-umbrellas (search the Jakarta archives).

Who talked about sub-umbrellas?  I didn't.

I've explained that
  1. CM cannot be released as it was before
  2. for some parts, the necessary _minimal_ support has "disappeared"
  3. some parts can be turned into independent components (with _full_
     support)
  4. Some people are ready to perform the necessary steps in order to
     create these components

Please comment on how this contradicts Commons policy.

>> This is particularly obvious with the RNGs where there is one 
>> unifying
>> interface, a factory method and multiple implementations.
>> [Of course, in that case, the new component will be much simpler 
>> than
>> VFS (which is a "good thing", isn't it?).]
>>
>>> Turning math into a multi-project has nothing to do with your
>>> plans to drop mature code,
>>
>> I am not dropping anything (others did that); I am stating facts and 
>> I
>> now want to spend my time on something (hopefully) worth it.  
>> [Working
>> to modularize unsupported code is a (huge) waste of time.]
>>
>> Also, in the case of CM, "mature code" is meaningless as an overall
>> qualifier: some codes are
>>   * new (and never released, e.g. 64-bits-based RNGs)
>>   * algorithms introduced relatively recently (and perhaps never 
>> used)
>>   * old (and sometimes outdated and impossible to fix without 
>> breaking
>>     compatibility)
>>   * mostly functional (but impossible to maintain, cf. MATH-1375)
>>   * resulting from a refactoring (hence even when the functionality 
>> has
>>     existed for a long time, the code is not "mature")
>>
>> IMHO, maturity should be visible in the code.  It's an impression 
>> that
>> builds up by looking at the code as a whole, and coming to the
>> conclusion
>> that indeed there is some overall consistency across files and
>> packages.
>>
>> Within some CM packages: yes (even if "mature" would certainly not 
>> mean
>> free of sometimes serious problems).
>>
>> Across the whole library: certainly *not*.
>> [For reasons I could expand on.  But I did several times (cf. 
>> archives)
>> without succeeding in changing course.]
>>
>>> because you (and currently no-one else) cannot
>>> answer questions to its functionality.
>>
>> See the first post in this thread, in the part about gradually
>> re-adding
>> codes if and when they are supported by a new team.
>
> What you talk about is a complete new component without a proper 
> upgrade
> path for users of Math 3.x.

"Commons Math" is a dead end.  Is it that which you did not get?

There is "Commons" and there are "math codes" implementing various
functionalities, some in good shape, which I want to help release,
some in bad shape (for numerous reasons which you don't know about
and don't seem to want to hear about) which I'm not going to help
release as long as they are in that state.

> You wanna use the new stuff for complex numbers?
> Well, adjust your code to the new structures in 
> commons-math-complex-4.0.

No.  It should be "commons-complex-numbers-1.0" (or perhaps "0.1" if
that's allowed).

> Oh, you also want to use genetic algorithms?, Well, that part of the 
> code
> should stick with commons-math-3.0, because we did not took it over 
> for 4.0.
> Maybe for 4.1 ...
>
> Sorry, but for such a release I already propose my vote today: -1

So you prefer to sink whole work rather than be pragmatic about the
new reality.

How is that preferable to the user community?

> In that case I'd move Math really into the incubator.

Please do.

There are several options:
  1. Go on with a monolithic Commons Math
  2. Break the codebase into (maven) modules
  3. Create (in the long term) an all-encompassing TLP
  4. Create reusable components (right now)

  [Add others if appropriate.]

Which is more useful, in your opinion?
To which are you going to contribute (multiple choice allowed,
of course)?


Gilles

>
> Regards,
> Jörg
>

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


Mime
View raw message