commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL] The Commons Math issue
Date Sat, 15 Apr 2017 17:20:40 GMT
On Sat, 15 Apr 2017 17:51:34 +0200, Oliver Heger wrote:
> Am 15.04.2017 um 00:15 schrieb Gilles:
>> Hi Oliver.
>>
>> On Fri, 14 Apr 2017 21:48:26 +0200, Oliver Heger wrote:
>>> Hi,
>>>
>>> Am 14.04.2017 um 17:12 schrieb Gilles:
>>>> Hi Benedikt.
>>>>
>>>> On Fri, 14 Apr 2017 12:49:25 +0200, Benedikt Ritter wrote:
>>>>> [...]
>>>>
>>>>> 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.
>>>>
>>>> The only working definition I know of "Commons" is: a home for
>>>> projects too small to exist on their own.
>>>> I gathered that what is important is that there are people willing
>>>> to maintain the component.
>>>>
>>>>> But that’s only my opinion.
>>>>
>>>> I *really* do not understand how you form an opinion that
>>>> "RNG" and "Numbers" do not belong as rightfully as <any other>
>>>> component.
>>>
>>> The Commons charter mentions "reusable libraries and components". I 
>>> used
>>> to interpret this as general-purpose components, meaning that they 
>>> are
>>> useful for applications in multiple domains. This definition should 
>>> hold
>>> for most of the components we have now.
>>
>> But not for "RNG" or "Numbers"?
>>
>> How many is "multiple"?
>>
>>> It does not hold for specialized math components.
>>
>> Do you believe that the other components are not "specialized"?
> Yes, I believe that they are general purpose in nature. Stuff from
> [lang] or [io] can be used e.g. by applications in financial sector, 
> in
> aviation, in medicine, in web applications, in command line tools, 
> you
> name it.

And many of the packages in "Commons Math" can also be used
in all those. [Financial applications without statistics or
integer arithmetics? Engineering without linear algebra, solvers,
optimizers? Medecine without geometry (for 3D visualization)? ...]

I think that it's not the right POV.

This place (and I read it from "Commons" people) came about as
a home for codebases that were too small too warrant a TLP.
Add the commitment to maintain the codebase, and it's a fine
policy for accepting new content.

>>
>> I never had the need for any of the "Commons" components except
>> CM, but it would not occur to me to speculate about how largely
>> useful they actually are.
>> I trust their creators/maintainers in that respect.
> This is not about usefulness of a component, but whether it is a fit 
> for
> [commons].
>
> That you never had the need for any other component could also be an
> indicator that [math] does not really fit in, couldn't it?

Hmm, let's pause a minute...

I totally agree with you.
Or, in fact, you agree with me, finally!

Indeed, if I knew how, I could make a query on the ML archive,
and retrieve a few posts where I wrote, several years ago, that
"Commons Math" was too big (a.o. things) to be considered on the
same footing as the other components.

However, contrary to "Commons Math", the parts which I want to
extract from it, fully qualify (according to the above operating
definition).

Moreover, some of those utilities are often so necessary that
many developers constantly reinvent them when they are not
provided by the language standard libraries.


Regards,
Gilles

>
> Oliver
>
>>
>> Now, you can validly argue that people needing the kind of
>> math-related stuff of CM would not use Java... ;-)
>>
>>> Therefore, I
>>> personally feel uneasy with them and would have difficulties to 
>>> provide
>>> oversight for them.
>>
>> As long as someone else helps where you cannot, what's the
>> problem?
>> And when nobody can, there is "dormant"...
>>
>> Gilles
>>
>>>
>>> But granted, the distinction is not very clear, and this is my
>>> interpretation.
>>>
>>> Oliver
>>>
>>>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message