+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.schai...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
