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
