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