Re: [All][Math] New component: "Commons Geometry"?
Hello Gilles, > Am 15.08.2017 um 16:26 schrieb Gilles : > > 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: 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
Re: [All][Math] New component: "Commons Geometry"?
On Thu, Aug 17, 2017 at 7:48 AM, Benedikt Ritter wrote: > Hello Gilles, > > > Am 15.08.2017 um 16:26 schrieb Gilles : > > > > 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: 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 > >
Re: [All][Math] New component: "Commons Geometry"?
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 : 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
+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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
+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 > 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: 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
Re: [All][Math] New component: "Commons Geometry"?
On Tue, Aug 15, 2017 at 4:26 PM, Gilles 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Sat, 19 Aug 2017 14:44:09 +0200, Jochen Wiedmann wrote: On Tue, Aug 15, 2017 at 4:26 PM, Gilles 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
+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: 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
Re: [All][Math] New component: "Commons Geometry"?
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 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
Re: [All][Math] New component: "Commons Geometry"?
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
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
Re: [All][Math] New component: "Commons Geometry"?
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 > wrote: > > On Tue, Aug 15, 2017 at 4:26 PM, Gilles 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: 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
Re: [All][Math] New component: "Commons Geometry"?
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 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
>> 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
Re: [All][Math] New component: "Commons Geometry"?
> Am 20.08.2017 um 23:11 schrieb Ralph Goers : > > 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 >> wrote: >> >> On Tue, Aug 15, 2017 at 4:26 PM, Gilles 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: 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
Re: [All][Math] New component: "Commons Geometry"?
On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: Am 20.08.2017 um 23:11 schrieb Ralph Goers : 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 wrote: On Tue, Aug 15, 2017 at 4:26 PM, Gilles 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
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 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 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
>>> 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
Re: [All][Math] New component: "Commons Geometry"?
> On Aug 21, 2017, at 4:39 AM, Gilles wrote: > > On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: >>> Am 20.08.2017 um 23:11 schrieb Ralph Goers : >>> >>> 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
>> 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 wrote: On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: Am 20.08.2017 um 23:11 schrieb Ralph Goers : 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: 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
Re: [All][Math] New component: "Commons Geometry"?
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" 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 wrote: >>> >>> On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: >>> Am 20.08.2017 um 23:11 schrieb Ralph Goers >: > > 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: 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 > >
Re: [All][Math] New component: "Commons Geometry"?
> On Aug 21, 2017, at 3:41 PM, Gary Gregory 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" 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 wrote: > On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: > > Am 20.08.2017 um 23:11 schrieb Ralph Goers >> : >> >> 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: 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
Re: [All][Math] New component: "Commons Geometry"?
On Mon, 21 Aug 2017 10:52:28 -0700, Ralph Goers wrote: On Aug 21, 2017, at 4:39 AM, Gilles wrote: On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: Am 20.08.2017 um 23:11 schrieb Ralph Goers : 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. It is not, unless you consider that doing some ground work for an (Apache) community to grow around an objectively useful piece of code is not worth trying. I’m not sure why I would answer your last question since you are clearly going to have a different opinion. My opinion is based on technical arguments; so why shouldn't yours too? Maybe those arguments can then convince me that I should let it down (and that over 10 years of volunteering work here were basically a waste of time). 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. I've already answered to this argument. Here is some of the reasoning: 1. "Math" is not a well-defined project name. It is much, much, much, too broad. It was the source of endless managements problems for "Commons Math", on to the fork itself. 2. "Commons Math" contains such loosely related things that grouping them hardly makes more sense than declaring that all "Commons" components should be modules of a unique maven project. 3. It is very unlikely that such a diversity of codes can be maintained by people who are able or willing to maintain all of it. 4. This has led to swaths of codes being developed without any review whatsoever. Confidence in them solely resided in the expertise of its developer (no plural intended). 5. The sole consensus on global development that could be reached was on including more and more code that would become unmaintainable once the developer responsible for would leave (as _proven_ by the facts, since the fork). And on, and on... Eventually you are going to want Commons Statistics, Commons Transforms, Commons Primes, etc. or things that are even more specific. No. *I* do not want it. The only thing I want is to release _good_ components. "Commons Math" has good code in it, but is a bad "component". [I've tried to show with "Commons RNG" what (I think) is a good component: narrow focus, modular, simple API and usage.] Other programming languages eco-systems successfully follow an approach based on (really) small components; why would you want "Commons Math" to remain this monolithic beast? 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. Again, arguing that all things pertaining to "a mathematical concept" should belong to a single library is no more sensible than, for example, assuming that all logging frameworks should all be modules of a unique library... 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. The "Commons Math" component was killed off by those who decided to fork it. Period. Long before that, I had indicated that some change was desirable (IMHO); but the course was set by the majority of regular contributors, who were able to maintain the various pieces. That was fair. But, since the fork, who belongs to that category? Why do you want to pretend that a healthy "Commons Math" component exists, when big parts of it are not maintained and that no slight refactoring is needed to fix some of the reported issues? Did I understand correctly that moving the whole of "Commons Math" to "dormant" is your most generous offer to those of us who try to find a way forward for some of the most useful code that it contains? Gilles Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
That is what I would like to see. Ralph > On Aug 21, 2017, at 12:41 PM, Gary Gregory 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. > > Gary > > On Aug 21, 2017 13:26, "Dave Brosius" 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 wrote: On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: > Am 20.08.2017 um 23:11 schrieb Ralph Goers >> : >> >> 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: 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
Re: [All][Math] New component: "Commons Geometry"?
On Mon, 21 Aug 2017 15:43:30 -0400, Rob Tompkins wrote: On Aug 21, 2017, at 3:41 PM, Gary Gregory 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. This route was not taken because it had been _explicitly_ forbidden by some of the PMC members. And I admit that there was some technical argument for not doing it, namely that we must leave the path open in case some (yet unknown) contributors want to continue from CM "master". Following the usual policy, a new release would make non-included code officially unsupported. [Doing otherwise would just increase the work load even more.] Another aspect of that route, also _explicitly_ enforced by the PMC policy is that all modules of a component must be released together, with the same version (cf. ML archive for the long story). This does not fit a codebase comprised of totally unrelated functionalities (see my preceding post): It makes no sense to have to release, say, a new "math-complex" module (possibly with different package name!) because a new release of "math-genetic" is required. There are several components in "Commons" and nobody in his right mind would suggest to group them all under a single maven project, for exactly that reason. Yet somehow, "Oh, this is math-related stuff" is sufficient to jump to the opposite conclusion. Gilles -Rob Gary On Aug 21, 2017 13:26, "Dave Brosius" 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 wrote: On Mon, 21 Aug 2017 08:31:55 +0200, Benedikt Ritter wrote: Am 20.08.2017 um 23:11 schrieb Ralph Goers : 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Mon, Aug 21, 2017 at 11:20 PM, Gilles wrote: > Other programming languages eco-systems successfully follow > an approach based on (really) small components; why would you > want "Commons Math" to remain this monolithic beast? No one is arguing for monolithic. We are simply questioning, whether a split in Maven modules is sufficient, or not. My impression is, that you are not even considering that more lightweight approach. The arguments are giving, are typically answered just as well with modules. Plus, you avoid losing oversight over the sum. 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Tue, 22 Aug 2017 18:35:22 +0200, Jochen Wiedmann wrote:
On Mon, Aug 21, 2017 at 11:20 PM, Gilles
wrote:
Other programming languages eco-systems successfully follow
an approach based on (really) small components; why would you
want "Commons Math" to remain this monolithic beast?
No one is arguing for monolithic. We are simply questioning, whether
a
split in Maven modules is sufficient, or not.
It is not.
My impression is, that you are not even considering that more
lightweight approach.
I have. From the outset.
I'm going to reiterate, once more.[1]
Some of the packages/codes of CM are candidates for standalone
components.
There are several reasons, possibly different for different
candidates:
1. Low-level, e.g.
* Check for equality between "double" values
* Fractions
* Complex numbers
* Combinatorics
* Prime numbers
Each of those can be of interest to quite different categories
of users.
[However, being quite low-level, it was not a bad compromise to
group them all in a component called "Numbers" on the rationale
that all deal with some kind of "number" (we can look at it as
the level just above the elementary "Number"s of the JDK).
2. Self-contained (i.e. no dependency on anything else), e.g.
* Code originally in the "o.a.c.math4.random" package that has
started the development of "Commons RNG".
Again of interest to a wide range of users.[2]
3. Standalone (with dependencies on a few low-level utilities
such as those that are, or would fit, in "Numbers", and "RNG",
but on nothing else from CM), e.g.
* Package "o.a.c.math4.geometry"
* Package "o.a.c.math4.ml"
* Package "o.a.c.math4.distribution" (except perhaps the
"multivariate" Gaussian)
Those are, by all sensible criteria, independent fields of
expertise and different user/developer communities; there is
no reason to group them in a single library.
With those, ends the list of what I think would be good
components (with no less general usefulness[3] than some
other "Commons" components).
No "avalanche" of new components, no unbearable "noise"
on the ML, no fear of PMC exhaustion at validating
release candidates.
I contend that project management and review work will
be _easier_ due to the more focused subject matters.
And I've no problem with doing one after the other, as
said previously.
Then there is package "o.a.c.m.genetics", whose support
should be discontinued (IMHO), for reasons given elsewhere.
The rest of CM is comprised of package with intertwined
dependencies:
* matrix algebra (package "o.a.c.m.linear")
* functions, integration, interpolation, root solvers
(package "o.a.c.m.analysis")
* differential equation solvers (package "o.a.c.m.ode")
* statistics (package "o.a.c.m.stat")
* optimizers (packages "o.a.c.m.optim" and "o.a.c.m.fitting")
* automatic differentiation ("o.a.c.m.analysis.differentiation")
In addition to being the sort of functionality that indeed
constitutes a "math toolbox", those packages would also stay
together for the following practical reasons:
1. Most unresolved issues target codes in them. Some have
been open for years. Some seem to require non-trivial
debugging.
2. Some of those issues can't be solved without significant
refactoring (particularly in "linear" and "stat").
3. Some codes were left dangling midway of a refactoring
(namely "optim").
One of my points is to make a clear and useful difference
between actively supported code (the new components) and
code in need of new blood ("MathLegacy").
The former is timely released with all bugs fixed.
The latter could be released (PMC willing) as a WIP, to
not let down users of codes that satisfy their needs (i.e.
the bugs do not show up for them).
Down to the level of practicalities, it will of course be
an improvement of "Mathlegacy" if it can be modularized.
But this in itself is already a lot of work which it would
be insane to complete without also fixing the design bugs
as they are encountered.
The arguments are giving, are typically answered
just as well with modules.
If that were true, the same argument would apply to the
whole of "Commons": just release all of it as modules
within a single maven project.
Plus, you avoid losing oversight over the
sum.
Adding apples and pears.
Oversight of unrelated functionalities is useless (and even
a liability, as it turned out).
Oversight is required at the "Commons" level, to ensure that
components are healthy.
What other proof do you need that "Commons Math" wasn't?[4]
Plus, a team of maintainers who, together, had a nearly
100% reactivity level could make up for the project's
failure to define a clear "management"; now the reactivity
level is on life-support,[5] and the shortcomings should
be apparent to all.
Gilles
Jochen
[1] Those reasonable arguments are already in the archive in
one form or another...
[2] If they have strong randomization requirements, they should
stop using "
Re: [All][Math] New component: "Commons Geometry"?
Le 21/08/2017 à 21:41, Gary Gregory a écrit : > 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. +1 for multiple modules instead of multiple components. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Wed, 30 Aug 2017 15:28:49 +0200, Emmanuel Bourg wrote: Le 21/08/2017 à 21:41, Gary Gregory a écrit : 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. +1 for multiple modules instead of multiple components. Emmanuel Bourg -1 to asking others to do one's work.[1] Gilles [1] More complete answer _already_ given. You should reply to that post, with concrete arguments. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Le 30/08/2017 à 22:14, Gilles a écrit : > -1 to asking others to do one's work.[1] So whatever the others think you don't care? If the quantity of work is important to you then you should be happy with a multi-module project since it induces significantly less work than multiple components: - one source repository - one JIRA setup - one site to manage - less release votes - less hair-pulling about defining component scopes - more flexibility to rearrange code between modules I thought you already realized that when you eventually agreed to pick this strategy for RNG instead of creating more components. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Thu, 31 Aug 2017 10:53:56 +0200, Emmanuel Bourg wrote: Le 30/08/2017 à 22:14, Gilles a écrit : -1 to asking others to do one's work.[1] So whatever the others think you don't care? If the quantity of work is important to you then you should be happy with a multi-module project since it induces significantly less work than multiple components: - one source repository - one JIRA setup - one site to manage - less release votes - less hair-pulling about defining component scopes - more flexibility to rearrange code between modules I thought you already realized that when you eventually agreed to pick this strategy for RNG instead of creating more components. Emmanuel Bourg Emmanuel, If you are a "nice guy" (as you once wrote on this ML), then maybe we've got a "media" problem; it's a pity we cannot meet in person to sort all those issues, to which I've brought answers upon answers, several times over (really it's all in the archive). [It reminds me that I had to meet the key developer of CM to have him realize how absurd it was to advocate for checked exceptions the way he did, whatever arguments I had been exposing for weeks on the ML.] You don't seem to get, and neither did the former core team of CM, that _everybody_ (thus "me too") is entitled to his opinion; if there are several opinions, then IMHO we must try to satisfy all the actual _contributors_, if they are willing to work toward whatever their opinion leads them to. To make it short and to the point: if you want CM modules, then start modularizing it. I'm not against you modularizing CM, I'm against me doing it just because you "think" it's a better approach to the (management) problems which I've been describing for at least two years (and some more). I've tried to convince people reading this list that some management mistakes (IMHO) were made; and I showed how I'd do actual work to try and fix them. After the "Commons RNG" experience, I'm even more convinced (and waiting for you to prove otherwise) that _some_ of the CM codes deserve their own components. [From here we get back to the initial post of this thread...] The rest of CM should certainly be modularized (at some point), but it should also be fixed (at some point), and this will take a lot of time because CM is such a mixed bag of implementation designs, pending bugs, dangling refactorings, outdated syntax, etc. IMO, prioritizing that work is the job of an active PMC. In order to continue RERO'ing "math"-related code, we must create new components. I thought that "Commons RNG" had made that obvious. [It does seem that some of the PMC members had now become more accepting of this view.] Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Le 31/08/2017 à 23:33, Gilles a écrit : > it's a pity we cannot meet in person to sort all those issues Hum, maybe with a few beers you'll be easier to convince ;) > I'm not against you modularizing CM, I'm against me doing it > just because you "think" it's a better approach to the > (management) problems which I've been describing for at least > two years (and some more). I understand your point of view, you don't want to spent a lot of time modularizing CM, dealing with parts of the code you are not comfortable with and delaying the release of code you really care about. That's fair and I agree this shouldn't be forced upon you. The good news is you don't actually have to refactor *all* of CM as a multi-module project right now. Start with a mostly empty branch containing just a couple of modules you like and release them. And you progressively bring more modules after each release from the old CM branch. That's equivalent to the creation of multiple components (you cherry-pick the code that you want, and release it when ready), and you keep the lightweight management of a single component. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Thu, Aug 31, 2017 at 4:28 PM, Emmanuel Bourg wrote: > Le 31/08/2017 à 23:33, Gilles a écrit : > > > it's a pity we cannot meet in person to sort all those issues > > Hum, maybe with a few beers you'll be easier to convince ;) > > > > I'm not against you modularizing CM, I'm against me doing it > > just because you "think" it's a better approach to the > > (management) problems which I've been describing for at least > > two years (and some more). > I understand your point of view, you don't want to spent a lot of time > modularizing CM, dealing with parts of the code you are not comfortable > with and delaying the release of code you really care about. That's fair > and I agree this shouldn't be forced upon you. > > The good news is you don't actually have to refactor *all* of CM as a > multi-module project right now. Start with a mostly empty branch > containing just a couple of modules you like and release them. And you > progressively bring more modules after each release from the old CM > branch. That's equivalent to the creation of multiple components (you > cherry-pick the code that you want, and release it when ready), and you > keep the lightweight management of a single component. > That sounds like a nice iterative approach. Gary > > Emmanuel Bourg > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All][Math] New component: "Commons Geometry"?
So volunteers? Gary, Emmanuel, others?? are you up to doing this? On 08/31/2017 06:29 PM, Gary Gregory wrote: On Thu, Aug 31, 2017 at 4:28 PM, Emmanuel Bourg wrote: Le 31/08/2017 à 23:33, Gilles a écrit : it's a pity we cannot meet in person to sort all those issues Hum, maybe with a few beers you'll be easier to convince ;) I'm not against you modularizing CM, I'm against me doing it just because you "think" it's a better approach to the (management) problems which I've been describing for at least two years (and some more). I understand your point of view, you don't want to spent a lot of time modularizing CM, dealing with parts of the code you are not comfortable with and delaying the release of code you really care about. That's fair and I agree this shouldn't be forced upon you. The good news is you don't actually have to refactor *all* of CM as a multi-module project right now. Start with a mostly empty branch containing just a couple of modules you like and release them. And you progressively bring more modules after each release from the old CM branch. That's equivalent to the creation of multiple components (you cherry-pick the code that you want, and release it when ready), and you keep the lightweight management of a single component. That sounds like a nice iterative approach. Gary Emmanuel Bourg - 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
Re: [All][Math] New component: "Commons Geometry"?
On Thu, Aug 31, 2017 at 8:54 PM, Dave Brosius wrote: > So volunteers? Gary, Emmanuel, others?? are you up to doing this? > Not for a while for me. Working and moving. Gary > > > On 08/31/2017 06:29 PM, Gary Gregory wrote: > >> On Thu, Aug 31, 2017 at 4:28 PM, Emmanuel Bourg >> wrote: >> >> Le 31/08/2017 à 23:33, Gilles a écrit : >>> >>> it's a pity we cannot meet in person to sort all those issues >>> Hum, maybe with a few beers you'll be easier to convince ;) >>> >>> >>> I'm not against you modularizing CM, I'm against me doing it just because you "think" it's a better approach to the (management) problems which I've been describing for at least two years (and some more). >>> I understand your point of view, you don't want to spent a lot of time >>> modularizing CM, dealing with parts of the code you are not comfortable >>> with and delaying the release of code you really care about. That's fair >>> and I agree this shouldn't be forced upon you. >>> >>> The good news is you don't actually have to refactor *all* of CM as a >>> multi-module project right now. Start with a mostly empty branch >>> containing just a couple of modules you like and release them. And you >>> progressively bring more modules after each release from the old CM >>> branch. That's equivalent to the creation of multiple components (you >>> cherry-pick the code that you want, and release it when ready), and you >>> keep the lightweight management of a single component. >>> >>> That sounds like a nice iterative approach. >> >> Gary >> >> >> Emmanuel Bourg >>> >>> - >>> 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 > >
Re: [All][Math] New component: "Commons Geometry"?
Le 1/09/2017 à 04:54, Dave Brosius a écrit : > So volunteers? Gary, Emmanuel, others?? are you up to doing this? I can setup the initial branch, but I need at least Gilles' consent and an indication about the first modules he'd like to integrate. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Fri, 1 Sep 2017 00:28:19 +0200, Emmanuel Bourg wrote: Le 31/08/2017 à 23:33, Gilles a écrit : it's a pity we cannot meet in person to sort all those issues Hum, maybe with a few beers you'll be easier to convince ;) It would quite probably require a stronger beverage. I'm not against you modularizing CM, I'm against me doing it just because you "think" it's a better approach to the (management) problems which I've been describing for at least two years (and some more). I understand your point of view, you don't want to spent a lot of time modularizing CM, dealing with parts of the code you are not comfortable with and delaying the release of code you really care about. That's fair and I agree this shouldn't be forced upon you. There is some truth, but not all of it. For a long time, I'm viewing CM more from a maintainer's POV rather than from a user's POV. IOW, the "prioritizing" I was mentioning, in one of the suppressed parts of my preceding message, is not based on what I "really care about", but on how generally useful they are (hence my being convinced that those would be good "Commons" component candidates). The good news is you don't actually have to refactor *all* of CM as a multi-module project right now. Start with a mostly empty branch containing just a couple of modules you like and release them. And you progressively bring more modules after each release from the old CM branch. Does everyone agree with that? [I seem to recall having made such a proposal, and it was not deemed acceptable...] That's equivalent to the creation of multiple components (you cherry-pick the code that you want, and release it when ready), Because of "Commons" rules, it is not "equivalent": There was a long thread concluding that all modules must be released _together_, and with the same top-level package name and version number. It is very "maintainer(s)-unfriendly" because of the quite different subject matters that coexist in CM. and you keep the lightweight management of a single component. I think that the unspecified problem(s) which you refer to here are mostly alleviated with tools such as git and maven. The problems I referred to in the preceding paragraph can't be. [Proof is the management crisis that ultimately doomed CM.] Gilles Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Fri, 1 Sep 2017 09:44:36 +0200, Emmanuel Bourg wrote: Le 1/09/2017 à 04:54, Dave Brosius a écrit : So volunteers? Gary, Emmanuel, others?? are you up to doing this? I can setup the initial branch, but I need at least Gilles' consent and an indication about the first modules he'd like to integrate. Emmanuel Bourg I'm still biased toward my own view as the most promising approach (see other post). [It's so obvious to me that most of the management problems we've seen with CM simply could not exist with more focused components.] However, I can't dismiss that other approaches, even less optimal (IMHO), could work (at least for some time). Modularization will certainly be an improvement. But who sufficiently believes in that approach that they will do the actual work? [Those people should speak up and propose the plan.] Personally, I've tried to demonstrate something with "Commons RNG"; I must have failed, but I do not know what. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Hi Gang, I am new to this apache group. My two cents here for a first post. Finally jumping after reading the threads and sensing the frustration. . I have pretty good success in using Math commons 3.6 for financial derivatives, financial and economics analysis and etc. Using the 3.6 as my a base structure accepted by many I have code for Arima, Markov analysis, constrained regressions, Linear programming for bond and equity optimization and yes I do use the complex number for derivative pricing. http://pfadintegral.com/docs/Schmelzle2010%20Fourier%20Pricing.pdf In fact I am writing a wrapper around the math common to write a R-like struct...and it is going well. Adding new objects and routines is far easier than with R. With a bit of work there is a strong possibility of having an ass kicking java algorithmic program. Thus far it is so easy it is actually fun! While I have my own code for matrix algebra and optimization I thought joining the open source community would provide a steady growth in algorithmic possibilities. Do you really want a complete revamp? Yikes! Are there issues? Yes. But I would hate to see this group toss the baby out with the bathwater. There is some good stuff here and with some work you can have a darn good statistical optimization package for multiple disciplines. My suggestion keep the existing code and slowly migrate to a better structure through deprecation and enhancements Cheers to you all and keep up the good work, Bill On Fri, Sep 1, 2017 at 5:48 PM, Gilles wrote: > On Fri, 1 Sep 2017 09:44:36 +0200, Emmanuel Bourg wrote: > >> Le 1/09/2017 à 04:54, Dave Brosius a écrit : >> >>> So volunteers? Gary, Emmanuel, others?? are you up to doing this? >>> >> >> I can setup the initial branch, but I need at least Gilles' consent and >> an indication about the first modules he'd like to integrate. >> >> Emmanuel Bourg >> >> > I'm still biased toward my own view as the most promising > approach (see other post). [It's so obvious to me that most > of the management problems we've seen with CM simply could > not exist with more focused components.] > > However, I can't dismiss that other approaches, even less > optimal (IMHO), could work (at least for some time). > Modularization will certainly be an improvement. > But who sufficiently believes in that approach that they > will do the actual work? [Those people should speak up > and propose the plan.] > > Personally, I've tried to demonstrate something with > "Commons RNG"; I must have failed, but I do not know > what. > > Gilles > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All][Math] New component: "Commons Geometry"?
> On Sep 1, 2017, at 9:35 PM, Bill Igoe wrote: > > Hi Gang, > > I am new to this apache group. My two cents here for a first post. Finally > jumping after reading the threads and sensing the frustration. . I have > pretty good success in using Math commons 3.6 for financial derivatives, > financial and economics analysis and etc. Using the 3.6 as my a base > structure accepted by many I have code for Arima, Markov analysis, > constrained regressions, Linear programming for bond and equity > optimization and yes I do use the complex number for derivative pricing. > > http://pfadintegral.com/docs/Schmelzle2010%20Fourier%20Pricing.pdf > > In fact I am writing a wrapper around the math common to write a R-like > struct...and it is going well. Adding new objects and routines is far > easier than with R. With a bit of work there is a strong possibility of > having an ass kicking java algorithmic program. Thus far it is so easy it > is actually fun! > > While I have my own code for matrix algebra and optimization I thought > joining the open source community would provide a steady growth in > algorithmic possibilities. Do you really want a complete revamp? Yikes! > > > Are there issues? Yes. But I would hate to see this group toss the baby > out with the bathwater. There is some good stuff here and with some work > you can have a darn good statistical optimization package for multiple > disciplines. > > My suggestion keep the existing code and slowly migrate to a better > structure through deprecation and enhancements This generally feels like the right direction to me. That said we’ll (all of us who haven’t been in there, myself included) have to start actually putting time into [math]. -Rob > > Cheers to you all and keep up the good work, > > Bill > > > On Fri, Sep 1, 2017 at 5:48 PM, Gilles wrote: > >> On Fri, 1 Sep 2017 09:44:36 +0200, Emmanuel Bourg wrote: >> >>> Le 1/09/2017 à 04:54, Dave Brosius a écrit : >>> So volunteers? Gary, Emmanuel, others?? are you up to doing this? >>> >>> I can setup the initial branch, but I need at least Gilles' consent and >>> an indication about the first modules he'd like to integrate. >>> >>> Emmanuel Bourg >>> >>> >> I'm still biased toward my own view as the most promising >> approach (see other post). [It's so obvious to me that most >> of the management problems we've seen with CM simply could >> not exist with more focused components.] >> >> However, I can't dismiss that other approaches, even less >> optimal (IMHO), could work (at least for some time). >> Modularization will certainly be an improvement. >> But who sufficiently believes in that approach that they >> will do the actual work? [Those people should speak up >> and propose the plan.] >> >> Personally, I've tried to demonstrate something with >> "Commons RNG"; I must have failed, but I do not know >> what. >> >> Gilles >> >> >> >> - >> 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
Re: [All][Math] New component: "Commons Geometry"?
Le 2/09/2017 à 00:50, Gilles a écrit : > Because of "Commons" rules, it is not "equivalent": There was > a long thread concluding that all modules must be released > _together_, and with the same top-level package name and version > number. True, but I don't see this as an issue. > I think that the unspecified problem(s) which you refer to > here are mostly alleviated with tools such as git and maven. I mentioned the problems in a previous message in this thread. Managing the releases, the JIRA configurations, maintaining the sites... many tasks can't be automated with tools, that's why I referred to the multi-modules solution as "lightweight" compared to multiple components. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Hi. On Mon, 4 Sep 2017 11:41:55 +0200, Emmanuel Bourg wrote: Le 2/09/2017 à 00:50, Gilles a écrit : Because of "Commons" rules, it is not "equivalent": There was a long thread concluding that all modules must be released _together_, and with the same top-level package name and version number. True, but I don't see this as an issue. I see it as a fundamental one: Why should codes unrelated by scope be artificially tied together by management rules (such as design, supported language version, release schedule, etc.)?[1] I think that the unspecified problem(s) which you refer to here are mostly alleviated with tools such as git and maven. I mentioned the problems in a previous message in this thread. Managing the releases, the JIRA configurations, maintaining the sites... many tasks can't be automated with tools, that's why I referred to the multi-modules solution as "lightweight" compared to multiple components. That's how much our mileages vary; IMO, all those are mild nuisances: the site is changed very rarely, JIRA configuration is done once[2], but managing the releases becomes irremediably difficult only when the scope of the component was not defined correctly.[3] Why do you "prefer" multi-module, independently of the subject matters being talked about? Please comment on my suggestion to create a single maven project for the whole of "Commons". I'd agree that this suggestion is ridiculous; yet some of you do the same proposal for "everything math-related". If you had been contributing to the math codes (plural), you perhaps would have understood that it creates more management problems than it solves.[4] The former CM core team did not want to see nor even discuss that aspect of development because there was a fairly strict segregation between the various functionalities where each one had a "master" (usually the initial contributor/committer) who was informally weighing more when it came to modifying "his" code.[5] Again, I have to stress on what happened that led me to propose a new "Commons RNG": obvious improvements to the CM code base were outrightly rejected based on demonstrably false statements; i.e. the objections were not technical but for the convenience of one user. Do you think that I enjoy contradicting you on these matters? These discussions are a net loss of goodwill that would be better used in creating useful codes. My point is that I'm arguing on what has really happened, while you still seem to deny that anything actually happened. Again, please do what you want with modularizing CM and release and support the code that will be the result. My "strategic" (!) plan has been clearly stated: 1. "Commons Numbers",[6] then 2. "Commons Geometry", then 3. "Commons Math (legacy) v4.0 * modularized if people want to work on it, and * without "unsupported" if allowed by the PMC Does the majority of the PMC sees that proposal as a constructive one? Do some developers want to contribute time to implement (parts of) that plan? Do they want to implement another plan? What plan? Without answering these simple questions, I think that we'd keep going in circles. Gilles Emmanuel Bourg [1] The rules are sensible once the scope has been determined based on the desire of the implementing team, not the other way around. [2] And I never got the impression that we were creating too much work for INFRA (how many new components per year do we ask for?). [3] As it has become of Common Math: the more it grew, the more it was likely that not all contributors could agree on a path forward, so that the majority "consensus" was on staying put; which, in turn, put off contributors who wanted to keep in sync with the language evolution. [4] The fork is an actual proof of that. [5] I don't deny that this can make sense since that person is likely the most knowledgeable in that domain. But it becomes a liability when the best design decisions are _not_ the same for the different functionalities. Modules are not an answer to this sort of problem. [6] Followed by "Commons SigProc" (contributor's involvement pending) since it depends on the "complex numbers". - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Le 4/09/2017 à 15:30, Gilles a écrit : > I see it as a fundamental one: Why should codes unrelated > by scope be artificially tied together by management rules > (such as design, supported language version, release schedule, > etc.)?[1] Because they share the same general scope of being math related. The design and the supported language version can be different for each module. > Why do you "prefer" multi-module, independently of the subject > matters being talked about? I already explained twice in this thread. > Please comment on my suggestion to create a single maven project > for the whole of "Commons". I'd agree that this suggestion is > ridiculous; yet some of you do the same proposal for "everything > math-related". If you want to use an absurd proposal to prove your point let me try that game too: Please comment on my suggestion to create multiple components out of every Java package defined in the Commons components. > If you had been contributing to the math codes (plural), you > perhaps would have understood that it creates more management > problems than it solves.[4] Please use foot references for external links only, your messages are unreadable if we have to go back and forth to understand them. > Again, I have to stress on what happened that led me to propose > a new "Commons RNG": obvious improvements to the CM code base > were outrightly rejected based on demonstrably false statements; > i.e. the objections were not technical but for the convenience > of one user. I still think that splitting RNG into its own component was a good move. I'm less happy with Numbers, I'd have preferred a module from a renovated "CM5" project started from scratch as I'm suggesting now for Geometry. > Do you think that I enjoy contradicting you on these matters? I'm starting to think that you enjoy rhetoric, probably more than seeking compromise unfortunately. > Do they want to implement another plan? What plan? Here is my counter-proposal: 1. Refactor Commons Math as a multi-module project, bump to version 5 2. Create two modules: geometry and legacy 3. Release Commons Math 5, without the legacy module 4. Spin-off new modules from the legacy module when needed And I'm willing to help at least for the steps 1 and 2. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
I know I haven't been around lately, but I this exchange caught my eye. I was trying to figure out a way to balance the issues, first, that there is resistance to creating a large number of projects spun out from CM and second, that there is a practical limit to how large a project can be maintained with the current resources. What I came up with is as follows: suppose we take CM and split it up into a number of modules. Then within the project we treat each module independently for the purposes of maintenance, release etc. So that if the geometry module is ready to cut a new release it may do so without being held up by issues in the other modules. So, how to accomplish this and still have CM appear to be and behave like one project? Each module would have it's own development branch. In the master branch would be a copy of the last released version of each module. Development happens in the development branch. When a module is ready to release, it merges into the master branch, bumps the version and releases the whole thing (i.e. all of CM). So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module and 4.2.8 of the geometry module. The geometry module is ready to make a new release, so it merges into master and bumps CM to 4.3.6 and geometry to 4.2.9. The linear algebra module stays at 4.1.7. So CM 4.3.6 is the same as 4.3.5 except for the geometry module, which is now at 4.2.9. While working this out I took a stab at splitting CM into modules. I ran into issues with the stats & distribution packages as many of the tests for other classes depend on them. So there's some work there to detangle some of the packages. But I was able to split out geometry, transform, optimizers, filter, diffeq and machine learning without a lot of trouble. See https://github.com/RayDeCampo/commons-math/tree/modules if you are interested. On Tue, Sep 5, 2017 at 8:33 AM, Emmanuel Bourg wrote: > Le 4/09/2017 à 15:30, Gilles a écrit : > > > I see it as a fundamental one: Why should codes unrelated > > by scope be artificially tied together by management rules > > (such as design, supported language version, release schedule, > > etc.)?[1] > > Because they share the same general scope of being math related. The > design and the supported language version can be different for each module. > > > > Why do you "prefer" multi-module, independently of the subject > > matters being talked about? > > I already explained twice in this thread. > > > > Please comment on my suggestion to create a single maven project > > for the whole of "Commons". I'd agree that this suggestion is > > ridiculous; yet some of you do the same proposal for "everything > > math-related". > > If you want to use an absurd proposal to prove your point let me try > that game too: Please comment on my suggestion to create multiple > components out of every Java package defined in the Commons components. > > > > If you had been contributing to the math codes (plural), you > > perhaps would have understood that it creates more management > > problems than it solves.[4] > > Please use foot references for external links only, your messages are > unreadable if we have to go back and forth to understand them. > > > > Again, I have to stress on what happened that led me to propose > > a new "Commons RNG": obvious improvements to the CM code base > > were outrightly rejected based on demonstrably false statements; > > i.e. the objections were not technical but for the convenience > > of one user. > > I still think that splitting RNG into its own component was a good move. > I'm less happy with Numbers, I'd have preferred a module from a > renovated "CM5" project started from scratch as I'm suggesting now for > Geometry. > > > > Do you think that I enjoy contradicting you on these matters? > > I'm starting to think that you enjoy rhetoric, probably more than > seeking compromise unfortunately. > > > > Do they want to implement another plan? What plan? > > Here is my counter-proposal: > > 1. Refactor Commons Math as a multi-module project, bump to version 5 > 2. Create two modules: geometry and legacy > 3. Release Commons Math 5, without the legacy module > 4. Spin-off new modules from the legacy module when needed > > And I'm willing to help at least for the steps 1 and 2. > > Emmanuel Bourg > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All][Math] New component: "Commons Geometry"?
I'm another Commons developer who: * Hasn't been "present" lately * Has no special mathematical background * Desires consensus * Repeatedly reads these exchanges in a state of vacillation between sympathy for Gilles's situation and suspicion that his communication style is too abrasive. Ultimately, I get that you're frustrated. I too have felt all along that Maven modules would be an acceptable approach wrt CM, but my view (in which I am seemingly not alone) of that set of code as "alike" simply because it relates to mathematics is, as I imply above, very likely rooted in ignorance. At the same time, the field of software development is only hoped to become more accessible by those with decreasing amounts of formal education, so perhaps it is fair that the line be drawn in the interest of the mathematical outsider. Even I have a reasonable understanding of basic geometry and can appreciate that there may be more situations in which its use would be "common." On the other hand, it still clearly feels like I would expect to find that among "math" code. As Ray has pointed out, there is no *technical* reason a Maven project's submodules must have synchronized release schedule or version numbers. It would seem to me that his approach, perhaps accounting for the notion of the "legacy" submodule, while undeniably increasing complexity of management to some extent, still seems the most likely way forward to give all parties *enough* satisfaction. We are developers: we should be able to create tooling, e.g. in Jenkins or elsewhere, that could help manage the coordination of version numbers between parent and children. In any case, Gilles's statement that geometry represents the outer edge of his vision for CM expansion means that this discussion needed to take place soon anyway; the only remaining decisions should IMO be 1) whether geometry belongs with CM5, and 2) whether numbers should be reabsorbed into such a CM5 structure. Matt On Sep 10, 2017 11:35, "Raymond DeCampo" wrote: I know I haven't been around lately, but I this exchange caught my eye. I was trying to figure out a way to balance the issues, first, that there is resistance to creating a large number of projects spun out from CM and second, that there is a practical limit to how large a project can be maintained with the current resources. What I came up with is as follows: suppose we take CM and split it up into a number of modules. Then within the project we treat each module independently for the purposes of maintenance, release etc. So that if the geometry module is ready to cut a new release it may do so without being held up by issues in the other modules. So, how to accomplish this and still have CM appear to be and behave like one project? Each module would have it's own development branch. In the master branch would be a copy of the last released version of each module. Development happens in the development branch. When a module is ready to release, it merges into the master branch, bumps the version and releases the whole thing (i.e. all of CM). So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module and 4.2.8 of the geometry module. The geometry module is ready to make a new release, so it merges into master and bumps CM to 4.3.6 and geometry to 4.2.9. The linear algebra module stays at 4.1.7. So CM 4.3.6 is the same as 4.3.5 except for the geometry module, which is now at 4.2.9. While working this out I took a stab at splitting CM into modules. I ran into issues with the stats & distribution packages as many of the tests for other classes depend on them. So there's some work there to detangle some of the packages. But I was able to split out geometry, transform, optimizers, filter, diffeq and machine learning without a lot of trouble. See https://github.com/RayDeCampo/commons-math/tree/modules if you are interested. On Tue, Sep 5, 2017 at 8:33 AM, Emmanuel Bourg wrote: > Le 4/09/2017 à 15:30, Gilles a écrit : > > > I see it as a fundamental one: Why should codes unrelated > > by scope be artificially tied together by management rules > > (such as design, supported language version, release schedule, > > etc.)?[1] > > Because they share the same general scope of being math related. The > design and the supported language version can be different for each module. > > > > Why do you "prefer" multi-module, independently of the subject > > matters being talked about? > > I already explained twice in this thread. > > > > Please comment on my suggestion to create a single maven project > > for the whole of "Commons". I'd agree that this suggestion is > > ridiculous; yet some of you do the same proposal for "everything > > math-related". > > If you want to use an absurd proposal to prove your point let me try > that game too: Please comment on my suggestion to create multiple > components out of every Java package defined in the Commons components. > > > > If you had been contributing to the math code
Re: [All][Math] New component: "Commons Geometry"?
On Tue, 5 Sep 2017 14:33:55 +0200, Emmanuel Bourg wrote: Le 4/09/2017 à 15:30, Gilles a écrit : I see it as a fundamental one: Why should codes unrelated by scope be artificially tied together by management rules (such as design, supported language version, release schedule, etc.)?[1] Because they share the same general scope of being math related. This is what CM was about, and it did not work out well. Been there, done that. The design and the supported language version can be different for each module. Which project would start on the premises of a non-uniform design among its modules? It makes sense if the projects are different and can be supported by different teams (even if there can be overlaps of course). Why do you "prefer" multi-module, independently of the subject matters being talked about? I already explained twice in this thread. You did not because you left out the _why_ you don't agree that "Mathematics" is too broad a scope for a programming project. At least a project which we could handle here at "Commons" (being a home for small, focused, components). CM was proven not to be a viable component for "Commons" in several ways: some decided to leave "Commons", some proposed to adapt our expectations to match the "Commons" eco-system (code-wise and community-wise, as I've explained in more than one way). A few others still insist that what led to much disappointment should be pursued. Same cause, same consequences. Please comment on my suggestion to create a single maven project for the whole of "Commons". I'd agree that this suggestion is ridiculous; yet some of you do the same proposal for "everything math-related". If you want to use an absurd proposal to prove your point let me try that game too: Please comment on my suggestion to create multiple components out of every Java package defined in the Commons components. You, not me, are advocating for an absurd proposal whose logical consequence would allow including the whole of mathematics in a single maven project. I start from the subject matter in order to define scope. This has nothing to do with what you are presenting here (which is indeed absurd too). If you had been contributing to the math codes (plural), you perhaps would have understood that it creates more management problems than it solves.[4] Please use foot references for external links only, your messages are unreadable if we have to go back and forth to understand them. Again, I have to stress on what happened that led me to propose a new "Commons RNG": obvious improvements to the CM code base were outrightly rejected based on demonstrably false statements; i.e. the objections were not technical but for the convenience of one user. I still think that splitting RNG into its own component was a good move. I'm less happy with Numbers, I'd have preferred a module from a renovated "CM5" project started from scratch as I'm suggesting now for Geometry. Good for "RNG", bad for "Numbers"... Where is the logic? Even so, how long did it take the PMC to see that "Commons RNG" was a good move? If "Commons RNG" was a good move, you could have the minimal trust that maybe, just maybe, I might be right with a quite limited set of similar suggestions resulted from an identical reasoning. Do you think that I enjoy contradicting you on these matters? I'm starting to think that you enjoy rhetoric, I'm not. But you seem on to try and blur my true position, with undertones that I'd be more "talking" than "doing". All evidences are there: the ML archives, the bugs, the fork, the new components (released and in-progress). But you look only at a couple of "mechanical" advantages of having N-1 components rather than N. probably more than seeking compromise unfortunately. And this accusation, yet again. :-/ Surely you do not have a clear memory of more than 10 years of day-to-day CM development; I did compromise on very wrong (IMO) decisions. And I have taken more than my share implementing some of those wrong decisions, trusting that the others would do their part. Did you notice the result? Errare humanum est, perseverare diabolicum. Do they want to implement another plan? What plan? Here is my counter-proposal: 1. Refactor Commons Math as a multi-module project, bump to version 5 2. Create two modules: geometry and legacy 3. Release Commons Math 5, without the legacy module 4. Spin-off new modules from the legacy module when needed And I'm willing to help at least for the steps 1 and 2. I'm not sure I understand your intended level of implication. [Changing the directory structure of the repository is the trivial part of the process. Stopping there is like shoving dust under carpet to pretend that the floor is clean.] I propose that "Commons Numbers" and "Commons Geometry" be components (with their own set of modules); and, from the rest of CM code, we'd have 1. easy "module" candidates like: o.a.c.m.distribution (uni
Re: [All][Math] New component: "Commons Geometry"?
On Sun, 10 Sep 2017 12:35:17 -0400, Raymond DeCampo wrote: I know I haven't been around lately, but I this exchange caught my eye. I was trying to figure out a way to balance the issues, first, that there is resistance to creating a large number of projects spun out from CM Depending on what is being counted (released, approved by contributors, approved by PMC), "large" would qualify a quantity that varies between 2 and 5. [The supposed amount of added work has been long dwarfed by endless arguing that amounts to discouraging any further work on CM code.] So the "resistance" argues on a baseless fear. and second, that there is a practical limit to how large a project can be maintained with the current resources. That is a fact, proved by the last two years of (in)activity on CM. What I came up with is as follows: suppose we take CM and split it up into a number of modules. Then within the project we treat each module independently for the purposes of maintenance, release etc. So that if the geometry module is ready to cut a new release it may do so without being held up by issues in the other modules. So, how to accomplish this and still have CM appear to be and behave like one project? Each module would have it's own development branch. In the master branch would be a copy of the last released version of each module. Development happens in the development branch. When a module is ready to release, it merges into the master branch, bumps the version and releases the whole thing (i.e. all of CM). So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module and 4.2.8 of the geometry module. The geometry module is ready to make a new release, so it merges into master and bumps CM to 4.3.6 and geometry to 4.2.9. The linear algebra module stays at 4.1.7. So CM 4.3.6 is the same as 4.3.5 except for the geometry module, which is now at 4.2.9. Please (re)read that thread (from 10 months ago): http://markmail.org/message/2674qemtl5vvrnum Is your proposal different? While working this out I took a stab at splitting CM into modules. I ran into issues with the stats & distribution packages as many of the tests for other classes depend on them. So there's some work there to detangle some of the packages. But I was able to split out geometry, transform, optimizers, filter, diffeq and machine learning without a lot of trouble. See https://github.com/RayDeCampo/commons-math/tree/modules if you are interested. This pretty much agrees with my observations (and analyses thereof), presented here several times, last installment of which was: http://markmail.org/message/rzvh3esin3neffqs Regards, Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Mon, Sep 11, 2017 at 1:20 PM, Gilles wrote: > On Sun, 10 Sep 2017 12:35:17 -0400, Raymond DeCampo wrote: > >> I know I haven't been around lately, but I this exchange caught my eye. >> >> I was trying to figure out a way to balance the issues, first, that there >> is resistance to creating a large number of projects spun out from CM >> > What I came up with is as follows: suppose we take CM and split it up into >> a number of modules. Then within the project we treat each module >> independently for the purposes of maintenance, release etc. So that if >> the >> geometry module is ready to cut a new release it may do so without being >> held up by issues in the other modules. >> >> So, how to accomplish this and still have CM appear to be and behave like >> one project? Each module would have it's own development branch. In the >> master branch would be a copy of the last released version of each module. >> Development happens in the development branch. When a module is ready to >> release, it merges into the master branch, bumps the version and releases >> the whole thing (i.e. all of CM). >> >> So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module and >> 4.2.8 of the geometry module. The geometry module is ready to make a new >> release, so it merges into master and bumps CM to 4.3.6 and geometry to >> 4.2.9. The linear algebra module stays at 4.1.7. So CM 4.3.6 is the same >> as 4.3.5 except for the geometry module, which is now at 4.2.9. >> > > Please (re)read that thread (from 10 months ago): > http://markmail.org/message/2674qemtl5vvrnum > > Is your proposal different? One difference is that I proposed an overarching CM version, in the same way that, e.g. JEE X is comprised of many versions of smaller standards. However much of the discussion in that thread still applies. > > > While working this out I took a stab at splitting CM into modules. I ran >> into issues with the stats & distribution packages as many of the tests >> for >> other classes depend on them. So there's some work there to detangle some >> of the packages. But I was able to split out geometry, transform, >> optimizers, filter, diffeq and machine learning without a lot of trouble. >> See https://github.com/RayDeCampo/commons-math/tree/modules if you are >> interested. >> > > This pretty much agrees with my observations (and analyses > thereof), presented here several times, last installment of > which was: > http://markmail.org/message/rzvh3esin3neffqs Yes, I used your posts as a roadmap when splitting it up.
Re: [All][Math] New component: "Commons Geometry"?
On Sat, Sep 2, 2017 at 12:50 AM, Gilles wrote: > Because of "Commons" rules, it is not "equivalent": There was > a long thread concluding that all modules must be released > _together_, and with the same top-level package name and version > number. > It is very "maintainer(s)-unfriendly" because of the quite > different subject matters that coexist in CM. I wouldn't count that rule "*all* modules must be released" as a mantra: a) In case of an emergency release (fixing a CVE, for example), I'd clearly consider pushing out the module as more important than waiting for a full release. (Of course, one must be careful to maintain compatibility when pushing out just a module, but that goes without saying.) b) I'd like to hear others experiences on that topic (maybe VFS). Anyways, my personal experiences with Rat are clear: Releasing *all* together is causing nothing but pain, and tends to defer releases indefinitely. OTOH, releasing a submodule can be done at all times, and without overly much preparation. In conclusion, I'd definitely support the release of a single submodule, if the need would arise. 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Hi Jochen, Jochen Wiedmann wrote: > On Sat, Sep 2, 2017 at 12:50 AM, Gilles > wrote: > >> Because of "Commons" rules, it is not "equivalent": There was >> a long thread concluding that all modules must be released >> _together_, and with the same top-level package name and version >> number. >> It is very "maintainer(s)-unfriendly" because of the quite >> different subject matters that coexist in CM. > > I wouldn't count that rule "*all* modules must be released" as a mantra: > > a) In case of an emergency release (fixing a CVE, for example), I'd > clearly consider pushing out the module as more important than waiting > for a full release. (Of course, one must be careful to maintain > compatibility when pushing out just a module, but that goes without > saying.) > b) I'd like to hear others experiences on that topic (maybe VFS). > Anyways, my personal experiences with Rat are clear: Releasing *all* > together is causing nothing but pain, and tends to defer releases > indefinitely. OTOH, releasing a submodule can be done at all times, > and without overly much preparation. > > In conclusion, I'd definitely support the release of a single > submodule, if the need would arise. Just that our tooling does not support this: 1/ No proper support for release of a GIT subtree 2/ No proper support for such a site generation 3/ No proper support using the release plugin 4/ Parents of such a component will have their own release cycle ... - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote: On Sat, Sep 2, 2017 at 12:50 AM, Gilles wrote: Because of "Commons" rules, it is not "equivalent": There was a long thread concluding that all modules must be released _together_, and with the same top-level package name and version number. It is very "maintainer(s)-unfriendly" because of the quite different subject matters that coexist in CM. I wouldn't count that rule "*all* modules must be released" as a mantra: I found the idea attractive, but Stian (link to older discussion in a previous post) advised that maven would not easily "support" it. Has that changed since the discussion took place (10 months ago)? a) In case of an emergency release (fixing a CVE, for example), I'd clearly consider pushing out the module as more important than waiting for a full release. (Of course, one must be careful to maintain compatibility when pushing out just a module, but that goes without saying.) b) I'd like to hear others experiences on that topic (maybe VFS). Anyways, my personal experiences with Rat are clear: Releasing *all* together is causing nothing but pain, and tends to defer releases indefinitely. OTOH, releasing a submodule can be done at all times, and without overly much preparation. In conclusion, I'd definitely support the release of a single submodule, if the need would arise. How can one reconcile what you say here with what was said in that old thread? Would the PMC accept that a component contains independent modules (where "independent" means that each module can have its own version number, irrespective of the component's version)? Arguably (cf. thread referred to above), a "Commons" component should be simple enough that multiple versions are not necessary. [Chorus:] This is not the case with "Commons Math", hence separate components for independent contents (such as "Geometry", "RNG", "Numbers" and "SigProc") is the simplest solution. Gilles Jochen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Pardon me for pulling this thread up again, I havent read anything about "Commons Geometry" since long (or may be I missed any other disscussion? ). is someone working on this ? what is the final decision ? I'm having good amount of time to spend on this now, appreciate If someone direct me to correct disscussion thread I think I can help here. It took me half hour to read all old mails but dont see final verdict, though I was in favour with Maven modules but after reading all again I think Gilles approch is more practicle here and If no one is working I can submit something to review. Regards, Amey On Wed, Sep 13, 2017 at 4:44 AM, Gilles wrote: > On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote: > >> On Sat, Sep 2, 2017 at 12:50 AM, Gilles >> wrote: >> >> Because of "Commons" rules, it is not "equivalent": There was >>> a long thread concluding that all modules must be released >>> _together_, and with the same top-level package name and version >>> number. >>> It is very "maintainer(s)-unfriendly" because of the quite >>> different subject matters that coexist in CM. >>> >> >> I wouldn't count that rule "*all* modules must be released" as a mantra: >> > > I found the idea attractive, but Stian (link to older discussion > in a previous post) advised that maven would not easily "support" > it. > > Has that changed since the discussion took place (10 months ago)? > > a) In case of an emergency release (fixing a CVE, for example), I'd >> clearly consider pushing out the module as more important than waiting >> for a full release. (Of course, one must be careful to maintain >> compatibility when pushing out just a module, but that goes without >> saying.) >> b) I'd like to hear others experiences on that topic (maybe VFS). >> Anyways, my personal experiences with Rat are clear: Releasing *all* >> together is causing nothing but pain, and tends to defer releases >> indefinitely. OTOH, releasing a submodule can be done at all times, >> and without overly much preparation. >> >> In conclusion, I'd definitely support the release of a single >> submodule, if the need would arise. >> > > How can one reconcile what you say here with what was said in > that old thread? > > Would the PMC accept that a component contains independent modules > (where "independent" means that each module can have its own version > number, irrespective of the component's version)? > > Arguably (cf. thread referred to above), a "Commons" component > should be simple enough that multiple versions are not necessary. > [Chorus:] This is not the case with "Commons Math", hence separate > components for independent contents (such as "Geometry", "RNG", > "Numbers" and "SigProc") is the simplest solution. > > Gilles > > Jochen >> > > > - > 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
Re: [All][Math] New component: "Commons Geometry"?
Hello Amey.
On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
Pardon me for pulling this thread up again, I havent read anything
about
"Commons Geometry" since long
Thanks for your renewed interest.
(or may be I missed any other disscussion? ).
Probably not.
is someone working on this ?
It would be a surprise.
what is the final decision ?
There hasn't been any progress towards a decision.
There isn't even a consensus on one of the central tenets of
Apache ("Those who do the work..."): how sad/strange (?).
I'm having good
amount of time to spend on this now, appreciate If someone direct me
to
correct disscussion thread
IIRC, the one below is where we left off...
I think I can help here.
Thanks for the offer!
It took me half hour to read all old mails but dont see final
verdict,
though I was in favour with Maven modules but after reading all again
I
think Gilles approch is more practicle here and If no one is working
I can
submit something to review.
IMHO, the priority would be to review the status of "Numbers"
(i.e. what is preventing a first release?).
Best regards,
Gilles
Regards,
Amey
On Wed, Sep 13, 2017 at 4:44 AM, Gilles
wrote:
On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
On Sat, Sep 2, 2017 at 12:50 AM, Gilles
wrote:
Because of "Commons" rules, it is not "equivalent": There was
a long thread concluding that all modules must be released
_together_, and with the same top-level package name and version
number.
It is very "maintainer(s)-unfriendly" because of the quite
different subject matters that coexist in CM.
I wouldn't count that rule "*all* modules must be released" as a
mantra:
I found the idea attractive, but Stian (link to older discussion
in a previous post) advised that maven would not easily "support"
it.
Has that changed since the discussion took place (10 months ago)?
a) In case of an emergency release (fixing a CVE, for example), I'd
clearly consider pushing out the module as more important than
waiting
for a full release. (Of course, one must be careful to maintain
compatibility when pushing out just a module, but that goes without
saying.)
b) I'd like to hear others experiences on that topic (maybe VFS).
Anyways, my personal experiences with Rat are clear: Releasing
*all*
together is causing nothing but pain, and tends to defer releases
indefinitely. OTOH, releasing a submodule can be done at all times,
and without overly much preparation.
In conclusion, I'd definitely support the release of a single
submodule, if the need would arise.
How can one reconcile what you say here with what was said in
that old thread?
Would the PMC accept that a component contains independent modules
(where "independent" means that each module can have its own version
number, irrespective of the component's version)?
Arguably (cf. thread referred to above), a "Commons" component
should be simple enough that multiple versions are not necessary.
[Chorus:] This is not the case with "Commons Math", hence separate
components for independent contents (such as "Geometry", "RNG",
"Numbers" and "SigProc") is the simplest solution.
Gilles
Jochen
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Fri, Dec 1, 2017 at 6:56 PM, Gilles wrote:
> Hello Amey.
Hi Gilles,
>
>
> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>
>> Pardon me for pulling this thread up again, I havent read anything about
>> "Commons Geometry" since long
>>
>
> Thanks for your renewed interest.
>
> (or may be I missed any other disscussion? ).
>>
>
> Probably not.
>
> is someone working on this ?
>>
>
> It would be a surprise.
>
> what is the final decision ?
>>
>
> There hasn't been any progress towards a decision.
>
I'm not sure if "Lazy Consensus" works in these matters ? better take help
of it, its fast and easy.
> There isn't even a consensus on one of the central tenets of
> Apache ("Those who do the work..."): how sad/strange (?).
>
> I'm having good
>> amount of time to spend on this now, appreciate If someone direct me to
>> correct disscussion thread
>>
>
> IIRC, the one below is where we left off...
>
> I think I can help here.
>>
>
> Thanks for the offer!
>
> It took me half hour to read all old mails but dont see final verdict,
>> though I was in favour with Maven modules but after reading all again I
>> think Gilles approch is more practicle here and If no one is working I can
>> submit something to review.
>>
>
> IMHO, the priority would be to review the status of "Numbers"
> (i.e. what is preventing a first release?).
>
Ok, If commons number is priority let me check that first, I will chime in
here after that release.
last numbers release I see on 22/4/17, and total open jiras are 18, what
are min expectation here ?
I will open another thread If want advise., let this thread alive for
o.a.c.geometry.
Regards,
Amey
> Best regards,
> Gilles
>
>
>
> Regards,
>> Amey
>>
>> On Wed, Sep 13, 2017 at 4:44 AM, Gilles
>> wrote:
>>
>> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
>>>
>>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles
wrote:
Because of "Commons" rules, it is not "equivalent": There was
> a long thread concluding that all modules must be released
> _together_, and with the same top-level package name and version
> number.
> It is very "maintainer(s)-unfriendly" because of the quite
> different subject matters that coexist in CM.
>
>
I wouldn't count that rule "*all* modules must be released" as a mantra:
>>> I found the idea attractive, but Stian (link to older discussion
>>> in a previous post) advised that maven would not easily "support"
>>> it.
>>>
>>> Has that changed since the discussion took place (10 months ago)?
>>>
>>> a) In case of an emergency release (fixing a CVE, for example), I'd
>>>
clearly consider pushing out the module as more important than waiting
for a full release. (Of course, one must be careful to maintain
compatibility when pushing out just a module, but that goes without
saying.)
b) I'd like to hear others experiences on that topic (maybe VFS).
Anyways, my personal experiences with Rat are clear: Releasing *all*
together is causing nothing but pain, and tends to defer releases
indefinitely. OTOH, releasing a submodule can be done at all times,
and without overly much preparation.
In conclusion, I'd definitely support the release of a single
submodule, if the need would arise.
>>> How can one reconcile what you say here with what was said in
>>> that old thread?
>>>
>>> Would the PMC accept that a component contains independent modules
>>> (where "independent" means that each module can have its own version
>>> number, irrespective of the component's version)?
>>>
>>> Arguably (cf. thread referred to above), a "Commons" component
>>> should be simple enough that multiple versions are not necessary.
>>> [Chorus:] This is not the case with "Commons Math", hence separate
>>> components for independent contents (such as "Geometry", "RNG",
>>> "Numbers" and "SigProc") is the simplest solution.
>>>
>>> Gilles
>>>
>>> Jochen
>>>
>
> -
> 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
Re: [All][Math] New component: "Commons Geometry"?
On Fri, Dec 1, 2017 at 7:23 PM, Amey Jadiye wrote:
>
>
> On Fri, Dec 1, 2017 at 6:56 PM, Gilles
> wrote:
>
>> Hello Amey.
>
>
> Hi Gilles,
>
>>
>>
>> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>>
>>> Pardon me for pulling this thread up again, I havent read anything about
>>> "Commons Geometry" since long
>>>
>>
>> Thanks for your renewed interest.
>>
>> (or may be I missed any other disscussion? ).
>>>
>>
>> Probably not.
>>
>> is someone working on this ?
>>>
>>
>> It would be a surprise.
>>
>> what is the final decision ?
>>>
>>
>> There hasn't been any progress towards a decision.
>>
>
> I'm not sure if "Lazy Consensus" works in these matters ? better take help
> of it, its fast and easy.
>
>
>> There isn't even a consensus on one of the central tenets of
>> Apache ("Those who do the work..."): how sad/strange (?).
>>
>> I'm having good
>>> amount of time to spend on this now, appreciate If someone direct me to
>>> correct disscussion thread
>>>
>>
>> IIRC, the one below is where we left off...
>>
>> I think I can help here.
>>>
>>
>> Thanks for the offer!
>>
>> It took me half hour to read all old mails but dont see final verdict,
>>> though I was in favour with Maven modules but after reading all again I
>>> think Gilles approch is more practicle here and If no one is working I
>>> can
>>> submit something to review.
>>>
>>
>> IMHO, the priority would be to review the status of "Numbers"
>> (i.e. what is preventing a first release?).
>>
>
> Ok, If commons number is priority let me check that first, I will chime in
> here after that release.
> last numbers release I see on 22/4/17,
>
apologies, that date belongs to site publish and SNAPSHOT, not the alpha
release.
and total open jiras are 18, what are min expectation here ?
> I will open another thread If want advise., let this thread alive for
> o.a.c.geometry.
>
> Regards,
> Amey
>
>
>> Best regards,
>> Gilles
>>
>>
>>
>> Regards,
>>> Amey
>>>
>>> On Wed, Sep 13, 2017 at 4:44 AM, Gilles
>>> wrote:
>>>
>>> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
On Sat, Sep 2, 2017 at 12:50 AM, Gilles
> wrote:
>
> Because of "Commons" rules, it is not "equivalent": There was
>
>> a long thread concluding that all modules must be released
>> _together_, and with the same top-level package name and version
>> number.
>> It is very "maintainer(s)-unfriendly" because of the quite
>> different subject matters that coexist in CM.
>>
>>
> I wouldn't count that rule "*all* modules must be released" as a
> mantra:
>
>
I found the idea attractive, but Stian (link to older discussion
in a previous post) advised that maven would not easily "support"
it.
Has that changed since the discussion took place (10 months ago)?
a) In case of an emergency release (fixing a CVE, for example), I'd
> clearly consider pushing out the module as more important than waiting
> for a full release. (Of course, one must be careful to maintain
> compatibility when pushing out just a module, but that goes without
> saying.)
> b) I'd like to hear others experiences on that topic (maybe VFS).
> Anyways, my personal experiences with Rat are clear: Releasing *all*
> together is causing nothing but pain, and tends to defer releases
> indefinitely. OTOH, releasing a submodule can be done at all times,
> and without overly much preparation.
>
> In conclusion, I'd definitely support the release of a single
> submodule, if the need would arise.
>
>
How can one reconcile what you say here with what was said in
that old thread?
Would the PMC accept that a component contains independent modules
(where "independent" means that each module can have its own version
number, irrespective of the component's version)?
Arguably (cf. thread referred to above), a "Commons" component
should be simple enough that multiple versions are not necessary.
[Chorus:] This is not the case with "Commons Math", hence separate
components for independent contents (such as "Geometry", "RNG",
"Numbers" and "SigProc") is the simplest solution.
Gilles
Jochen
>
>
>>
>> -
>> 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
Re: [All][Math] New component: "Commons Geometry"?
On Fri, 1 Dec 2017 19:23:57 +0530, Amey Jadiye wrote: On Fri, Dec 1, 2017 at 6:56 PM, Gilles wrote: Hello Amey. Hi Gilles, On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote: Pardon me for pulling this thread up again, I havent read anything about "Commons Geometry" since long Thanks for your renewed interest. (or may be I missed any other disscussion? ). Probably not. is someone working on this ? It would be a surprise. what is the final decision ? There hasn't been any progress towards a decision. I'm not sure if "Lazy Consensus" works in these matters ? better take help of it, its fast and easy. By definition, it does not apply when people voice their opinion: Some did it one way, others did it in another (non-compatible way). The strange thing here is that some PMC members seem to prefer moving Commons Math to "dormant" rather than let the few remaining active developers do some cleanup in the hope to revivify some of the code base in a more modern Java eco-system. Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Has the PMC and the active developers met over a video call to try and hash this out? It would be a shame to see this library fall into disuse. I'd also argue with Jigsaw being the heart of Java 9+ that more modular libs now make sense. Cheers, Martijn On 1 December 2017 at 14:56, Gilles wrote: > On Fri, 1 Dec 2017 19:23:57 +0530, Amey Jadiye wrote: > >> On Fri, Dec 1, 2017 at 6:56 PM, Gilles >> wrote: >> >> Hello Amey. >>> >> >> >> Hi Gilles, >> >> >>> >>> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote: >>> >>> Pardon me for pulling this thread up again, I havent read anything about "Commons Geometry" since long >>> Thanks for your renewed interest. >>> >>> (or may be I missed any other disscussion? ). >>> >>> Probably not. >>> >>> is someone working on this ? >>> >>> It would be a surprise. >>> >>> what is the final decision ? >>> >>> There hasn't been any progress towards a decision. >>> >>> >> I'm not sure if "Lazy Consensus" works in these matters ? better take help >> of it, its fast and easy. >> > > By definition, it does not apply when people voice their opinion: > Some did it one way, others did it in another (non-compatible way). > > The strange thing here is that some PMC members seem to prefer > moving Commons Math to "dormant" rather than let the few remaining > active developers do some cleanup in the hope to revivify some of > the code base in a more modern Java eco-system. > > Gilles > > [...] >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All][Math] New component: "Commons Geometry"?
Hi. On Sat, 2 Dec 2017 20:40:38 +, Martijn Verburg wrote: Has the PMC and the active developers met over a video call to try and hash this out? The ML archive is replete with discussions. A few PMC members voiced their agreement with the Apache mantra. A few oppose trying an approach that would break the status quo, even as it has stalled development (the next major release is nowhere in sight, almost 3 years after work started on it). It would be a shame to see this library fall into disuse. The library can be used but is virtually unmaintained. IMO, the question is why the loss of continuity is being preferred over a proposal that costs only to those who are willing to put work in it. The asymmetry of the situation should be obvious... I'd also argue with Jigsaw being the heart of Java 9+ that more modular libs now make sense. +1 to a separation of concerns that allows for clear and independent lines of development. Regards, Gilles Cheers, Martijn On 1 December 2017 at 14:56, Gilles wrote: On Fri, 1 Dec 2017 19:23:57 +0530, Amey Jadiye wrote: On Fri, Dec 1, 2017 at 6:56 PM, Gilles wrote: Hello Amey. Hi Gilles, On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote: Pardon me for pulling this thread up again, I havent read anything about "Commons Geometry" since long Thanks for your renewed interest. (or may be I missed any other disscussion? ). Probably not. is someone working on this ? It would be a surprise. what is the final decision ? There hasn't been any progress towards a decision. I'm not sure if "Lazy Consensus" works in these matters ? better take help of it, its fast and easy. By definition, it does not apply when people voice their opinion: Some did it one way, others did it in another (non-compatible way). The strange thing here is that some PMC members seem to prefer moving Commons Math to "dormant" rather than let the few remaining active developers do some cleanup in the hope to revivify some of the code base in a more modern Java eco-system. Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Fri, Dec 1, 2017 at 2:26 PM, Gilles wrote:
> There hasn't been any progress towards a decision.
> There isn't even a consensus on one of the central tenets of
> Apache ("Those who do the work..."): how sad/strange (?).
Those who do the work are welcome to decide on their own, if they do
not involve others. Establishing a new commons component doesn't
qualify, IMO.
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
On Fri, Dec 1, 2017 at 2:26 PM, Gilles
wrote:
There hasn't been any progress towards a decision.
There isn't even a consensus on one of the central tenets of
Apache ("Those who do the work..."): how sad/strange (?).
Those who do the work are welcome to decide on their own, if they do
not involve others.
The conditional is not part of the well-known mantra.
The issue here is to answer the question of what to do with
a non-trivial code base. My stance is to try and fix the
problem(s), a.o. difficult management, by rooting out its
main cause: CM has become an aggregate of components with
completely different subject matters, scopes, designs,
efficiencies, provisions for extension, etc.
[An array of issues which "maven" modules will not solve.]
We are seemingly faced with a choice between:
1. Maintain CM as the huge library that it is now.
2. Incrementally create maintainable components.
A long time has passed since these alternatives were first
exposed, only proving that none of the people who informally
chose option(1) invested work to make it a reality.
Refusing option (2) not only "involves others"; it is harming
them (very real people, having done a lot of work here, on
that code base).
Establishing a new commons component doesn't
qualify, IMO.
True; that's why we are stalled, despite that a majority
of the PMC did not explicitly oppose option (2).
A handful of PMC people prefer to let the code base become
"dormant" rather than give any chance to an alternate view.
[If, say, you looked at the "Commons RNG" project, and
concluded that, decidedly, this is not how a component
should look like, then I could perhaps fathom out where
those reservations come from.]
Gilles
Jochen
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Can this project be forked to a new domain over on GitHub (under the
existing Apache license), split up and then continued in that case?
Cheers,
Martijn
On 3 December 2017 at 11:51, Gilles wrote:
> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
>
>> On Fri, Dec 1, 2017 at 2:26 PM, Gilles
>> wrote:
>>
>> There hasn't been any progress towards a decision.
>>> There isn't even a consensus on one of the central tenets of
>>> Apache ("Those who do the work..."): how sad/strange (?).
>>>
>>
>> Those who do the work are welcome to decide on their own, if they do
>> not involve others.
>>
>
> The conditional is not part of the well-known mantra.
>
> The issue here is to answer the question of what to do with
> a non-trivial code base. My stance is to try and fix the
> problem(s), a.o. difficult management, by rooting out its
> main cause: CM has become an aggregate of components with
> completely different subject matters, scopes, designs,
> efficiencies, provisions for extension, etc.
> [An array of issues which "maven" modules will not solve.]
>
> We are seemingly faced with a choice between:
> 1. Maintain CM as the huge library that it is now.
> 2. Incrementally create maintainable components.
>
> A long time has passed since these alternatives were first
> exposed, only proving that none of the people who informally
> chose option(1) invested work to make it a reality.
>
> Refusing option (2) not only "involves others"; it is harming
> them (very real people, having done a lot of work here, on
> that code base).
>
> Establishing a new commons component doesn't
>> qualify, IMO.
>>
>
> True; that's why we are stalled, despite that a majority
> of the PMC did not explicitly oppose option (2).
>
> A handful of PMC people prefer to let the code base become
> "dormant" rather than give any chance to an alternate view.
> [If, say, you looked at the "Commons RNG" project, and
> concluded that, decidedly, this is not how a component
> should look like, then I could perhaps fathom out where
> those reservations come from.]
>
> Gilles
>
>
>> Jochen
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [All][Math] New component: "Commons Geometry"?
I don’t know why you are ignoring option 3, which is what many have suggested
many times.
3) Modify CM to be a multi-module project that contains only the modules you
want to support.
Ralph
> On Dec 3, 2017, at 4:51 AM, Gilles wrote:
>
> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
>> On Fri, Dec 1, 2017 at 2:26 PM, Gilles wrote:
>>
>>> There hasn't been any progress towards a decision.
>>> There isn't even a consensus on one of the central tenets of
>>> Apache ("Those who do the work..."): how sad/strange (?).
>>
>> Those who do the work are welcome to decide on their own, if they do
>> not involve others.
>
> The conditional is not part of the well-known mantra.
>
> The issue here is to answer the question of what to do with
> a non-trivial code base. My stance is to try and fix the
> problem(s), a.o. difficult management, by rooting out its
> main cause: CM has become an aggregate of components with
> completely different subject matters, scopes, designs,
> efficiencies, provisions for extension, etc.
> [An array of issues which "maven" modules will not solve.]
>
> We are seemingly faced with a choice between:
> 1. Maintain CM as the huge library that it is now.
> 2. Incrementally create maintainable components.
>
> A long time has passed since these alternatives were first
> exposed, only proving that none of the people who informally
> chose option(1) invested work to make it a reality.
>
> Refusing option (2) not only "involves others"; it is harming
> them (very real people, having done a lot of work here, on
> that code base).
>
>> Establishing a new commons component doesn't
>> qualify, IMO.
>
> True; that's why we are stalled, despite that a majority
> of the PMC did not explicitly oppose option (2).
>
> A handful of PMC people prefer to let the code base become
> "dormant" rather than give any chance to an alternate view.
> [If, say, you looked at the "Commons RNG" project, and
> concluded that, decidedly, this is not how a component
> should look like, then I could perhaps fathom out where
> those reservations come from.]
>
> Gilles
>
>>
>> Jochen
>
>
> -
> 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
Re: [All][Math] New component: "Commons Geometry"?
Hi Ralph.
On Tue, 5 Dec 2017 22:38:06 -0700, Ralph Goers wrote:
I don’t know
Then please _read_ the ML archive.
why you are ignoring
I do not (willingly) "ignore" any proposal. [Gentle
reminders are welcome if/when I lost track of a pending
issue that is waiting for my input.]
It's rather the opposite: a few PMC people keep turning
a blind eye to arguably constructive proposals (see below
and ML archive).
option 3, which is what many have
suggested many times.
With strings attached. See ML archive.
3) Modify CM to be a multi-module project
See below; what don't you understand in "issues which
maven modules will not solve"?
[See ML archive for a many times reiterated detailed
description of the CM problems, the difference between
CM and other components (modular or not), here and
elsewhere, and how we do not have (never had) the human
resources to correctly handle such a large and diverse
code base.]
that contains only the
modules you want to support.
That condition was explicitly rejected when *I* first
evoked it (see ML archive).
Later discussions (see ML archive) clarified (?!) that
modularizing CM would certainly not suffice to revive
the project.
Other options were (see ML archive)
4. create an Apache TLP (proposed by James Carman),
5. go through the Incubator.
Either one required the PMC to relinquish the code base
(no internal fork allowed IIUC), which it refused (see ML
archive).
The now visible consequences of renewed obstruction to
the refactoring of CM were not difficult to predict (see
ML archive).
Gilles
Ralph
On Dec 3, 2017, at 4:51 AM, Gilles
wrote:
On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
On Fri, Dec 1, 2017 at 2:26 PM, Gilles
wrote:
There hasn't been any progress towards a decision.
There isn't even a consensus on one of the central tenets of
Apache ("Those who do the work..."): how sad/strange (?).
Those who do the work are welcome to decide on their own, if they
do
not involve others.
The conditional is not part of the well-known mantra.
The issue here is to answer the question of what to do with
a non-trivial code base. My stance is to try and fix the
problem(s), a.o. difficult management, by rooting out its
main cause: CM has become an aggregate of components with
completely different subject matters, scopes, designs,
efficiencies, provisions for extension, etc.
[An array of issues which "maven" modules will not solve.]
We are seemingly faced with a choice between:
1. Maintain CM as the huge library that it is now.
2. Incrementally create maintainable components.
A long time has passed since these alternatives were first
exposed, only proving that none of the people who informally
chose option(1) invested work to make it a reality.
Refusing option (2) not only "involves others"; it is harming
them (very real people, having done a lot of work here, on
that code base).
Establishing a new commons component doesn't
qualify, IMO.
True; that's why we are stalled, despite that a majority
of the PMC did not explicitly oppose option (2).
A handful of PMC people prefer to let the code base become
"dormant" rather than give any chance to an alternate view.
[If, say, you looked at the "Commons RNG" project, and
concluded that, decidedly, this is not how a component
should look like, then I could perhaps fathom out where
those reservations come from.]
Gilles
Jochen
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][Math] New component: "Commons Geometry"?
Frankly, as an observer, this issue seems to be handled pretty poorly.
Commons-Math is currently dead. There are people willing to put in
effort to work on parts of it, but they are blocked at every turn.
Various options are put forward, but nothing ever happens.
In technical terms, if Commons-Math were a TLP, it would no doubt
release multiple separate releases, just like commons does. Thus,
separate commons projects seems like a good model.
Commons-VFS is not a good comparator, as it is a single "narrow and
deep" library with plugins. Commons-Math is a "broad and shallow"
library by comparison [1]. Subdivisions of a "broad and shallow"
library are best managed with separate release cycles, as each part is
independent of the others. (commons [lang], [collections] and [io] are
not forced to be multi-module simply because they all release to the
java.base module).
Anyway, the original rules for Commons [2] required a majority
approval vote (more +1 than -1) to create a new component, which has
already happended AFAICT. So, I think those that want to create a new
component should JFDI.
Stephen
[1] https://marc.info/?l=jakarta-commons-dev&m=108601577728628&w=2
[2] http://commons.apache.org/oldcharter.html (item 15)
On 6 December 2017 at 12:59, Gilles wrote:
> Hi Ralph.
>
> On Tue, 5 Dec 2017 22:38:06 -0700, Ralph Goers wrote:
>>
>> I don’t know
>
>
> Then please _read_ the ML archive.
>
>> why you are ignoring
>
>
> I do not (willingly) "ignore" any proposal. [Gentle
> reminders are welcome if/when I lost track of a pending
> issue that is waiting for my input.]
>
> It's rather the opposite: a few PMC people keep turning
> a blind eye to arguably constructive proposals (see below
> and ML archive).
>
>> option 3, which is what many have
>> suggested many times.
>
>
> With strings attached. See ML archive.
>
>> 3) Modify CM to be a multi-module project
>
>
> See below; what don't you understand in "issues which
> maven modules will not solve"?
> [See ML archive for a many times reiterated detailed
> description of the CM problems, the difference between
> CM and other components (modular or not), here and
> elsewhere, and how we do not have (never had) the human
> resources to correctly handle such a large and diverse
> code base.]
>
>> that contains only the
>> modules you want to support.
>
>
> That condition was explicitly rejected when *I* first
> evoked it (see ML archive).
>
> Later discussions (see ML archive) clarified (?!) that
> modularizing CM would certainly not suffice to revive
> the project.
>
> Other options were (see ML archive)
> 4. create an Apache TLP (proposed by James Carman),
> 5. go through the Incubator.
>
> Either one required the PMC to relinquish the code base
> (no internal fork allowed IIUC), which it refused (see ML
> archive).
>
> The now visible consequences of renewed obstruction to
> the refactoring of CM were not difficult to predict (see
> ML archive).
>
> Gilles
>
>
>
>> Ralph
>>
>>> On Dec 3, 2017, at 4:51 AM, Gilles wrote:
>>>
>>> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
On Fri, Dec 1, 2017 at 2:26 PM, Gilles
wrote:
> There hasn't been any progress towards a decision.
> There isn't even a consensus on one of the central tenets of
> Apache ("Those who do the work..."): how sad/strange (?).
Those who do the work are welcome to decide on their own, if they do
not involve others.
>>>
>>>
>>> The conditional is not part of the well-known mantra.
>>>
>>> The issue here is to answer the question of what to do with
>>> a non-trivial code base. My stance is to try and fix the
>>> problem(s), a.o. difficult management, by rooting out its
>>> main cause: CM has become an aggregate of components with
>>> completely different subject matters, scopes, designs,
>>> efficiencies, provisions for extension, etc.
>>> [An array of issues which "maven" modules will not solve.]
>>>
>>> We are seemingly faced with a choice between:
>>> 1. Maintain CM as the huge library that it is now.
>>> 2. Incrementally create maintainable components.
>>>
>>> A long time has passed since these alternatives were first
>>> exposed, only proving that none of the people who informally
>>> chose option(1) invested work to make it a reality.
>>>
>>> Refusing option (2) not only "involves others"; it is harming
>>> them (very real people, having done a lot of work here, on
>>> that code base).
>>>
Establishing a new commons component doesn't
qualify, IMO.
>>>
>>>
>>> True; that's why we are stalled, despite that a majority
>>> of the PMC did not explicitly oppose option (2).
>>>
>>> A handful of PMC people prefer to let the code base become
>>> "dormant" rather than give any chance to an alternate view.
>>> [If, say, you looked at the "Commons RNG" project, and
>>> concluded that, decidedly, this is not how a component
>>> should look like, then I could perhaps fathom out where
>>> those reservations come from.]
>>>
>>> Gi
