Hi Patrick, and others.
On Fri, 10 Jun 2016 07:37:00 -0400, Patrick Meyer wrote:
I think it would be better to spend the time trying to recruit new
contributors than it would be to alienate existing ones.
By what are you alienated?
[This is addressed to all readers and would-be contributors to
the Commons project.]
Are there, among the readers, people who'd step forward to take
all the CM codebase, and start the process towards a TLP?
Are there people, among the CM contributors (or willing to
contribute) opposed to having the "Random Number Generator"
functionality being split off of the CM codebase.
Are there people opposed to the same concerning the functionality
based around the complex numbers?
Are there people opposed to the refactoring of the "o.a.c.m.ml"
package (which is likely to break all applications currently
using it)?
Also, the
effort required to divide the library into smaller parts
In some cases, the effort is worth it.
In the first case I want to submit (RNG), the effort was done already;
and for that reason also (in addition to the objective bonuses), I want
to see this code released sooner than later (or never).
would be
better spent creating patches.
Patches welcome. ;-)
Does anyone have ideas for actively recruiting contributors?
Contributors will (maybe) come to a project they like; as noted
by others, they (certainly) won't come where there is no fun.
Then some people come and ask: "What is the roadmap?". There was
none. It was impossible because of the unlimited scope, the
lack of resources, the wildly different priorities, etc.
Do you
know of mathematics departments that also teach students Java
programming? A recruiting campaign with the message like "here's what
we do at CM, we'd like your help" could attract new contributors.
What do we do?
Let's see the actual message.
I am well placed to remind that CM as it was "practiced" did not
attract many people. [At a talk (FOSDEM), four years ago, one of the
questions was about the Java version; we were well into the Java 7
era; a telling silence followed Thomas Neidhart's answer that the
"consensus" was to stick to... Java 5. From an audience of more than
60 people, zero contributor.]
It
will take time, but a constructive approach like this one will do
more
to sustain CM.
This is something to explore. Are you going to do it?
How are you so sure that "it will do more" that what I propose,
which is in fact quite constructive.
I understand that you may be angry by this long chain of mails.
But please do not shoot at the bearer of bad news.
Regards,
Gilles
Thanks,
Patrick
-----Original Message-----
From: Jörg Schaible [mailto:joerg.schai...@bpm-inspire.com]
Sent: Friday, June 10, 2016 6:20 AM
To: dev@commons.apache.org
Subject: Re: [Math] Commons Math (r)evolution
Hi Gilles,
Gilles wrote:
Hi.
On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:
[snip]
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.
That does not state the fact, that the code is already released and
it does not matter at all if users ask questions for release 3.0 or
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?
The code in question should not have been in CM. [That was my
position
back
then (cf. archive).]
Again, you cannot change history, it is already released. And a new
release
of the code does not make the situation worse.
And every bug report for it is a reminder that unmaintainable code
should
not be released.
That is your interpretation. For me it is a normal bug report and we
can
eigher solve it on our own or have to wait for a contribution.
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!
Then: Why is size a problem? It is only a problem if *you* try to
support
all of it at once. Nobody expects that.
[snip]
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.
You've stated that multiple times now.
I think that "I do not know (and nobody else does)" is not an
acceptable
answer to user requests.
See, this is the difference. To me this *is* acceptible. Especially
if users
have to be kind of experts themselves to use this code.
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.
A new release does not change the situation at all. With such a
definition
we could move quite some of our components directly to the attic,
because
the original authors are no longer around and we might currently have
no
expert around.
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 talk about it, because it is what the result looks to me.
I've explained that
1. CM cannot be released as it was before
You've expressed that *you* don't want to release it as it was before
(well-
founded however).
2. for some parts, the necessary _minimal_ support has
"disappeared"
That does not immediately invalidate the existing code. One fact that
you
don't want to see.
3. some parts can be turned into independent components (with
_full_
support)
Have we some kind of agreement here to introduce new Commons
components? As
far as I know, we just did not oppose to break Math into individual
artifacts.
4. Some people are ready to perform the necessary steps in order
to
create these components
The work on the code is still independent of a monolithic Math
component vs.
inidividual (let's say) Maven projects. The refactoring is the same
if you
simply want to minimize the dependencies between the Java packages in
Math.
Please comment on how this contradicts Commons policy.
The ASF in general does not like umbrella TLPs at all. Apache Commons
actually has been near this category all the times. We try to manage
a
(large) set of general purpose libraries with the intent to provide
long
time compatibility (sometimes possibly exaggerated) or provide clear
upgrade
paths if a redesign was necessary. We do this, because we are aware
that our
components are nearly always part of large software stacks and we may
impact
a lot of stuff if we fail.
However every of our components has a general purpose. Math is
described as
"Lightweight, self-contained mathematics and statistics components".
The
component in its completeness is certainly no longer lightwight.
What you propose now, is to move Math in its current state into
dormant (or
even attic, because it will then never be revived in its current
state) and
create several (how many?) new Commons components, all of them
focussed to a
special mathematical problem. And this is exactly the reason why a
bunch of
new Math components no longer fit into Commons, because they fail the
"general purpose".
It has happened before that a Commons component had outgrown the
general
purpose (see former HttpClient that is now a successful TLP) and Math
might
be not the last one. Remember, we already had a successful vote for a
Math
TLP this year for exactly these reasons.
[snip]
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?
It's death when we decide it together. Currently it's your
(well-founded)
opinion.
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).
See, I doubt that all devs were aware of the fact, that we're
currently not
just talking about a Math component with multiple artifacts, but a
bunch of
new Commons components instead (discontinuing the "Math component").
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.
As PMC I care for a sane Commons community with already ~40
maintained
components.
How is that preferable to the user community?
And what does the name "commons-complex-numbers-0.1" vs.
"commons-math-
complex-number-4.0" change for the users' situation I've described
above?
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
Concerning the release cycle, there's no difference between 1 and 2.
3. Create (in the long term) an all-encompassing TLP
4. Create reusable components (right now)
IMHO, 4 is not an option for Commons, only for a Math TLP. Which
needs an
own community. Which has to be rebuilt.
[Add others if appropriate.]
Which is more useful, in your opinion?
As stated above.
To which are you going to contribute (multiple choice allowed,
of course)?
Nowadays I typically care for the release only. And I care for the
impact of
it, because my software stack is also built upon Commons.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
