commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <>
Subject Re: [ALL] The Commons Math issue
Date Fri, 14 Apr 2017 10:49:25 GMT

sorry for coming late to the table. I think Gary summed it up pretty well:

„I see busy people doing what they want when the want in all
of Commons, respectfully and diligently.“

After going through the mails, I still don’t understand how the PMC needs to change it ways
in order to move CM forward. If there’s nobody interested/has the time to maintain the code,
so be it. I’m regularly monitoring the proper components and move those which really nobody
needs anymore to dormant. CM has never been on my list.

Regarding the decision to keep CM here at commons: As far as I remember (I’m sure Gilles
has the likes to the archives ;-)) the PMC was pretty ambivalent and let it to the CM developers.
That group decided it would be better to stay at commons. Later some of those people decided
it would be better to move away from Apache all together. That’s okay for me.
My personal opinion is, that neither CM, nor numbers or RNG belong into commons. They are
to specific and should form a TLP on their own. But that’s only my opinion. And I’m fine
with the way it is now.

My 2 cents

> Am 13.04.2017 um 14:12 schrieb Gilles <>:
> Hi Jörg.
> On Thu, 13 Apr 2017 11:31:17 +0200, Jörg Schaible wrote:
>> Hi Oliver,
>> Oliver Heger wrote:
>>> Am 12.04.2017 um 19:39 schrieb Gilles:
>>>> On Wed, 12 Apr 2017 18:25:03 +0200, Emmanuel Bourg wrote:
>>>>> On 04/12/2017 05:29 PM, Gilles wrote:
>>>>>> Do you actually prefer advertizing a non-Apache project rather than
>>>>>> having the PMC support its own developers in any which way it could?
>>>>> If nobody is able to maintain commons-math I have no objection
>>>>> recommending an alternative, especially one that is derived from
>>>>> commons-math, has the same license and an open development process.
>>>> The issue here is that an "in-house" solution has been proposed,
>>>> based on time-consuming work on the part of developers still
>>>> contributing here.
>>>> The PMC members should logically (?) favour any proper endeavour
>>>> that attempts to keep _this_ community alive.
>>>> For functionality that requires expertise not existing anymore around
>>>> here, it would be fine though, of course.
>>>> Thus I ask that we make a list of such functionality before dismissing
>>>> the local goodwill as if it didn't exist.
>>>>> The minimal support you can expect from the PMC members is people voting
>>>>> on the releases, and if there is no show stopper like binary
>>>>> incompatibilities, awful regressions or improperly licensed code, the
>>>>> vote will be a non-issue.
>>>>>> How can you be so sure? The last releases did not elicit an awful
>>>>>> of votes; and that is for components that do not raise objections
>>>>>> their mere existence.
>>>>> Give it a try?
>>>> OK for small, focused, components?
>>> I am fine with Commons RNG and Commons Numbers.
>>> I would feel uneasy with a significant number of mathematical components
>>> extracted from [math] that are added to Commons, even if they are small
>>> and focused. It would seem strange if you opened the Commons Web site
>>> and about half of the components were math-related. If this is the goal,
>>> I would prefer to start again the top-level-project discussion.
>> Then let's continue with it unless we *have* a significant number of
>> components. If those attract in completion enough contributors/committers,
>> we can again try to form a TLP and donate all of them. IMHO the creation of
>> RNG and Numbers was healthy to our ecosystem, therefore I don't see a reason
>> to stop with the separation of more component out of Math now.
> What a change from the generally overwhelmingly negative tone
> of this ML! ;-)
> Can we learn something from why it was so hard for long-time
> developers to accept even non-destructive changes?
> IOW, can we expand on what is "healthy to our ecosystem"?
> Thank you,
> Gilles
>> Cheers,
>> Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: <>
> For additional commands, e-mail: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message