commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@bpm-inspire.com>
Subject Re: [Math] Commons Math (r)evolution
Date Thu, 09 Jun 2016 07:43:06 GMT
Hi Gilles,

Gilles wrote:

> Hi.
> 
> On Wed, 8 Jun 2016 23:50:00 +0300, Artem Barger wrote:
>> On Wed, Jun 8, 2016 at 12:25 AM, Gilles
>> <gilles@harfang.homelinux.org>
>> wrote:
>>
>>>
>>> According to JIRA, among 180 issues currently targeted for the
>>>>> next major release (v4.0), 139 have been resolved (75 of which
>>>>> were not in v3.6.1).
>>>>>
>>>>>
>>>> ​Huh, it's above of 75% completion :)​
>>>>
>>>
>>> Everybody is welcome to review the "open" issues and comment
>>> about them.
>>>
>>>
>> ​I guess someone need to prioritize them​ according to they
>> importance for
>> release.
> 
> Importance is relative... :-}
> 
> IMO, it is important to not release unsupported code.

Unit test *are* kind of support.

> So the priority would be higher for issues that would be included
> in the release of the new Commons components.
> Hence the need to figure out what these components will be.
> 
>>>>> Of course, anyone who wishes to maintain some of these codes
>>>>>
>>>>> (answer user questions, fix bugs, create enhancements, etc.)
>>>>> is most welcome to step forward.
>>>>>
>>>>>
>>>> ​I can try to cover some of these and maintain relevant code
>>>> parts.​
>>>>
>>>
>>> Which ones?
>>>
>> ​I will look into JIRA and provide the issue numbers, and of course I
>> can cover and assist with ML part and particular clustering.​
> 
> Thanks.
> 
>>>
>>> IMO, a maintainer is someone who is able to respond to user
>>> questions and to figure out whether a bug report is valid.
>>>
>>
>> ​I'm subscribed for mailing list for quite a while and haven't
>> seen a lot of questions coming from user​s.
> 
> The "user" ML has always been fairly quiet.
> Does it mean that the code is really easy to use?
> Or feature-complete (I doubt that)?
> Or that there are very few users for the most complex features?
> 
> The "dev" ML was usually (much) more active.
> 
> The point is that when someone asks a question or propose an
> contribution, there must be someone to answer.

And this is IMHO a wrong assumption. We have a lot of components where the 
original authors have left long ago. So the situation is not new.

Math is a specialized library and nobody expects that it is accompanied by 
tutorials explaining the theory or developers that act as trainers here on 
the lists. Users of special algorithms are supposed to be experts themselves 
and should understand what they are doing. Or do you expect that any 
arbitrary user can use genetic algorithms or neuronal network stuff without 
the mathematical background?

Anything is well and can be released as long as the existing code is 
verified by unit tests. Otherwise we would have to remove a lot of code 
every time we release a component ... or do you expect e.g. that the release 
manager of vfs understands completely any of its providers?

>>>>> ​I think that clustering part could be generalized to ML package
>>>>> as a
>>>> whole.​
>>>>
>>>
>>> Fine I guess, since currently the "neuralnet" sub-package's only
>>> concrete functionality is also a clustering method.
>>>
>>>
>> ​I was also wondering whenever ML package meant to be extended in
>> the future
> 
> Really there was no plan, or as many plans as there were developers...
> 
> Putting all these codes (with different designs, different coding
> practices, different intended audiences, different levels of expertise,
> etc.) in a single library was not sustainable.
> 
> 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*. Turning math into a multi-project has nothing to do with your 
plans to drop mature code, because you (and currently no-one else) cannot 
answer questions to its functionality.

Cheers,
Jörg


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


Mime
View raw message