This is a vote thread - not a discussion thread. If you want to discuss
people’s votes please move it to another thread.
Ralph
> On Aug 20, 2017, at 11:29 AM, Gilles <gil...@harfang.homelinux.org> wrote:
>
> On Sun, 20 Aug 2017 23:16:17 +0530, Amey Jadiye wrote:
>> I'm +1 to this change, I would be more than happy to lend my hands to help
>> on this front. pardon me for being quite because some heavy work on my day
>> job.
>>
>> I don't want to fork this thread to different discussion but I have one
>> simple doubt that rather creating whole new component why don't we just
>> create maven modules within CM? I understand that release becomes easy
>> with different component and some more other advantages but same can be
>> done within single project. this is obvious question and which you guys
>> might have discussed before but I didn't found it in past mail archives,
>
> Some of the objections against having new components were along
> those lines (i.e. "Why not make modules?").
> The problem is not with modules (I quite pushed for modularization
> in "Commons RNG" and "Commons Numbers"), it is with "Commons Math"
> requiring so much work to tackle the backlog (some identified issues
> are _years_ old), in addition to the work for modularizing it.
>
> I don't think that it is acceptable to release code within a new suit
> ("module") without fixing it too.
> And other people here indicated that no Commons Math release should
> remove any code for which no alternative exists.
> So, "Commons Math" is stuck.
>
>
> Gilles
>
>> though I saw a fork of CM made last year and "that" code base is doing
>> exactly what my doubt is. i.e sub-component as maven module.
>>
>> Regards,
>> Amey
>>
>>
>> On Tue, Aug 15, 2017 at 7:56 PM, Gilles <gil...@harfang.homelinux.org>
>> wrote:
>>
>>> Hello.
>>>
>>> [Time for a new episode in our "Ripping CM" series.]
>>>
>>> How about creating "Commons Geometry"?
>>>
>>> The rationale is comprised of the usual suspects:
>>> * Smaller and more focused component, hence:
>>> - Consistent development and maintenance.
>>> - Consistent release schedule, not encumbered by
>>> changes (and endless discussions) in _totally_
>>> unrelated code.
>>> - Potential for attracting contributors not
>>> interested in maintaining the (growing) backlog
>>> of CM.
>>> * Self-contained: 96.3% of the "o.a.c.math4.geometry"
>>> package have no dependency except:
>>> - 4 classes now in "Commons Numbers".
>>> - 2 methods and 1 constant in "MathUtils".
>>> - CM exceptions. [Creating alternatives for those
>>> will probably be the most time-consuming part of
>>> the porting work.]
>>>
>>> Moreover, none of the code in the "o.a.c.math4.geometry"
>>> package is used by another package of CM.
>>>
>>> A new component would give the "geometry" codes a much
>>> better chance of being (confidently[1]) released, since
>>> CM is "stuck" for the foreseeable future.[2]
>>>
>>> WDYT?
>>>
>>> Gilles
>>>
>>> [1] There seems to be only one issue reported in JIRA
>>> that pertains to "geometry".
>>> [2] 54 issues yet to be fixed before the 4.0 release;
>>> which, at the current rate, would lead to after 2025
>>> (a very rough guess, I admit).
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
