commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [Math] Commons Math (r)evolution
Date Fri, 10 Jun 2016 01:15:52 GMT
+1. (Or -1, depending on which way you want to look at it). 

Ralph

> On Jun 9, 2016, at 4:48 PM, Jörg Schaible <joerg.schaible@gmx.de> 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?
> 
> 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?
> 
>> 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?
> 
> [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. 
> 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).
> 
>> 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. You wanna use the new stuff for complex numbers? 
> Well, adjust your code to the new structures in commons-math-complex-4.0. 
> 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
> 
> In that case I'd move Math really into the incubator.
> 
> Regards,
> Jörg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 



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


Mime
View raw message