[All][Math] New component: "Commons Geometry"?

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[All][Math] New component: "Commons Geometry"?

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Benedikt Ritter-4
Hello Gilles,

> Am 15.08.2017 um 16:26 schrieb Gilles <[hidden email]>:
>
> 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?

I want to see the initial release of Commons Numbers before breaking more components out of CM.

Regards,
Benedikt

>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

garydgregory
On Thu, Aug 17, 2017 at 7:48 AM, Benedikt Ritter <[hidden email]> wrote:

> Hello Gilles,
>
> > Am 15.08.2017 um 16:26 schrieb Gilles <[hidden email]>:
> >
> > 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?
>
> I want to see the initial release of Commons Numbers before breaking more
> components out of CM.
>

Sounds reasonable to me.

Gary


>
> Regards,
> Benedikt
>
> >
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
In reply to this post by Benedikt Ritter-4
Hi Benedikt.

On Thu, 17 Aug 2017 15:48:45 +0200, Benedikt Ritter wrote:

> Hello Gilles,
>
>> Am 15.08.2017 um 16:26 schrieb Gilles
>> <[hidden email]>:
>>
>> 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?
>
> I want to see the initial release of Commons Numbers before breaking
> more components out of CM.

+1
I'm among those who most want to see that release rather sooner
than later.  [IIRC, I posted regularly to inquire about the status
of the pending issues.  Is there more *I* can do at this point?]

I've no problem with serializing the "CM ripping[1]" project.

However, I wish to know what people think of the purely technical,
code-oriented, arguments which I've put forward above.

My suggestion would be to have a "beta" release of the new component
in order to let a community of expert/interested users voice its
opinion on the expected API.  [I think there is a lot of good and
broadly useful code in the "geometry" package (otherwise I wouldn't
ask for a new component) but I also suspect that the API can be
improved.]

Regards,
Gilles

[1] For its own good, and ours. ;-)

> Regards,
> Benedikt
>
>>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Jörg Schaible-5
In reply to this post by Gilles Sadowski
+1

Looks good to me.

Gilles 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Rob Tompkins
+1 with the thought of Benedikt's point about trying to lift one project at a time.

> On Aug 17, 2017, at 11:15 AM, Jörg Schaible <[hidden email]> wrote:
>
> +1
>
> Looks good to me.
>
> Gilles 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

jochen-2
In reply to this post by Gilles Sadowski
On Tue, Aug 15, 2017 at 4:26 PM, Gilles <[hidden email]> wrote:

> How about creating "Commons Geometry"?

Honestly: There are other subprojects (Vfs comes to mind), which are
perfectly able to produce a set of jar file without adding to the list
of jar files for every one. Why do you require a new subproject?

Given the amount of noise, that numbers, RNG, etc. have produced over
the last year, I am more than hesitant to have more of that. (In
particular, when considering the rather limited amount of releases,
which have grown out of that. The "Downloads" section for numbers is
still pointing to RNG.)

As far, as I am concerned, I am clearly -1

Jochen



--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
On Sat, 19 Aug 2017 14:44:09 +0200, Jochen Wiedmann wrote:
> On Tue, Aug 15, 2017 at 4:26 PM, Gilles
> <[hidden email]> wrote:
>
>> How about creating "Commons Geometry"?
>
> Honestly: There are other subprojects (Vfs comes to mind), which are
> perfectly able to produce a set of jar file without adding to the
> list
> of jar files for every one.

I don't understand the purpose of that remark.

> Why do you require a new subproject?

The reasons were on the original post.
Haven't I been proven right that CM would become unmaintained?
I am in favour of attempting to salvage what can be (prioritizing
according to the given criteria).

> Given the amount of noise, that numbers, RNG, etc. have produced over
> the last year, I am more than hesitant to have more of that.

1. Isn't this list supposed to hold discussions? [If it bothers you
    (as it does me, on subjects which I'm not interested in), please
    support the creation of separate MLs.  The "noise" is not IMO a
    reasonable argument to oppose other's work.]
2. It's quite unfair to cite "RNG" in this regard.  Do you refer to
    the "history" (i.e. the dispute I had with our now Apache chairman)?
    Or to something else?  I sure hope that you are not criticizing the
    fact that I developed Commons RNG in full view by commenting every
    aspect on this list and on JIRA.
    Whatever, wasn't it released?  Did it incur any "noise" since then?
3. What noise does the development (mostly porting work) of "Numbers"
    entail? [I certainly wish there would be more noise if it could
    help making the release imminent; remaining issues depend on other
    people (see JIRA).]
4. It's quite unlikely that a "Geometry" component will create any
    noise at this point: cf. my suggestion about a "beta" release.
    If it does afterwards, that it will mean that the goal of
    reviving interest in that codebase (and, hopefully, attracting
    maintainers and contributors) will have succeeded.

> (In
> particular, when considering the rather limited amount of releases,
> which have grown out of that.

The first request (partly spin-off, mostly improvements and new
features) was about package "o.a.c.math4.random".  As a result,
"Commons RNG" v1.0 has indeed been released.
I'm willing to release v1.1 (but waiting for a feature taken on
by someone else).

The second spin-off was "Numbers". No release yet, that's true,
but didn't I indicate that a "Geometry" installment would wait
for that to happen?

What else?  Yes, a "Commons SigProc" idea was floated, but it's
hardly a spin-off from Commons Math: rather it is new donated
code that has a few CM dependencies (which I guess would mostly
become dependencies on "Numbers"). [And not much noise entailed
by that one either, because the donor (and expected main
contributor) hasn't started the porting work yet.]

> The "Downloads" section for numbers is
> still pointing to RNG.)

It's a copy/paste bug. Hardly a reason to stop initiatives.

>
> As far, as I am concerned, I am clearly -1

Obviously, I'm at a loss understanding why...

Regards,
Gilles

>
> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Dave Brosius-2
In reply to this post by Jörg Schaible-5
+1


On 08/17/2017 11:15 AM, Jörg Schaible wrote:

> +1
>
> Looks good to me.
>
> Gilles 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Amey Jadiye
In reply to this post by Gilles Sadowski
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,
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 <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--

---------------------------------------------------------------------

To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
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
> <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Ralph Goers
In reply to this post by jochen-2
I have to agree with Jochen and am -1 to this proposal. I have stated before that I don’t want to see Commons become the placeholder for all the Math related components. If Math has stuff that can’t be maintained then create a MathLegacy project in the sandbox and move the stuff there.

Ralph

> On Aug 19, 2017, at 5:44 AM, Jochen Wiedmann <[hidden email]> wrote:
>
> On Tue, Aug 15, 2017 at 4:26 PM, Gilles <[hidden email]> wrote:
>
>> How about creating "Commons Geometry"?
>
> Honestly: There are other subprojects (Vfs comes to mind), which are
> perfectly able to produce a set of jar file without adding to the list
> of jar files for every one. Why do you require a new subproject?
>
> Given the amount of noise, that numbers, RNG, etc. have produced over
> the last year, I am more than hesitant to have more of that. (In
> particular, when considering the rather limited amount of releases,
> which have grown out of that. The "Downloads" section for numbers is
> still pointing to RNG.)
>
> As far, as I am concerned, I am clearly -1
>
> Jochen
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Ralph Goers
In reply to this post by Gilles Sadowski
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 <[hidden email]> 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 <[hidden email]>
>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Benedikt Ritter-4
In reply to this post by Ralph Goers

> Am 20.08.2017 um 23:11 schrieb Ralph Goers <[hidden email]>:
>
> I have to agree with Jochen and am -1 to this proposal. I have stated before that I don’t want to see Commons become the placeholder for all the Math related components. If Math has stuff that can’t be maintained then create a MathLegacy project in the sandbox and move the stuff there.

I’ve also already argued in that direction.

Benedikt

>
> Ralph
>
>> On Aug 19, 2017, at 5:44 AM, Jochen Wiedmann <[hidden email]> wrote:
>>
>> On Tue, Aug 15, 2017 at 4:26 PM, Gilles <[hidden email]> wrote:
>>
>>> How about creating "Commons Geometry"?
>>
>> Honestly: There are other subprojects (Vfs comes to mind), which are
>> perfectly able to produce a set of jar file without adding to the list
>> of jar files for every one. Why do you require a new subproject?
>>
>> Given the amount of noise, that numbers, RNG, etc. have produced over
>> the last year, I am more than hesitant to have more of that. (In
>> particular, when considering the rather limited amount of releases,
>> which have grown out of that. The "Downloads" section for numbers is
>> still pointing to RNG.)
>>
>> As far, as I am concerned, I am clearly -1
>>
>> Jochen
>>
>>
>>
>> --
>> The next time you hear: "Don't reinvent the wheel!"
>>
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:

>> Am 20.08.2017 um 23:11 schrieb Ralph Goers
>> <[hidden email]>:
>>
>> I have to agree with Jochen and am -1 to this proposal. I have
>> stated before that I don’t want to see Commons become the placeholder
>> for all the Math related components. If Math has stuff that can’t be
>> maintained then create a MathLegacy project in the sandbox and move
>> the stuff there.
>
> I’ve also already argued in that direction.

I gave technical arguments in favour of the proposal (cf. first
post in this thread).

People opposing it give none.
A sudden "allergy" of some PMC members to "math"-related code
does not warrant rejecting non-obsolete code.[1]

A good start would be to answer this question: Why is it bad (or
worse than the current situation) to have this "new" component?


Gilles

[1] Unless you have exclusive information that geometrical
     concepts will be outdated soon.

>
> Benedikt
>
>>
>> Ralph
>>
>>> On Aug 19, 2017, at 5:44 AM, Jochen Wiedmann
>>> <[hidden email]> wrote:
>>>
>>> On Tue, Aug 15, 2017 at 4:26 PM, Gilles
>>> <[hidden email]> wrote:
>>>
>>>> How about creating "Commons Geometry"?
>>>
>>> Honestly: There are other subprojects (Vfs comes to mind), which
>>> are
>>> perfectly able to produce a set of jar file without adding to the
>>> list
>>> of jar files for every one. Why do you require a new subproject?
>>>
>>> Given the amount of noise, that numbers, RNG, etc. have produced
>>> over
>>> the last year, I am more than hesitant to have more of that. (In
>>> particular, when considering the rather limited amount of releases,
>>> which have grown out of that. The "Downloads" section for numbers
>>> is
>>> still pointing to RNG.)
>>>
>>> As far, as I am concerned, I am clearly -1
>>>
>>> Jochen
>>>
>>>
>>>
>>> --
>>> The next time you hear: "Don't reinvent the wheel!"
>>>
>>>
>>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Ralph Goers
In reply to this post by Ralph Goers
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Ralph Goers
In reply to this post by Gilles Sadowski

> On Aug 21, 2017, at 4:39 AM, Gilles <[hidden email]> wrote:
>
> On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:
>>> Am 20.08.2017 um 23:11 schrieb Ralph Goers <[hidden email]>:
>>>
>>> I have to agree with Jochen and am -1 to this proposal. I have stated before that I don’t want to see Commons become the placeholder for all the Math related components. If Math has stuff that can’t be maintained then create a MathLegacy project in the sandbox and move the stuff there.
>>
>> I’ve also already argued in that direction.
>
> I gave technical arguments in favour of the proposal (cf. first
> post in this thread).
>
> People opposing it give none.
> A sudden "allergy" of some PMC members to "math"-related code
> does not warrant rejecting non-obsolete code.[1]
>
> A good start would be to answer this question: Why is it bad (or
> worse than the current situation) to have this "new" component?

Technical arguments are not required since this is basically a housekeeping issue.

I’m not sure why I would answer your last question since you are clearly going to have a different opinion. But many of us believe that Math is a great name for a project that contains math subcomponents, rather than wading through a bunch of different Commons projects. Eventually you are going to want Commons Statistics, Commons Transforms, Commons Primes, etc. or things that are even more specific. All of these should be modules under Math. To be honest, I’m really not clear why Commons Numbers was approved as I’ve never heard anyone talk about complex numbers or fractions in anything but a mathematical concept.

I get that what you are really trying to do is kill Commons Math off piece by piece. I just don’t agree with doing that.

Ralph



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Dave Brosius-2
 >> I get that what you are really trying to do is kill Commons Math off
piece by piece. I just don’t agree with doing that.


This is ridiculous. Giles is the primary person trying to keep some
semblance of commons-math-like-stuff alive. He has asserted that there
is no way he can maintain all of commons-math, and no one else is really
all that interested.  Time has proven he is right.

Given he is trying his best to keep code going, and actually the one
doing the work, perhaps we should be a little bit less offensive about
trying to shut him down.

--dave

On 08/21/2017 01:52 PM, Ralph Goers wrote:

>> On Aug 21, 2017, at 4:39 AM, Gilles <[hidden email]> wrote:
>>
>> On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:
>>>> Am 20.08.2017 um 23:11 schrieb Ralph Goers <[hidden email]>:
>>>>
>>>> I have to agree with Jochen and am -1 to this proposal. I have stated before that I don’t want to see Commons become the placeholder for all the Math related components. If Math has stuff that can’t be maintained then create a MathLegacy project in the sandbox and move the stuff there.
>>> I’ve also already argued in that direction.
>> I gave technical arguments in favour of the proposal (cf. first
>> post in this thread).
>>
>> People opposing it give none.
>> A sudden "allergy" of some PMC members to "math"-related code
>> does not warrant rejecting non-obsolete code.[1]
>>
>> A good start would be to answer this question: Why is it bad (or
>> worse than the current situation) to have this "new" component?
> Technical arguments are not required since this is basically a housekeeping issue.
>
> I’m not sure why I would answer your last question since you are clearly going to have a different opinion. But many of us believe that Math is a great name for a project that contains math subcomponents, rather than wading through a bunch of different Commons projects. Eventually you are going to want Commons Statistics, Commons Transforms, Commons Primes, etc. or things that are even more specific. All of these should be modules under Math. To be honest, I’m really not clear why Commons Numbers was approved as I’ve never heard anyone talk about complex numbers or fractions in anything but a mathematical concept.
>
> I get that what you are really trying to do is kill Commons Math off piece by piece. I just don’t agree with doing that.
>
> Ralph
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

garydgregory
What about this for a compromise: create Commons Math 5 as a multi-module
project and bring in as submodules only the newly minted components and
whatever gets spun out of Math 3/4.

Gary

On Aug 21, 2017 13:26, "Dave Brosius" <[hidden email]> wrote:

> >> I get that what you are really trying to do is kill Commons Math off
> piece by piece. I just don’t agree with doing that.
>
>
> This is ridiculous. Giles is the primary person trying to keep some
> semblance of commons-math-like-stuff alive. He has asserted that there is
> no way he can maintain all of commons-math, and no one else is really all
> that interested.  Time has proven he is right.
>
> Given he is trying his best to keep code going, and actually the one doing
> the work, perhaps we should be a little bit less offensive about trying to
> shut him down.
>
> --dave
>
> On 08/21/2017 01:52 PM, Ralph Goers wrote:
>
>> On Aug 21, 2017, at 4:39 AM, Gilles <[hidden email]> wrote:
>>>
>>> On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:
>>>
>>>> Am 20.08.2017 um 23:11 schrieb Ralph Goers <[hidden email]
>>>>> >:
>>>>>
>>>>> I have to agree with Jochen and am -1 to this proposal. I have stated
>>>>> before that I don’t want to see Commons become the placeholder for all the
>>>>> Math related components. If Math has stuff that can’t be maintained then
>>>>> create a MathLegacy project in the sandbox and move the stuff there.
>>>>>
>>>> I’ve also already argued in that direction.
>>>>
>>> I gave technical arguments in favour of the proposal (cf. first
>>> post in this thread).
>>>
>>> People opposing it give none.
>>> A sudden "allergy" of some PMC members to "math"-related code
>>> does not warrant rejecting non-obsolete code.[1]
>>>
>>> A good start would be to answer this question: Why is it bad (or
>>> worse than the current situation) to have this "new" component?
>>>
>> Technical arguments are not required since this is basically a
>> housekeeping issue.
>>
>> I’m not sure why I would answer your last question since you are clearly
>> going to have a different opinion. But many of us believe that Math is a
>> great name for a project that contains math subcomponents, rather than
>> wading through a bunch of different Commons projects. Eventually you are
>> going to want Commons Statistics, Commons Transforms, Commons Primes, etc.
>> or things that are even more specific. All of these should be modules under
>> Math. To be honest, I’m really not clear why Commons Numbers was approved
>> as I’ve never heard anyone talk about complex numbers or fractions in
>> anything but a mathematical concept.
>>
>> I get that what you are really trying to do is kill Commons Math off
>> piece by piece. I just don’t agree with doing that.
>>
>> Ralph
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Rob Tompkins


> On Aug 21, 2017, at 3:41 PM, Gary Gregory <[hidden email]> wrote:
>
> What about this for a compromise: create Commons Math 5 as a multi-module
> project and bring in as submodules only the newly minted components and
> whatever gets spun out of Math 3/4.

This feels like a good compromise to me. I'm actually surprised were not going this direction with math 4.  

-Rob

>
> Gary
>
> On Aug 21, 2017 13:26, "Dave Brosius" <[hidden email]> wrote:
>
>>>> I get that what you are really trying to do is kill Commons Math off
>> piece by piece. I just don’t agree with doing that.
>>
>>
>> This is ridiculous. Giles is the primary person trying to keep some
>> semblance of commons-math-like-stuff alive. He has asserted that there is
>> no way he can maintain all of commons-math, and no one else is really all
>> that interested.  Time has proven he is right.
>>
>> Given he is trying his best to keep code going, and actually the one doing
>> the work, perhaps we should be a little bit less offensive about trying to
>> shut him down.
>>
>> --dave
>>
>>> On 08/21/2017 01:52 PM, Ralph Goers wrote:
>>>
>>>> On Aug 21, 2017, at 4:39 AM, Gilles <[hidden email]> wrote:
>>>>
>>>>> On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote:
>>>>>
>>>>> Am 20.08.2017 um 23:11 schrieb Ralph Goers <[hidden email]
>>>>>>> :
>>>>>>
>>>>>> I have to agree with Jochen and am -1 to this proposal. I have stated
>>>>>> before that I don’t want to see Commons become the placeholder for all the
>>>>>> Math related components. If Math has stuff that can’t be maintained then
>>>>>> create a MathLegacy project in the sandbox and move the stuff there.
>>>>>>
>>>>> I’ve also already argued in that direction.
>>>>>
>>>> I gave technical arguments in favour of the proposal (cf. first
>>>> post in this thread).
>>>>
>>>> People opposing it give none.
>>>> A sudden "allergy" of some PMC members to "math"-related code
>>>> does not warrant rejecting non-obsolete code.[1]
>>>>
>>>> A good start would be to answer this question: Why is it bad (or
>>>> worse than the current situation) to have this "new" component?
>>>>
>>> Technical arguments are not required since this is basically a
>>> housekeeping issue.
>>>
>>> I’m not sure why I would answer your last question since you are clearly
>>> going to have a different opinion. But many of us believe that Math is a
>>> great name for a project that contains math subcomponents, rather than
>>> wading through a bunch of different Commons projects. Eventually you are
>>> going to want Commons Statistics, Commons Transforms, Commons Primes, etc.
>>> or things that are even more specific. All of these should be modules under
>>> Math. To be honest, I’m really not clear why Commons Numbers was approved
>>> as I’ve never heard anyone talk about complex numbers or fractions in
>>> anything but a mathematical concept.
>>>
>>> I get that what you are really trying to do is kill Commons Math off
>>> piece by piece. I just don’t agree with doing that.
>>>
>>> Ralph
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234