Re: [Math] Getting things done

[Jörg Schaible]

Hello Mike,

michael.brzustow...@gmail.com wrote:

> Hi Math3 devs,
> 
> Is there a consensus on the future of Math3?

Definately. Not necessarily as Math3 for mid-term, since the plan was to 
establish a Math TLP with the code base of Math 3/4 minus the code for the 
three new components.

> I rely on the Linear Algebra
> package and also Stats.
> Is there major changes planned for those? I have heard some mentions of
> refactoring going on,
> but not sure how much would change to the API ... or if it's just
> implementation details.

Actually I have no knowledge about the current state of the code, esp. what 
happened between Math 3 and 4 for the areas you've mentioned here.
 
> I do hope to contribute some code (probably in linalg, stats,
> machine-learning) when some current
> side projects clear up and I have time to dedicate.

Any help is welcome. The future of Math needs an active community caring for 
the individual parts of the code.

Cheers.
Jörg


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

Re: [Math] Getting things done

[michael.brzustow...@gmail.com]

Hi Math3 devs,

Is there a consensus on the future of Math3? I rely on the Linear Algebra
package and also Stats.
Is there major changes planned for those? I have heard some mentions of
refactoring going on,
but not sure how much would change to the API ... or if it's just
implementation details.

I do hope to contribute some code (probably in linalg, stats,
machine-learning) when some current
side projects clear up and I have time to dedicate.

Thanx,
Mike Brzustowicz

On Sat, Jun 25, 2016 at 7:58 AM, Jörg Schaible 
wrote:

> Brent Worden wrote:
>
> > On Thu, Jun 23, 2016 at 12:05 PM, Jörg Schaible 
> > wrote:
> >
> >> Hi Gilles,
> >>
> >> Gilles wrote:
> >>
> >> [snip]
> >>
> >> > Indeed, it will be much more productive to let the new(bie) team
> >> > experiment within Commons by creating the following new components:
> >> >   * Commons RNG
> >> >   * Commons AltMath
> >> >   * Commons MathTools
> >> >
> >> > The first one, pretty much, was accepted. Amazing.
> >>
> >>
> >> Not yet, only two binding votes. However, you're able to change this ;-)
> >>
> >>
> > Not to sidetrack this discussion but, I believe there were three binding
> > votes:
> > - Benedikt Ritter
> > - Emmanuel Bourg
> > - Brent Worden
>
> You're right. Actually I missed your vote.
>
> Cheers,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Getting things done

[Jörg Schaible]

Brent Worden wrote:

> On Thu, Jun 23, 2016 at 12:05 PM, Jörg Schaible 
> wrote:
> 
>> Hi Gilles,
>>
>> Gilles wrote:
>>
>> [snip]
>>
>> > Indeed, it will be much more productive to let the new(bie) team
>> > experiment within Commons by creating the following new components:
>> >   * Commons RNG
>> >   * Commons AltMath
>> >   * Commons MathTools
>> >
>> > The first one, pretty much, was accepted. Amazing.
>>
>>
>> Not yet, only two binding votes. However, you're able to change this ;-)
>>
>>
> Not to sidetrack this discussion but, I believe there were three binding
> votes:
> - Benedikt Ritter
> - Emmanuel Bourg
> - Brent Worden

You're right. Actually I missed your vote.

Cheers,
Jörg



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

Re: [Math] Getting things done

[Brent Worden]

On Thu, Jun 23, 2016 at 12:05 PM, Jörg Schaible 
wrote:

> Hi Gilles,
>
> Gilles wrote:
>
> [snip]
>
> > Indeed, it will be much more productive to let the new(bie) team
> > experiment within Commons by creating the following new components:
> >   * Commons RNG
> >   * Commons AltMath
> >   * Commons MathTools
> >
> > The first one, pretty much, was accepted. Amazing.
>
>
> Not yet, only two binding votes. However, you're able to change this ;-)
>
>
Not to sidetrack this discussion but, I believe there were three binding
votes:
- Benedikt Ritter
- Emmanuel Bourg
- Brent Worden

Re: [Math] Getting things done

[Emmanuel Bourg]

Le 23/06/2016 à 19:20, Jörg Schaible a écrit :

> Hmm. Here I got lost. Do you now try to keep the "unsupported" parts in CM4 
> or leave them out as proposed two lines above? 

Well, that really depends on the usefulness of the parts considered. For
example even if we have no developer expert in Fourier transforms,
considering that it's a widely used algorithm that is already well
covered by the unit tests, I think we should keep it. On the other hand,
an unsupported part that is rarely useful could be dropped.

> As long as we keep the name "CM" we make promises to existing users
> and it is difficult to drop something.

I don't see this as an issue, users relying on the removed parts can
stick to CM 3.x (or switch to Hipparchus).

Emmanuel Bourg


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

Re: [Math] Getting things done

[Jörg Schaible]

Hi Emmanuel,

Emmanuel Bourg wrote:

> Le 23/06/2016 à 14:33, Jochen Wiedmann a écrit :
> 
>> The important part, to me, is to find something on which we can agree.
>> That doesn't mean that everyone is happy with the outcome, but that
>> everyone's got the feeling "I can live with that". In particular,
>> there must not be any serious opposition later on. If you'd like to
>> oppose: Please do so here, and now.
> 
> Thank you for proposing a plan Jochen. I'm certainly in the "I can live
> with that" category, but I'm a bit skeptical about the outcome. Neither
> the incubator nor a TLP sound viable to me at this point, because the
> community around commons-math hasn't recovered from the loss of its
> historical contributors. I'd would rather incubate the Math TLP within
> Commons until more contributors like Eric join the party.
> 
> Because the best way to attract developers is to release something
> useful, I'd suggest releasing as soon as possible something derived from
> the current Commons Math 4 base:
> - commons-random: with the random number generators
> - commons-math4: with the core math utilities (fractions, complex,
> fastmath, stats, FFT, etc) and leaving out the orphaned parts judged too
> specialized like the genetic algorithms.
> 
> The core commons-math4 may contain "unsupported" parts as long as they
> are properly covered by unit tests and not too specialized.

Hmm. Here I got lost. Do you now try to keep the "unsupported" parts in CM4 
or leave them out as proposed two lines above? As long as we keep the name 
"CM" we make promises to existing users and it is difficult to drop 
something.

One benefit of Gilles smaller components is their specialized target. We as 
PMC failed to realize that CM had been a dumping ground in the last 10 years 
(see Dimitri's mail) and that aside the real common math utilities we also 
collected very specialized stuff that is hardly used by anyone and that 
should have never been added to *Commons* Math (AFAICS the latest released 
jar is the threefold size compared to any other Commons component). If we 
keep "CM" we might end up in the same situation again.

- Jörg


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

Re: [Math] Getting things done

[Jörg Schaible]

Hi Gilles,

Gilles wrote:

[snip]

> Indeed, it will be much more productive to let the new(bie) team
> experiment within Commons by creating the following new components:
>   * Commons RNG
>   * Commons AltMath
>   * Commons MathTools
> 
> The first one, pretty much, was accepted. Amazing.


Not yet, only two binding votes. However, you're able to change this ;-)

Actually RNG is the component with the least strings, because it has never 
been released and creates no binary compatibility problems. Simply remove 
the code from CM4 and anything is well.


> The second one is more fuzzy for some people, but I'll have to stress
> again that it's probably because they should have a look at the code!
> It will be a zero dependency component (which I had referred to as
> "Standard math functions" in the vote thread) with common
> functionality,
> useful beyond "math-centric" (whatever that means) applications.
> 
> The last one is a smaller "Commons Math", i.e. stripped of
> functionality
> unsupported at the time of release.
> It is _also_ a new component to clearly separate it from Commons Math,
> so that users have an upgrade path; or at least, they will be able to
> easily figure out what has become unsupported.
> If new contributors come in order to fill the gap, more codes can be
> transferred to "MathTools".[2]
> [At the same time "Commons Math" itself stays clean of packages
> reordering, renaming or removal, so that if and when someone wants to
> restart from there, it's trivial.]
> 
> I see this proposal as a compromise, deferring(!) further splits of
> complex and rational" numbers functionality, while allowing to have a
> taste of the the advantages and drawbacks of full modularization (i.e.
> individual components).


Still, we have not yet cleared what it means to the existing CM to break 
these out, since the code to extract *has been* released (see also 
Benedikt's question). It's still a "proper" component unless we move it into 
dormant and/or hand it over to a TLP.

IMHO the best way out would be a CM 3.7 release (based on latest 3.x) with 
all removed classes marked as deprecated. Then you're free to drop the code 
in trunk and a future Math TLP might concentrate on specialized mathematical 
algorithms and problems that do not have such a wide audience.

And who knows, maybe the Hipparchus fork will use these new components also 
in the long run and concentrate themselves on the "interesting" stuff.

Cheers,
Jörg


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

Re: [Math] Getting things done

[Gilles]

Hello.

On Thu, 23 Jun 2016 14:33:05 +0200, Jochen Wiedmann wrote:

Hi,

I'd like an attempt to put an end to all those discussions regarding
Commons Math (CM). That means, in particular, that we find an common
agreement on a course of action. So, here's a suggestion (might as
well call it an offer, because acceptance would mean a lot of work on
my side)

  1.) I'll write a proposal to move CM to the Incubator.
  2.) We'll wait for the Incubators decision. If the Incubator 
accepts CM.
  3.) If the Incubator rejects CM, then I'd start another formal TLP 
vote.

  4.) If the board accepts the TLP: Very well.
  5.) If not: So what. Now we know, at least.

In either case: At the end of the procedure, we'd have clarity. This
will allow us to focus on a smaller set of issues (technical), and we
can go on.

The important part, to me, is to find something on which we can 
agree.

That doesn't mean that everyone is happy with the outcome, but that
everyone's got the feeling "I can live with that". In particular,
there must not be any serious opposition later on. If you'd like to
oppose: Please do so here, and now.


Thanks for a constructive proposal.

But as you indicated, this means a lot of administrative work whose
ultimate result is far from being certain.
In particular, people have quite clearly pointed out that the incubator
 * is a place for community building
 * not a place to rethink a code base
while we have
 * a community (small perhaps, but sufficient for the code we want to
   release and are able to support), but
 * no viable (IMO) project for salvaging the currently "unsupported"
   code.[1]

If Commons reject its own code (IOW does not accept a new component,
despite its potential usefulness, as noted by Eric), then the next
alternative would be a TLP proposal (as attempted by James).  Because
in the TLP, we'll be allowed to release components according to their
individual level of support (which means that well-tested code can be
released ASAP while in the incubator path, it might never be).
Obviously, this would necessitates that the Commons PMC accepts to let
go of the Commons Math code base without any strings attached.

So... I agree with Dave. ;-)

And partially with Emmanuel.

Indeed, it will be much more productive to let the new(bie) team
experiment within Commons by creating the following new components:
 * Commons RNG
 * Commons AltMath
 * Commons MathTools

The first one, pretty much, was accepted. Amazing.

The second one is more fuzzy for some people, but I'll have to stress
again that it's probably because they should have a look at the code!
It will be a zero dependency component (which I had referred to as
"Standard math functions" in the vote thread) with common 
functionality,

useful beyond "math-centric" (whatever that means) applications.

The last one is a smaller "Commons Math", i.e. stripped of 
functionality

unsupported at the time of release.
It is _also_ a new component to clearly separate it from Commons Math,
so that users have an upgrade path; or at least, they will be able to
easily figure out what has become unsupported.
If new contributors come in order to fill the gap, more codes can be
transferred to "MathTools".[2]
[At the same time "Commons Math" itself stays clean of packages
reordering, renaming or removal, so that if and when someone wants to
restart from there, it's trivial.]

I see this proposal as a compromise, deferring(!) further splits of
complex and rational" numbers functionality, while allowing to have a
taste of the the advantages and drawbacks of full modularization (i.e.
individual components).

We do this; if the result suits the PMC, we go on; if not: "Now we 
know,

at least."

Do you agree?
If not, please let us know why.


Regards,
Gilles

[1] To become a valuable project, the proposal probably needs a "back 
to
basics" study (as noted by Dimitri) in order to generate a 
consistent

initiative, and not just another fork encumbered with all the
liabilities of the past and no experts to compensate for them.
[2] Of course, the naming is illustrative, subject to a VOTE. ;-)



Thanks,

Jochen



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

Re: [Math] Getting things done

[Eric Barnhill]

Thank you for the clarification.

I like the idea of a commons-math base component, suiting the commons
mission.

If commons math were transmuted to a large scale new math project, that
competes with Hipparchus. Both projects are forks of the same scope and at
the same time. But in the Hipparchus case, the decisions are made by the
people who contribute to the library, and further, there are (I gather)
more very experienced contributors. Here the decisions on math are mostly
not made by people who contribute to math, and the experienced contributors
have dwindled.

I'm sorry but I think the reality is that such a project won't compete.
Certainly if I had to choose, I would probably prefer the other fork,
though in reality without commons-math I would just move my energies to GNU
Octave and ImageJ.

Gilles does not think that the new project will compete either. In
response, Gilles is trying to reshape commons-math in a way that will have
an important and unique place in the world and attract users, uses and
support. This is a code base that interweaves successfully with the commons
mission and code base, with the potential for growth in the form of small
auxiliary modules driven by enthusiasts.

A base commons-math could draw broad support from the community for some
relatively easy to maintain components that really are in common use as the
enthusiasts come and go. Personally, this suits my interests which are not
extravagantly mathematical. I really just want to smooth the terrain
between commons, ImageJ, GNU Octave, and JoCL to maximize my open source
scientific computing pleasure. I'm just as likely to contribute to
commons-lang if that aids these goals. I can only speak for myself of
course.

Maybe four simultaneous votes was not the smoothest way to continue but it
allows Gilles to get going, while the iron is hot. No one has voted -1 so
perhaps Gilles should start the branch and let us know what it is.

I don't anticipate posting any more comments on these matters, but if
Gilles starts a new branch I will show up for work.

Eric


On Thu, Jun 23, 2016 at 2:53 PM, Ralph Goers 
wrote:

> My answer would be slightly different.  It doesn’t. All topics related to
> the code should be deferred until we know what is happening with the
> community.
>
> Ralph
>
> > On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann 
> wrote:
> >
> > It doesn't, at least in my opinion. If the future Math project decides
> > to have a "base" component: Very well. But, if the other components
> > are elsewhere: Why should the base stay at Commons?
> >
> >
> > On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill 
> wrote:
> >> There has been a lot of support in the discussions for, as Emmanuel put
> it,
> >> a "base commons-math
> >> component".
> >>
> >> Where does that factor into this proposal?
> >>
> >> On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I'd like an attempt to put an end to all those discussions regarding
> >>> Commons Math (CM). That means, in particular, that we find an common
> >>> agreement on a course of action. So, here's a suggestion (might as
> >>> well call it an offer, because acceptance would mean a lot of work on
> >>> my side)
> >>>
> >>>  1.) I'll write a proposal to move CM to the Incubator.
> >>>  2.) We'll wait for the Incubators decision. If the Incubator accepts
> CM.
> >>>  3.) If the Incubator rejects CM, then I'd start another formal TLP
> vote.
> >>>  4.) If the board accepts the TLP: Very well.
> >>>  5.) If not: So what. Now we know, at least.
> >>>
> >>> In either case: At the end of the procedure, we'd have clarity. This
> >>> will allow us to focus on a smaller set of issues (technical), and we
> >>> can go on.
> >>>
> >>> The important part, to me, is to find something on which we can agree.
> >>> That doesn't mean that everyone is happy with the outcome, but that
> >>> everyone's got the feeling "I can live with that". In particular,
> >>> there must not be any serious opposition later on. If you'd like to
> >>> oppose: Please do so here, and now.
> >>>
> >>> Thanks,
> >>>
> >>> 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
> >>>
> >>>
> >
> >
> >
> > --
> > 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 

Re: [Math] Getting things done

[Rob Tompkins]

+1 - Tell me how I can help. I like the idea that we contribute a (or some) 
component(s) back to commons, but I think it makes a lot of sense to just work 
towards community future state before concerning ourselves with code future 
state, as that will happen naturally over time. 

-Rob

> On Jun 23, 2016, at 8:33 AM, Jochen Wiedmann  
> wrote:
> 
> Hi,
> 
> I'd like an attempt to put an end to all those discussions regarding
> Commons Math (CM). That means, in particular, that we find an common
> agreement on a course of action. So, here's a suggestion (might as
> well call it an offer, because acceptance would mean a lot of work on
> my side)
> 
>  1.) I'll write a proposal to move CM to the Incubator.
>  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>  4.) If the board accepts the TLP: Very well.
>  5.) If not: So what. Now we know, at least.
> 
> In either case: At the end of the procedure, we'd have clarity. This
> will allow us to focus on a smaller set of issues (technical), and we
> can go on.
> 
> The important part, to me, is to find something on which we can agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.
> 
> Thanks,
> 
> 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: [Math] Getting things done

[Emmanuel Bourg]

Le 23/06/2016 à 14:33, Jochen Wiedmann a écrit :

> The important part, to me, is to find something on which we can agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.

Thank you for proposing a plan Jochen. I'm certainly in the "I can live
with that" category, but I'm a bit skeptical about the outcome. Neither
the incubator nor a TLP sound viable to me at this point, because the
community around commons-math hasn't recovered from the loss of its
historical contributors. I'd would rather incubate the Math TLP within
Commons until more contributors like Eric join the party.

Because the best way to attract developers is to release something
useful, I'd suggest releasing as soon as possible something derived from
the current Commons Math 4 base:
- commons-random: with the random number generators
- commons-math4: with the core math utilities (fractions, complex,
fastmath, stats, FFT, etc) and leaving out the orphaned parts judged too
specialized like the genetic algorithms.

The core commons-math4 may contain "unsupported" parts as long as they
are properly covered by unit tests and not too specialized.

Does this sound like an acceptable compromise?

Emmanuel Bourg


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

Re: [Math] Getting things done

[Dave Brosius]

I realize there are good intentions here. But what the common theme of 
all these email chains, when you filter out the disagreements, is, 
"deferred until"


If 'deferring' is the only thing we can agree on, i think something is 
broken with the system.


IMO let the doers do. Clearly Gilles is the main driver of change. It 
appears he now has some people who will help at least to some extent, 
but he has shown over last half year (at least) that he will be the 
primary one to move the code base.


I would just have Gilles (and friends) go ahead and make the changes he 
feels are the right direction. If he were to take an inordinate dump in 
the code base (he won't), or walk away with it half-baked (he won't), 
the next person along, if ever, just can go back to an earlier branch 
point and start again.


But we are supposed to be a meritocracy, not an oligarchy. It feels much 
like that later at the moment.


dave

On 06/23/2016 08:53 AM, Ralph Goers wrote:

My answer would be slightly different.  It doesn’t. All topics related to the 
code should be deferred until we know what is happening with the community.

Ralph


On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann  wrote:

It doesn't, at least in my opinion. If the future Math project decides
to have a "base" component: Very well. But, if the other components
are elsewhere: Why should the base stay at Commons?


On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill  wrote:

There has been a lot of support in the discussions for, as Emmanuel put it,
a "base commons-math
component".

Where does that factor into this proposal?

On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann 
wrote:


Hi,

I'd like an attempt to put an end to all those discussions regarding
Commons Math (CM). That means, in particular, that we find an common
agreement on a course of action. So, here's a suggestion (might as
well call it an offer, because acceptance would mean a lot of work on
my side)

  1.) I'll write a proposal to move CM to the Incubator.
  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
  4.) If the board accepts the TLP: Very well.
  5.) If not: So what. Now we know, at least.

In either case: At the end of the procedure, we'd have clarity. This
will allow us to focus on a smaller set of issues (technical), and we
can go on.

The important part, to me, is to find something on which we can agree.
That doesn't mean that everyone is happy with the outcome, but that
everyone's got the feeling "I can live with that". In particular,
there must not be any serious opposition later on. If you'd like to
oppose: Please do so here, and now.

Thanks,

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





--
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: [Math] Getting things done

[Ralph Goers]

My answer would be slightly different.  It doesn’t. All topics related to the 
code should be deferred until we know what is happening with the community.

Ralph

> On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann  
> wrote:
> 
> It doesn't, at least in my opinion. If the future Math project decides
> to have a "base" component: Very well. But, if the other components
> are elsewhere: Why should the base stay at Commons?
> 
> 
> On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill  wrote:
>> There has been a lot of support in the discussions for, as Emmanuel put it,
>> a "base commons-math
>> component".
>> 
>> Where does that factor into this proposal?
>> 
>> On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann 
>> wrote:
>> 
>>> Hi,
>>> 
>>> I'd like an attempt to put an end to all those discussions regarding
>>> Commons Math (CM). That means, in particular, that we find an common
>>> agreement on a course of action. So, here's a suggestion (might as
>>> well call it an offer, because acceptance would mean a lot of work on
>>> my side)
>>> 
>>>  1.) I'll write a proposal to move CM to the Incubator.
>>>  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>>>  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>>>  4.) If the board accepts the TLP: Very well.
>>>  5.) If not: So what. Now we know, at least.
>>> 
>>> In either case: At the end of the procedure, we'd have clarity. This
>>> will allow us to focus on a smaller set of issues (technical), and we
>>> can go on.
>>> 
>>> The important part, to me, is to find something on which we can agree.
>>> That doesn't mean that everyone is happy with the outcome, but that
>>> everyone's got the feeling "I can live with that". In particular,
>>> there must not be any serious opposition later on. If you'd like to
>>> oppose: Please do so here, and now.
>>> 
>>> Thanks,
>>> 
>>> 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
>>> 
>>> 
> 
> 
> 
> -- 
> 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: [Math] Getting things done

[Jochen Wiedmann]

It doesn't, at least in my opinion. If the future Math project decides
to have a "base" component: Very well. But, if the other components
are elsewhere: Why should the base stay at Commons?


On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill  wrote:
> There has been a lot of support in the discussions for, as Emmanuel put it,
> a "base commons-math
> component".
>
> Where does that factor into this proposal?
>
> On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann 
> wrote:
>
>> Hi,
>>
>> I'd like an attempt to put an end to all those discussions regarding
>> Commons Math (CM). That means, in particular, that we find an common
>> agreement on a course of action. So, here's a suggestion (might as
>> well call it an offer, because acceptance would mean a lot of work on
>> my side)
>>
>>   1.) I'll write a proposal to move CM to the Incubator.
>>   2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>>   3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>>   4.) If the board accepts the TLP: Very well.
>>   5.) If not: So what. Now we know, at least.
>>
>> In either case: At the end of the procedure, we'd have clarity. This
>> will allow us to focus on a smaller set of issues (technical), and we
>> can go on.
>>
>> The important part, to me, is to find something on which we can agree.
>> That doesn't mean that everyone is happy with the outcome, but that
>> everyone's got the feeling "I can live with that". In particular,
>> there must not be any serious opposition later on. If you'd like to
>> oppose: Please do so here, and now.
>>
>> Thanks,
>>
>> 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
>>
>>



-- 
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: [Math] Getting things done

[Eric Barnhill]

There has been a lot of support in the discussions for, as Emmanuel put it,
a "base commons-math
component".

Where does that factor into this proposal?

On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann 
wrote:

> Hi,
>
> I'd like an attempt to put an end to all those discussions regarding
> Commons Math (CM). That means, in particular, that we find an common
> agreement on a course of action. So, here's a suggestion (might as
> well call it an offer, because acceptance would mean a lot of work on
> my side)
>
>   1.) I'll write a proposal to move CM to the Incubator.
>   2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>   3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>   4.) If the board accepts the TLP: Very well.
>   5.) If not: So what. Now we know, at least.
>
> In either case: At the end of the procedure, we'd have clarity. This
> will allow us to focus on a smaller set of issues (technical), and we
> can go on.
>
> The important part, to me, is to find something on which we can agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.
>
> Thanks,
>
> 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: [Math] Getting things done

[Ralph Goers]

+1 - Go for it!

Ralph

> On Jun 23, 2016, at 5:33 AM, Jochen Wiedmann  
> wrote:
> 
> Hi,
> 
> I'd like an attempt to put an end to all those discussions regarding
> Commons Math (CM). That means, in particular, that we find an common
> agreement on a course of action. So, here's a suggestion (might as
> well call it an offer, because acceptance would mean a lot of work on
> my side)
> 
>  1.) I'll write a proposal to move CM to the Incubator.
>  2.) We'll wait for the Incubators decision. If the Incubator accepts CM.
>  3.) If the Incubator rejects CM, then I'd start another formal TLP vote.
>  4.) If the board accepts the TLP: Very well.
>  5.) If not: So what. Now we know, at least.
> 
> In either case: At the end of the procedure, we'd have clarity. This
> will allow us to focus on a smaller set of issues (technical), and we
> can go on.
> 
> The important part, to me, is to find something on which we can agree.
> That doesn't mean that everyone is happy with the outcome, but that
> everyone's got the feeling "I can live with that". In particular,
> there must not be any serious opposition later on. If you'd like to
> oppose: Please do so here, and now.
> 
> Thanks,
> 
> 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