commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject RE: [Math] Commons Math (r)evolution
Date Fri, 10 Jun 2016 22:55:16 GMT
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 ""
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.


> Thanks,
> Patrick
> -----Original Message-----
> From: Jörg Schaible []
> Sent: Friday, June 10, 2016 6:20 AM
> To:
> 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:
For additional commands, e-mail:

View raw message