oops. My bad. I just noticed this is NOT a vote there. I just saw what looked
like votes.
Ralph
> On Aug 20, 2017, at 2:12 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
