[ALL] Volunteers for a Math IPMC?

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

James Carman
Could we start something in the sandbox? It's not modifying existing code.

On Sat, Jun 18, 2016 at 8:43 AM Jörg Schaible <[hidden email]> wrote:

> Hi Gilles,
>
> Gilles wrote:
>
> > Hi.
> >
> > On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote:
> >> Gilles,
> >>
> >> Thanks for links.
> >>
> >> I just read that (long-winded) thread and I see no consensus that
> >> "Commons
> >> project is not being interested in hosting those components".
> >
> > In line with what I wrote previously, there isn't any consensus on
> > anything
> > within Commons.
> >
> > I'm asking, again, whether I need to initiate a VOTE that would allow
> > me
> > to set up a workspace ("git", etc.) and transfer some code from CM over
> > there.
> > Or can I jut do it?  [Some help with doing that is most welcome.]
>
>
> -1 (and this is a veto)
>
> Not unless the future of the existing CM is clarified and we get (majority
> ?) consensus here on the list.
>
>
> >> It may be that incubation is a good thing for Commons Math, but it
> >> doesn't
> >> seem valid to say that incubation is necessary because CM is being
> >> kicked
> >> out of Commons.
> >
> > Never said so.
> >
> > There is a confusion here: *I* say that CM is dead.
> >
> > It was dead already in early February but nobody noticed because *I*
> > (alone) continued to answer the ML, comment on JIRA reports and commit
> > code.
> >
> > Why I was alone doing that became clear when Luc announced his
> > resignation
> > and the fork.
> >
> > The development situation *will* change because the context *has*
> > changed
> > (unsupported code).
> > CM cannot go on as it did before the fork.
>
>
> And this is exactly the question. For me as PMC member of Commons I have to
> look at all components and it is not the first time that the original
> authors of a component vanishes and it won't be the last. Either new people
> will stay up to carry on (there are already some new ones) or the component
> is moved at some point into dormant state, because it gets obsolete (maybe
> because of the fork, future will tell).
>
> However, we care for all Commons components and their usage in the wild.
> Nearly all of our components are buried deep down in some software stacks
> and therefore we always take care to an extreme extent to compatibility of
> new releases. With your proposal to rip CM into parts you leave the current
> users of CM out in the rain. *You* tell them simply to use your new shiny
> components A and B and for the rest they should stay at old CM (that still
> contains on top the old stuff of A and B). Sorry, but this is not a proper
> scenario for Commons.
>
>
> > Everybody (developers, users, Commons PMC) would be better off with a
> > selected set of new (supported) components because this is something we
> > can easily do *now* (RERO, etc.).
>
>
> Again, this is *your* point of view and it is caused by *your* refusal to
> consider a CM release that contains the existing code base, just because
> this includes also code *you* cannot/will not/have no interest to support
> or
> maintain. Nobody asked the latter of *you*, just to keep the code untouched
> where you have no interest to work with. Nobody would stop you from working
> on the rest.
>
>
> > I'm OK to go through the incubator to do that; but I don't see that it
> > is an easier path.  Surely it looks longer.  And it seems that even the
> > incubator people doubt that it will lead anywhere.
> >
> > Given the uncertain outcome, going through the incubator would be an
> > attempt at rethinking the development of the currently unsupported
> > code.  See e.g.
> >    https://issues.apache.org/jira/browse/MATH-172
> > [Or is that out of scope for an incubation proposal?]
>
>
> The incubator seems at least to be an option to go forward with CM.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Gilles Sadowski
In reply to this post by Jörg Schaible
Hi.

On Sat, 18 Jun 2016 14:42:46 +0200, Jörg Schaible wrote:

> Hi Gilles,
>
> Gilles wrote:
>
>> Hi.
>>
>> On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote:
>>> Gilles,
>>>
>>> Thanks for links.
>>>
>>> I just read that (long-winded) thread and I see no consensus that
>>> "Commons
>>> project is not being interested in hosting those components".
>>
>> In line with what I wrote previously, there isn't any consensus on
>> anything
>> within Commons.
>>
>> I'm asking, again, whether I need to initiate a VOTE that would
>> allow
>> me
>> to set up a workspace ("git", etc.) and transfer some code from CM
>> over
>> there.
>> Or can I jut do it?  [Some help with doing that is most welcome.]
>
>
> -1 (and this is a veto)

What are you vetoing?

Or does this veto indeed shows to Ted that Commons refuses to create
new components.

> Not unless the future of the existing CM is clarified and we get
> (majority
> ?) consensus here on the list.

What I hope is clear that any non-bug-fix release of CM 3.x is without
me.

>>> It may be that incubation is a good thing for Commons Math, but it
>>> doesn't
>>> seem valid to say that incubation is necessary because CM is being
>>> kicked
>>> out of Commons.
>>
>> Never said so.
>>
>> There is a confusion here: *I* say that CM is dead.
>>
>> It was dead already in early February but nobody noticed because *I*
>> (alone) continued to answer the ML, comment on JIRA reports and
>> commit
>> code.
>>
>> Why I was alone doing that became clear when Luc announced his
>> resignation
>> and the fork.
>>
>> The development situation *will* change because the context *has*
>> changed
>> (unsupported code).
>> CM cannot go on as it did before the fork.
>
>
> And this is exactly the question. For me as PMC member of Commons I
> have to
> look at all components and it is not the first time that the original
> authors of a component vanishes and it won't be the last.

It's not "author" that matters, it's "maintainer".
[It just happens that the two were the same for a lot of the codes in
CM (not a healthy situation indeed).]

> Either new people
> will stay up to carry on (there are already some new ones)

I discussed that already: counting new contributors and estimating
their
future contributions, that still leaves roughly 80% of the code
unsupported.

> or the component
> is moved at some point into dormant state, because it gets obsolete
> (maybe
> because of the fork, future will tell).
>
> However, we care for all Commons components and their usage in the
> wild.
> Nearly all of our components are buried deep down in some software
> stacks
> and therefore we always take care to an extreme extent to
> compatibility of
> new releases.

Again this non-argument?
I answered to that countless times: Major releases are NOT REQUIRED to
be
compatible.

> With your proposal to rip CM into parts you leave the current
> users of CM out in the rain. *You* tell them simply to use your new
> shiny
> components A and B and for the rest they should stay at old CM (that
> still
> contains on top the old stuff of A and B). Sorry, but this is not a
> proper
> scenario for Commons.

How is that different from the scenario of any other major release?
Either I don't understand what you are talking about or it seems that
you
forbid any release of new code unless everything has been fixed in the
code.

It was never the case and it makes no sense.

>> Everybody (developers, users, Commons PMC) would be better off with
>> a
>> selected set of new (supported) components because this is something
>> we
>> can easily do *now* (RERO, etc.).
>
>
> Again, this is *your* point of view and it is caused by *your*
> refusal to
> consider a CM release that contains the existing code base, just
> because
> this includes also code *you* cannot/will not/have no interest to
> support or
> maintain.

I explained my position on this.  And it is not what you state here.

For me, a bug-fix for CM 3.x is OK if the following conditions are both
satisfied:
  1. CM 4.0 is worked on actively and released, and
  2. a need is explicitly identified (and those who have this need will
     actively help).

A release of CM 4.0 that is monolithic, targets Java 5 and contains
unsupported code is not OK.

> Nobody asked the latter of *you*, just to keep the code untouched
> where you have no interest to work with.

I already answered to that point.  Code is there; anyone can take from
any point in its history and do whatever he pleases.

> Nobody would stop you from working on the rest.

You just did.

As it happens you seem to acknowledge that the fork outside Apache is
the only way to sort out the identified shortcomings of CM.

Is it what you are aiming at by vetoing new components?

>> I'm OK to go through the incubator to do that; but I don't see that
>> it
>> is an easier path.  Surely it looks longer.  And it seems that even
>> the
>> incubator people doubt that it will lead anywhere.
>>
>> Given the uncertain outcome, going through the incubator would be an
>> attempt at rethinking the development of the currently unsupported
>> code.  See e.g.
>>    https://issues.apache.org/jira/browse/MATH-172
>> [Or is that out of scope for an incubation proposal?]
>
>
> The incubator seems at least to be an option to go forward with CM.

How is that different from the POV of Commons?

This time could be better spent in rethinking the codebase in order
to get it right (community-wise) this time.

Legacy users will not upgrade to CM 4.0, whatever it contains.
New users/contributors will not come to maintain a legacy code.

CM is dead.  And we are loosing a lot of time in sterile discussions
about scenarios that DO NOT exist (for CM).


Gilles

>
> - Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Matt Benson-2
On Jun 18, 2016 9:28 AM, "Gilles" <[hidden email]> wrote:

>
> Hi.
>
>
> On Sat, 18 Jun 2016 14:42:46 +0200, Jörg Schaible wrote:
>>
>> Hi Gilles,
>>
>> Gilles wrote:
>>
>>> Hi.
>>>
>>> On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote:
>>>>
>>>> Gilles,
>>>>
>>>> Thanks for links.
>>>>
>>>> I just read that (long-winded) thread and I see no consensus that
>>>> "Commons
>>>> project is not being interested in hosting those components".
>>>
>>>
>>> In line with what I wrote previously, there isn't any consensus on
>>> anything
>>> within Commons.
>>>
>>> I'm asking, again, whether I need to initiate a VOTE that would allow
>>> me
>>> to set up a workspace ("git", etc.) and transfer some code from CM over
>>> there.
>>> Or can I jut do it?  [Some help with doing that is most welcome.]
>>
>>
>>
>> -1 (and this is a veto)
>
>
> What are you vetoing?
>
> Or does this veto indeed shows to Ted that Commons refuses to create
> new components.
>
>

I think it is indicative of the position held by many, myself included,
that a set of focused, math-related artifacts do not make sense at the
Commons component level, and should be grouped as separate artifacts of
Commons math or a TLP with the same basic structure.

Matt

>> Not unless the future of the existing CM is clarified and we get
(majority

>> ?) consensus here on the list.
>
>
> What I hope is clear that any non-bug-fix release of CM 3.x is without
> me.
>
>
>>>> It may be that incubation is a good thing for Commons Math, but it
>>>> doesn't
>>>> seem valid to say that incubation is necessary because CM is being
>>>> kicked
>>>> out of Commons.
>>>
>>>
>>> Never said so.
>>>
>>> There is a confusion here: *I* say that CM is dead.
>>>
>>> It was dead already in early February but nobody noticed because *I*
>>> (alone) continued to answer the ML, comment on JIRA reports and commit
>>> code.
>>>
>>> Why I was alone doing that became clear when Luc announced his
>>> resignation
>>> and the fork.
>>>
>>> The development situation *will* change because the context *has*
>>> changed
>>> (unsupported code).
>>> CM cannot go on as it did before the fork.
>>
>>
>>
>> And this is exactly the question. For me as PMC member of Commons I have
to

>> look at all components and it is not the first time that the original
>> authors of a component vanishes and it won't be the last.
>
>
> It's not "author" that matters, it's "maintainer".
> [It just happens that the two were the same for a lot of the codes in
> CM (not a healthy situation indeed).]
>
>
>> Either new people
>> will stay up to carry on (there are already some new ones)
>
>
> I discussed that already: counting new contributors and estimating their
> future contributions, that still leaves roughly 80% of the code
unsupported.
>
>
>> or the component
>> is moved at some point into dormant state, because it gets obsolete
(maybe
>> because of the fork, future will tell).
>>
>> However, we care for all Commons components and their usage in the wild.
>> Nearly all of our components are buried deep down in some software stacks
>> and therefore we always take care to an extreme extent to compatibility
of

>> new releases.
>
>
> Again this non-argument?
> I answered to that countless times: Major releases are NOT REQUIRED to be
> compatible.
>
>
>> With your proposal to rip CM into parts you leave the current
>> users of CM out in the rain. *You* tell them simply to use your new shiny
>> components A and B and for the rest they should stay at old CM (that
still
>> contains on top the old stuff of A and B). Sorry, but this is not a
proper
>> scenario for Commons.
>
>
> How is that different from the scenario of any other major release?
> Either I don't understand what you are talking about or it seems that you
> forbid any release of new code unless everything has been fixed in the
code.

>
> It was never the case and it makes no sense.
>
>
>>> Everybody (developers, users, Commons PMC) would be better off with a
>>> selected set of new (supported) components because this is something we
>>> can easily do *now* (RERO, etc.).
>>
>>
>>
>> Again, this is *your* point of view and it is caused by *your* refusal to
>> consider a CM release that contains the existing code base, just because
>> this includes also code *you* cannot/will not/have no interest to
support or

>> maintain.
>
>
> I explained my position on this.  And it is not what you state here.
>
> For me, a bug-fix for CM 3.x is OK if the following conditions are both
> satisfied:
>  1. CM 4.0 is worked on actively and released, and
>  2. a need is explicitly identified (and those who have this need will
>     actively help).
>
> A release of CM 4.0 that is monolithic, targets Java 5 and contains
> unsupported code is not OK.
>
>
>> Nobody asked the latter of *you*, just to keep the code untouched
>> where you have no interest to work with.
>
>
> I already answered to that point.  Code is there; anyone can take from
> any point in its history and do whatever he pleases.
>
>
>> Nobody would stop you from working on the rest.
>
>
> You just did.
>
> As it happens you seem to acknowledge that the fork outside Apache is
> the only way to sort out the identified shortcomings of CM.
>
> Is it what you are aiming at by vetoing new components?
>
>
>>> I'm OK to go through the incubator to do that; but I don't see that it
>>> is an easier path.  Surely it looks longer.  And it seems that even the
>>> incubator people doubt that it will lead anywhere.
>>>
>>> Given the uncertain outcome, going through the incubator would be an
>>> attempt at rethinking the development of the currently unsupported
>>> code.  See e.g.
>>>    https://issues.apache.org/jira/browse/MATH-172
>>> [Or is that out of scope for an incubation proposal?]
>>
>>
>>
>> The incubator seems at least to be an option to go forward with CM.
>
>
> How is that different from the POV of Commons?
>
> This time could be better spent in rethinking the codebase in order
> to get it right (community-wise) this time.
>
> Legacy users will not upgrade to CM 4.0, whatever it contains.
> New users/contributors will not come to maintain a legacy code.
>
> CM is dead.  And we are loosing a lot of time in sterile discussions
> about scenarios that DO NOT exist (for CM).
>
>
> Gilles
>
>
>>
>> - Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Gilles Sadowski
On Sat, 18 Jun 2016 11:53:37 -0500, Matt Benson wrote:

> On Jun 18, 2016 9:28 AM, "Gilles" <[hidden email]>
> wrote:
>>
>> Hi.
>>
>>
>> On Sat, 18 Jun 2016 14:42:46 +0200, Jörg Schaible wrote:
>>>
>>> Hi Gilles,
>>>
>>> Gilles wrote:
>>>
>>>> Hi.
>>>>
>>>> On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote:
>>>>>
>>>>> Gilles,
>>>>>
>>>>> Thanks for links.
>>>>>
>>>>> I just read that (long-winded) thread and I see no consensus that
>>>>> "Commons
>>>>> project is not being interested in hosting those components".
>>>>
>>>>
>>>> In line with what I wrote previously, there isn't any consensus on
>>>> anything
>>>> within Commons.
>>>>
>>>> I'm asking, again, whether I need to initiate a VOTE that would
>>>> allow
>>>> me
>>>> to set up a workspace ("git", etc.) and transfer some code from CM
>>>> over
>>>> there.
>>>> Or can I jut do it?  [Some help with doing that is most welcome.]
>>>
>>>
>>>
>>> -1 (and this is a veto)
>>
>>
>> What are you vetoing?
>>
>> Or does this veto indeed shows to Ted that Commons refuses to create
>> new components.
>>
>>
>
> I think it is indicative of the position held by many, myself
> included,
> that a set of focused, math-related artifacts do not make sense at
> the
> Commons component level, and should be grouped as separate artifacts
> of
> Commons math or a TLP with the same basic structure.

We are getting close to the real problem.

Can we draw the conclusion, at last, that Commons Math does not make
sense in Commons?  [I'd hope so; since you make the point that even a
general functionality like random number generation would not make
sense here, then a monolithic library (with all sorts of math-related
functionalities) makes even less sense here.]

So I think that we could summarize the situation as follows:
  * -1 for new components (Commons refuses)
  * -1 for TLP (Commons refuses)
  * -1 for incubator (until the situation is "clarified")
  * -1 for no change (no committer left)


Gilles

> Matt
>
>>> Not unless the future of the existing CM is clarified and we get
> (majority
>>> ?) consensus here on the list.
>>
>>
>> What I hope is clear that any non-bug-fix release of CM 3.x is
>> without
>> me.
>>
>>
>>>>> It may be that incubation is a good thing for Commons Math, but
>>>>> it
>>>>> doesn't
>>>>> seem valid to say that incubation is necessary because CM is
>>>>> being
>>>>> kicked
>>>>> out of Commons.
>>>>
>>>>
>>>> Never said so.
>>>>
>>>> There is a confusion here: *I* say that CM is dead.
>>>>
>>>> It was dead already in early February but nobody noticed because
>>>> *I*
>>>> (alone) continued to answer the ML, comment on JIRA reports and
>>>> commit
>>>> code.
>>>>
>>>> Why I was alone doing that became clear when Luc announced his
>>>> resignation
>>>> and the fork.
>>>>
>>>> The development situation *will* change because the context *has*
>>>> changed
>>>> (unsupported code).
>>>> CM cannot go on as it did before the fork.
>>>
>>>
>>>
>>> And this is exactly the question. For me as PMC member of Commons I
>>> have
> to
>>> look at all components and it is not the first time that the
>>> original
>>> authors of a component vanishes and it won't be the last.
>>
>>
>> It's not "author" that matters, it's "maintainer".
>> [It just happens that the two were the same for a lot of the codes
>> in
>> CM (not a healthy situation indeed).]
>>
>>
>>> Either new people
>>> will stay up to carry on (there are already some new ones)
>>
>>
>> I discussed that already: counting new contributors and estimating
>> their
>> future contributions, that still leaves roughly 80% of the code
> unsupported.
>>
>>
>>> or the component
>>> is moved at some point into dormant state, because it gets obsolete
> (maybe
>>> because of the fork, future will tell).
>>>
>>> However, we care for all Commons components and their usage in the
>>> wild.
>>> Nearly all of our components are buried deep down in some software
>>> stacks
>>> and therefore we always take care to an extreme extent to
>>> compatibility
> of
>>> new releases.
>>
>>
>> Again this non-argument?
>> I answered to that countless times: Major releases are NOT REQUIRED
>> to be
>> compatible.
>>
>>
>>> With your proposal to rip CM into parts you leave the current
>>> users of CM out in the rain. *You* tell them simply to use your new
>>> shiny
>>> components A and B and for the rest they should stay at old CM
>>> (that
> still
>>> contains on top the old stuff of A and B). Sorry, but this is not a
> proper
>>> scenario for Commons.
>>
>>
>> How is that different from the scenario of any other major release?
>> Either I don't understand what you are talking about or it seems
>> that you
>> forbid any release of new code unless everything has been fixed in
>> the
> code.
>>
>> It was never the case and it makes no sense.
>>
>>
>>>> Everybody (developers, users, Commons PMC) would be better off
>>>> with a
>>>> selected set of new (supported) components because this is
>>>> something we
>>>> can easily do *now* (RERO, etc.).
>>>
>>>
>>>
>>> Again, this is *your* point of view and it is caused by *your*
>>> refusal to
>>> consider a CM release that contains the existing code base, just
>>> because
>>> this includes also code *you* cannot/will not/have no interest to
> support or
>>> maintain.
>>
>>
>> I explained my position on this.  And it is not what you state here.
>>
>> For me, a bug-fix for CM 3.x is OK if the following conditions are
>> both
>> satisfied:
>>  1. CM 4.0 is worked on actively and released, and
>>  2. a need is explicitly identified (and those who have this need
>> will
>>     actively help).
>>
>> A release of CM 4.0 that is monolithic, targets Java 5 and contains
>> unsupported code is not OK.
>>
>>
>>> Nobody asked the latter of *you*, just to keep the code untouched
>>> where you have no interest to work with.
>>
>>
>> I already answered to that point.  Code is there; anyone can take
>> from
>> any point in its history and do whatever he pleases.
>>
>>
>>> Nobody would stop you from working on the rest.
>>
>>
>> You just did.
>>
>> As it happens you seem to acknowledge that the fork outside Apache
>> is
>> the only way to sort out the identified shortcomings of CM.
>>
>> Is it what you are aiming at by vetoing new components?
>>
>>
>>>> I'm OK to go through the incubator to do that; but I don't see
>>>> that it
>>>> is an easier path.  Surely it looks longer.  And it seems that
>>>> even the
>>>> incubator people doubt that it will lead anywhere.
>>>>
>>>> Given the uncertain outcome, going through the incubator would be
>>>> an
>>>> attempt at rethinking the development of the currently unsupported
>>>> code.  See e.g.
>>>>    https://issues.apache.org/jira/browse/MATH-172
>>>> [Or is that out of scope for an incubation proposal?]
>>>
>>>
>>>
>>> The incubator seems at least to be an option to go forward with CM.
>>
>>
>> How is that different from the POV of Commons?
>>
>> This time could be better spent in rethinking the codebase in order
>> to get it right (community-wise) this time.
>>
>> Legacy users will not upgrade to CM 4.0, whatever it contains.
>> New users/contributors will not come to maintain a legacy code.
>>
>> CM is dead.  And we are loosing a lot of time in sterile discussions
>> about scenarios that DO NOT exist (for CM).
>>
>>
>> Gilles
>>
>>
>>>
>>> - Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Ted Dunning
In reply to this post by Gilles Sadowski
On Sat, Jun 18, 2016 at 4:29 AM, Gilles <[hidden email]>
wrote:

> ...
> I'm asking, again, whether I need to initiate a VOTE that would allow me
> to set up a workspace ("git", etc.) and transfer some code from CM over
> there.
>

Nothing is stopping you from setting something up.  Github is usually the
easiest way.

It doesn't sound like that is what you want, however. I don't understand
why not.


>
> It may be that incubation is a good thing for Commons Math, but it doesn't
>> seem valid to say that incubation is necessary because CM is being kicked
>> out of Commons.
>>
>
> Never said so.
>

Hmm... I must have misunderstood the comment about CM not being interested
in hosting "these components".


> There is a confusion here: *I* say that CM is dead.
>

Strong words. Such statements are often frustrating to others. It does
sound like the community has dwindled, perhaps beyond repair.

The development situation *will* change because the context *has* changed
> (unsupported code). CM cannot go on as it did before the fork.
>

You can never go home. No project stays the same.


> Everybody (developers, users, Commons PMC) would be better off with a
> selected set of new (supported) components because this is something we
> can easily do *now* (RERO, etc.).
>

This was your assertion in the long email thread. It seemed that there was
significant counter-positions.


> I'm OK to go through the incubator to do that; but I don't see that it
> is an easier path.  Surely it looks longer.  And it seems that even the
> incubator people doubt that it will lead anywhere.
>

The incubator is for building community and adapting to Apache. If you
don't have a seed community, then incubator is the wrong place. You need to
have more than just you.



>
> Given the uncertain outcome, going through the incubator would be an
> attempt at rethinking the development of the currently unsupported
> code.  See e.g.
>   https://issues.apache.org/jira/browse/MATH-172
> [Or is that out of scope for an incubation proposal?]


Incubator is not a place to rethink code. It is primarily for building
community.


>
>
>
> Gilles
>
>
> On Fri, Jun 17, 2016 at 3:35 PM, Gilles <[hidden email]>
>> wrote:
>>
>> On Fri, 17 Jun 2016 08:51:36 -0700, Ted Dunning wrote:
>>>
>>> Excuse me?
>>>>
>>>> See inline.
>>>>
>>>>
>>>>
>>>> On Fri, Jun 17, 2016 at 7:50 AM, Gilles <[hidden email]>
>>>> wrote:
>>>>
>>>> Hi all.
>>>>
>>>>>
>>>>> On Tue, 14 Jun 2016 11:01:13 -0700, Ralph Goers wrote:
>>>>>
>>>>> I thought this had been made clear.  Several months Commons voted to
>>>>>
>>>>>> make Math a TLP. But shortly after that most of the people involved
>>>>>> with Commons Math felt that a TLP at the ASF would not work for them,
>>>>>> so they forked the project and left, effectively voiding the TLP vote
>>>>>> since the proposed PMC is no longer valid.  There is one person left
>>>>>> who was very involved in Commons Math and a few other people who have
>>>>>> expressed interest in joining the new community.
>>>>>>
>>>>>> So this is a situation where we have an already existing code base
>>>>>> where a lot of the people left are not familiar with quite a bit of
>>>>>> it.  The new group of people who are interested are trying to
>>>>>> determine how they should move forward. There is some talk of breaking
>>>>>> Commons Math into smaller components and possibly dropping some where
>>>>>> there is no one to maintain it.
>>>>>>
>>>>>>
>>>>>> The "Commons" project not being interested in hosting those
>>>>> components,
>>>>> is the "incubator" a good place for the developers wishing to go in
>>>>> that
>>>>> direction?
>>>>>
>>>>>
>>>>> Perhaps before we move to next steps, could you provide some links to
>>>> the
>>>> discussion where it was decided that Commons is not interested in
>>>> hosting
>>>> these components?
>>>>
>>>>
>>> I proposed to concretely examine this possibility in more than
>>> one message:
>>>   http://markmail.org/message/ye6wvqvlvnqe4qrp
>>>   http://markmail.org/message/3gupcednhqtcfepw
>>>   http://markmail.org/message/3kob7djjicax6rgn
>>>   http://markmail.org/message/7rb2mxq7hhwzykvr
>>>
>>> And again in another thread:
>>>   http://markmail.org/message/fnlta2ttfne3aj5f
>>>
>>>
>>> What's the next step?
>>>>>
>>>>>
>>>>> Let's get to a common understanding of what went before.
>>>>
>>>>
>>> Even that seems impossible. :-(
>>>
>>>
>>> Gilles
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Gilles Sadowski
On Sat, 18 Jun 2016 11:00:34 -0700, Ted Dunning wrote:

> On Sat, Jun 18, 2016 at 4:29 AM, Gilles
> <[hidden email]>
> wrote:
>
>> ...
>> I'm asking, again, whether I need to initiate a VOTE that would
>> allow me
>> to set up a workspace ("git", etc.) and transfer some code from CM
>> over
>> there.
>>
>
> Nothing is stopping you from setting something up.  Github is usually
> the
> easiest way.
>
> It doesn't sound like that is what you want, however. I don't
> understand
> why not.

And I don't understand that Apache would indeed prefer that code be
forked
rather than evolved here...

>> It may be that incubation is a good thing for Commons Math, but it
>> doesn't
>>> seem valid to say that incubation is necessary because CM is being
>>> kicked
>>> out of Commons.
>>>
>>
>> Never said so.
>>
>
> Hmm... I must have misunderstood the comment about CM not being
> interested
> in hosting "these components".

Commons is NOT interested in hosting the new components.
That much was made clear in Matt Benson's last post. [Maybe not
cross-posted
to the incubator's ML.]

>> There is a confusion here: *I* say that CM is dead.
>>
>
> Strong words. Such statements are often frustrating to others.

Not strong, just factual.

Maybe it will be revived in the future.
Until then, I proposed to *do* something while the others seem to only
want to wait.
Strange that the latter proposal seems more acceptable than mine.

> It does
> sound like the community has dwindled, perhaps beyond repair.

It sure sounds like it.
In fewer words: CM is dead.

> The development situation *will* change because the context *has*
> changed
>> (unsupported code). CM cannot go on as it did before the fork.
>>
>
> You can never go home. No project stays the same.

Well, some people in CM for years did their best to avoid change.
I didn't like that view and argue with them because they were
important contributors to CM.

I still have to argue, but now with non-contributors.
*This* makes no sense.

>> Everybody (developers, users, Commons PMC) would be better off with
>> a
>> selected set of new (supported) components because this is something
>> we
>> can easily do *now* (RERO, etc.).
>>
>
> This was your assertion in the long email thread. It seemed that
> there was
> significant counter-positions.

By non-contributors, using arguments that do not fit the CM history.

>> I'm OK to go through the incubator to do that; but I don't see that
>> it
>> is an easier path.  Surely it looks longer.  And it seems that even
>> the
>> incubator people doubt that it will lead anywhere.
>>
>
> The incubator is for building community and adapting to Apache. If
> you
> don't have a seed community, then incubator is the wrong place. You
> need to
> have more than just you.

That's fair, but there are a few others; that was mentioned.

>>
>> Given the uncertain outcome, going through the incubator would be an
>> attempt at rethinking the development of the currently unsupported
>> code.  See e.g.
>>   https://issues.apache.org/jira/browse/MATH-172
>> [Or is that out of scope for an incubation proposal?]
>
>
> Incubator is not a place to rethink code. It is primarily for
> building
> community.

I thought so.
So, that leaves us with TLP.  Back to square one.


Gilles

>>
>>
>> On Fri, Jun 17, 2016 at 3:35 PM, Gilles
>> <[hidden email]>
>>> wrote:
>>>
>>> On Fri, 17 Jun 2016 08:51:36 -0700, Ted Dunning wrote:
>>>>
>>>> Excuse me?
>>>>>
>>>>> See inline.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jun 17, 2016 at 7:50 AM, Gilles
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> Hi all.
>>>>>
>>>>>>
>>>>>> On Tue, 14 Jun 2016 11:01:13 -0700, Ralph Goers wrote:
>>>>>>
>>>>>> I thought this had been made clear.  Several months Commons
>>>>>> voted to
>>>>>>
>>>>>>> make Math a TLP. But shortly after that most of the people
>>>>>>> involved
>>>>>>> with Commons Math felt that a TLP at the ASF would not work for
>>>>>>> them,
>>>>>>> so they forked the project and left, effectively voiding the
>>>>>>> TLP vote
>>>>>>> since the proposed PMC is no longer valid.  There is one person
>>>>>>> left
>>>>>>> who was very involved in Commons Math and a few other people
>>>>>>> who have
>>>>>>> expressed interest in joining the new community.
>>>>>>>
>>>>>>> So this is a situation where we have an already existing code
>>>>>>> base
>>>>>>> where a lot of the people left are not familiar with quite a
>>>>>>> bit of
>>>>>>> it.  The new group of people who are interested are trying to
>>>>>>> determine how they should move forward. There is some talk of
>>>>>>> breaking
>>>>>>> Commons Math into smaller components and possibly dropping some
>>>>>>> where
>>>>>>> there is no one to maintain it.
>>>>>>>
>>>>>>>
>>>>>>> The "Commons" project not being interested in hosting those
>>>>>> components,
>>>>>> is the "incubator" a good place for the developers wishing to go
>>>>>> in
>>>>>> that
>>>>>> direction?
>>>>>>
>>>>>>
>>>>>> Perhaps before we move to next steps, could you provide some
>>>>>> links to
>>>>> the
>>>>> discussion where it was decided that Commons is not interested in
>>>>> hosting
>>>>> these components?
>>>>>
>>>>>
>>>> I proposed to concretely examine this possibility in more than
>>>> one message:
>>>>   http://markmail.org/message/ye6wvqvlvnqe4qrp
>>>>   http://markmail.org/message/3gupcednhqtcfepw
>>>>   http://markmail.org/message/3kob7djjicax6rgn
>>>>   http://markmail.org/message/7rb2mxq7hhwzykvr
>>>>
>>>> And again in another thread:
>>>>   http://markmail.org/message/fnlta2ttfne3aj5f
>>>>
>>>>
>>>> What's the next step?
>>>>>>
>>>>>>
>>>>>> Let's get to a common understanding of what went before.
>>>>>
>>>>>
>>>> Even that seems impossible. :-(
>>>>
>>>>
>>>> Gilles


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Matt Benson-2
On Jun 18, 2016 2:05 PM, "Gilles" <[hidden email]> wrote:

>
> On Sat, 18 Jun 2016 11:00:34 -0700, Ted Dunning wrote:
>>
>> On Sat, Jun 18, 2016 at 4:29 AM, Gilles <[hidden email]>
>> wrote:
>>
>>> ...
>>> I'm asking, again, whether I need to initiate a VOTE that would allow me
>>> to set up a workspace ("git", etc.) and transfer some code from CM over
>>> there.
>>>
>>
>> Nothing is stopping you from setting something up.  Github is usually the
>> easiest way.
>>
>> It doesn't sound like that is what you want, however. I don't understand
>> why not.
>
>
> And I don't understand that Apache would indeed prefer that code be forked
> rather than evolved here...
>
>
>>> It may be that incubation is a good thing for Commons Math, but it
doesn't
>>>>
>>>> seem valid to say that incubation is necessary because CM is being
kicked
>>>> out of Commons.
>>>>
>>>
>>> Never said so.
>>>
>>
>> Hmm... I must have misunderstood the comment about CM not being
interested
>> in hosting "these components".
>
>
> Commons is NOT interested in hosting the new components.
> That much was made clear in Matt Benson's last post. [Maybe not
cross-posted
> to the incubator's ML.]
>

I am one person. Personally I don't understand what is so offensive to you
about retaining a hierarchical level between Commons and math-focused
artifacts; I simply feel that a preponderance of math-focused components
dilutes the Commons "brand."

br,
Matt

>
>>> There is a confusion here: *I* say that CM is dead.
>>>
>>
>> Strong words. Such statements are often frustrating to others.
>
>
> Not strong, just factual.
>
> Maybe it will be revived in the future.
> Until then, I proposed to *do* something while the others seem to only
> want to wait.
> Strange that the latter proposal seems more acceptable than mine.
>
>
>> It does
>> sound like the community has dwindled, perhaps beyond repair.
>
>
> It sure sounds like it.
> In fewer words: CM is dead.
>
>
>> The development situation *will* change because the context *has* changed
>>>
>>> (unsupported code). CM cannot go on as it did before the fork.
>>>
>>
>> You can never go home. No project stays the same.
>
>
> Well, some people in CM for years did their best to avoid change.
> I didn't like that view and argue with them because they were
> important contributors to CM.
>
> I still have to argue, but now with non-contributors.
> *This* makes no sense.
>
>
>>> Everybody (developers, users, Commons PMC) would be better off with a
>>> selected set of new (supported) components because this is something we
>>> can easily do *now* (RERO, etc.).
>>>
>>
>> This was your assertion in the long email thread. It seemed that there
was

>> significant counter-positions.
>
>
> By non-contributors, using arguments that do not fit the CM history.
>
>
>>> I'm OK to go through the incubator to do that; but I don't see that it
>>> is an easier path.  Surely it looks longer.  And it seems that even the
>>> incubator people doubt that it will lead anywhere.
>>>
>>
>> The incubator is for building community and adapting to Apache. If you
>> don't have a seed community, then incubator is the wrong place. You need
to

>> have more than just you.
>
>
> That's fair, but there are a few others; that was mentioned.
>
>
>>>
>>> Given the uncertain outcome, going through the incubator would be an
>>> attempt at rethinking the development of the currently unsupported
>>> code.  See e.g.
>>>   https://issues.apache.org/jira/browse/MATH-172
>>> [Or is that out of scope for an incubation proposal?]
>>
>>
>>
>> Incubator is not a place to rethink code. It is primarily for building
>> community.
>
>
> I thought so.
> So, that leaves us with TLP.  Back to square one.
>
>
>
> Gilles
>
>>>
>>>
>>> On Fri, Jun 17, 2016 at 3:35 PM, Gilles <[hidden email]>
>>>>
>>>> wrote:
>>>>
>>>> On Fri, 17 Jun 2016 08:51:36 -0700, Ted Dunning wrote:
>>>>>
>>>>>
>>>>> Excuse me?
>>>>>>
>>>>>>
>>>>>> See inline.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 17, 2016 at 7:50 AM, Gilles <[hidden email]
>
>>>>>> wrote:
>>>>>>
>>>>>> Hi all.
>>>>>>
>>>>>>>
>>>>>>> On Tue, 14 Jun 2016 11:01:13 -0700, Ralph Goers wrote:
>>>>>>>
>>>>>>> I thought this had been made clear.  Several months Commons voted to
>>>>>>>
>>>>>>>> make Math a TLP. But shortly after that most of the people involved
>>>>>>>> with Commons Math felt that a TLP at the ASF would not work for
them,
>>>>>>>> so they forked the project and left, effectively voiding the TLP
vote
>>>>>>>> since the proposed PMC is no longer valid.  There is one person
left
>>>>>>>> who was very involved in Commons Math and a few other people who
have
>>>>>>>> expressed interest in joining the new community.
>>>>>>>>
>>>>>>>> So this is a situation where we have an already existing code base
>>>>>>>> where a lot of the people left are not familiar with quite a bit of
>>>>>>>> it.  The new group of people who are interested are trying to
>>>>>>>> determine how they should move forward. There is some talk of
breaking
>>>>>>>> Commons Math into smaller components and possibly dropping some
where

>>>>>>>> there is no one to maintain it.
>>>>>>>>
>>>>>>>>
>>>>>>>> The "Commons" project not being interested in hosting those
>>>>>>>
>>>>>>> components,
>>>>>>> is the "incubator" a good place for the developers wishing to go in
>>>>>>> that
>>>>>>> direction?
>>>>>>>
>>>>>>>
>>>>>>> Perhaps before we move to next steps, could you provide some links
to

>>>>>>
>>>>>> the
>>>>>> discussion where it was decided that Commons is not interested in
>>>>>> hosting
>>>>>> these components?
>>>>>>
>>>>>>
>>>>> I proposed to concretely examine this possibility in more than
>>>>> one message:
>>>>>   http://markmail.org/message/ye6wvqvlvnqe4qrp
>>>>>   http://markmail.org/message/3gupcednhqtcfepw
>>>>>   http://markmail.org/message/3kob7djjicax6rgn
>>>>>   http://markmail.org/message/7rb2mxq7hhwzykvr
>>>>>
>>>>> And again in another thread:
>>>>>   http://markmail.org/message/fnlta2ttfne3aj5f
>>>>>
>>>>>
>>>>> What's the next step?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Let's get to a common understanding of what went before.
>>>>>>
>>>>>>
>>>>>>
>>>>> Even that seems impossible. :-(
>>>>>
>>>>>
>>>>> Gilles
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

RE: [ALL] Volunteers for a Math IPMC?

Dennis E. Hamilton
In reply to this post by Gilles Sadowski
Being one of the non-participants that Gilles speaks of, perhaps it is easier for me to not have any baggage that filters what I see as perfectly plain actions.

> -----Original Message-----
> From: Gilles [mailto:[hidden email]]
> Sent: Saturday, June 18, 2016 10:56
> To: [hidden email]
> Subject: Re: [ALL] Volunteers for a Math IPMC?
>
> On Sat, 18 Jun 2016 11:53:37 -0500, Matt Benson wrote:
> > On Jun 18, 2016 9:28 AM, "Gilles" <[hidden email]>
> > wrote:
> >>
> >> Hi.
> >>
> >>
> >> On Sat, 18 Jun 2016 14:42:46 +0200, Jörg Schaible wrote:
[ ... ]

> >>>> I'm asking, again, whether I need to initiate a VOTE that would
> >>>> allow
> >>>> me
> >>>> to set up a workspace ("git", etc.) and transfer some code from CM
> >>>> over
> >>>> there.
> >>>> Or can I jut do it?  [Some help with doing that is most welcome.]
> >>>
> >>>
> >>>
> >>> -1 (and this is a veto)
> >>
> >>
> >> What are you vetoing?
[orcmid]

It seems clear to me that Jörg is addressing a unilateral, individual act involving the CM code base.  Perhaps after the weekend that can be confirmed.

Committers are in a position to veto changes to the code base, and the proposed act can be seen as falling under that.  It might be good to wait and discuss the basis of the veto with Jörg and see what, if anything, would cure it.

Now, anyone can initiate a [VOTE] so that is not subject to veto.  

However, resorting to [VOTE]s appears to be a symptom of some sort of community failure.  Consensus-seeking is very important and it is odd that there is not some civil way to tease out consensus on what appears to be a sticking point.  It would be very healthy to find out where there is consensus already, perhaps on a focused [DISCUSS] or even [PROPOSAL] thread and then see what can be worked out about the sticky parts that the consensus does not extend to.

Two more observations as one of the non-participant buttinskies and I will go worry about matters in my particular area of influence:

 1. Observation: Going to TLP is not an option based on what I see here.  The community question does not get easier for TLP versus incubation.  It's not so simple as having enough initial PMC members to be able to approve a release.

 2. Observation: At the ASF, "Forking is a Feature."  It has already happened once with regard to Commons Math.  Individuals have their own concerns and attitudes and hurts about that, but the Foundation has no objection.  None.  The license allows it and it is OK.  
    Now, forking *within* Apache might seem different although I think, in this case, there is a constraint that is the same as when an external project is forked or contributed into an Apache project.  The code that is incorporated in the fork/poddling/TLP code base for an Apache project *must* be willingly offered by its origin project.  So you are now back at the previously unsolved problem: what is the consensus at Commons about what is to be done with Commons Math as it is that is actionable by those here?  Then what is encouraged with regard to active support in some other venue to the extent that Commons has any stake at all in terms of ability to act?

 - Dennis


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Jörg Schaible
In reply to this post by Gilles Sadowski
Hi Gilles,

Gilles wrote:

> Hi.
>
> On Sat, 18 Jun 2016 14:42:46 +0200, Jörg Schaible wrote:
>> Hi Gilles,
>>
>> Gilles wrote:
>>
>>> Hi.
>>>
>>> On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote:
>>>> Gilles,
>>>>
>>>> Thanks for links.
>>>>
>>>> I just read that (long-winded) thread and I see no consensus that
>>>> "Commons
>>>> project is not being interested in hosting those components".
>>>
>>> In line with what I wrote previously, there isn't any consensus on
>>> anything
>>> within Commons.
>>>
>>> I'm asking, again, whether I need to initiate a VOTE that would
>>> allow
>>> me
>>> to set up a workspace ("git", etc.) and transfer some code from CM
>>> over
>>> there.
>>> Or can I jut do it?  [Some help with doing that is most welcome.]
>>
>>
>> -1 (and this is a veto)
>
> What are you vetoing?


That someone (you) simply start to extract code from an existing component
into something new. It does not matter if I cast the veto now or after a
commit.


> Or does this veto indeed shows to Ted that Commons refuses to create
> new components.


It simply reflects that we have no consensus and therefore we cannot act one
or the other way.


>> Not unless the future of the existing CM is clarified and we get
>> (majority
>> ?) consensus here on the list.
>
> What I hope is clear that any non-bug-fix release of CM 3.x is without
> me.


Thanks that you state this so directly: We all have to do it your way or
you're gone.


[snip]


>> And this is exactly the question. For me as PMC member of Commons I
>> have to
>> look at all components and it is not the first time that the original
>> authors of a component vanishes and it won't be the last.
>
> It's not "author" that matters, it's "maintainer".
> [It just happens that the two were the same for a lot of the codes in
> CM (not a healthy situation indeed).]


The Commons components would be in a very bad shape if every *current*
maintainer of a component simple dropped the code he does not feel
responsible for.

 
>> Either new people
>> will stay up to carry on (there are already some new ones)
>
> I discussed that already: counting new contributors and estimating
> their
> future contributions, that still leaves roughly 80% of the code
> unsupported.


The code *is* released. It does not matter for which version we are asked
for support - even if we cannot provide it.


>> or the component
>> is moved at some point into dormant state, because it gets obsolete
>> (maybe
>> because of the fork, future will tell).
>>
>> However, we care for all Commons components and their usage in the
>> wild.
>> Nearly all of our components are buried deep down in some software
>> stacks
>> and therefore we always take care to an extreme extent to
>> compatibility of
>> new releases.
>
> Again this non-argument?
> I answered to that countless times: Major releases are NOT REQUIRED to
> be
> compatible.


Major releases can be used for refactoring, introducing new concepts or drop
deprecated stuff, but they will not simply drop 80% of the code.


>> With your proposal to rip CM into parts you leave the current
>> users of CM out in the rain. *You* tell them simply to use your new
>> shiny
>> components A and B and for the rest they should stay at old CM (that
>> still
>> contains on top the old stuff of A and B). Sorry, but this is not a
>> proper
>> scenario for Commons.
>
> How is that different from the scenario of any other major release?
> Either I don't understand what you are talking about or it seems that
> you
> forbid any release of new code unless everything has been fixed in the
> code.


We never managed to fix all bugs for any release of any Commons component.
That did never prevent a new release. This is your own rule.


> It was never the case and it makes no sense.
>
>>> Everybody (developers, users, Commons PMC) would be better off with
>>> a
>>> selected set of new (supported) components because this is something
>>> we
>>> can easily do *now* (RERO, etc.).
>>
>>
>> Again, this is *your* point of view and it is caused by *your*
>> refusal to
>> consider a CM release that contains the existing code base, just
>> because
>> this includes also code *you* cannot/will not/have no interest to
>> support or
>> maintain.
>
> I explained my position on this.  And it is not what you state here.
>
> For me, a bug-fix for CM 3.x is OK if the following conditions are both
> satisfied:
>   1. CM 4.0 is worked on actively and released, and
>   2. a need is explicitly identified (and those who have this need will
>      actively help).
>
> A release of CM 4.0 that is monolithic, targets Java 5 and contains
> unsupported code is not OK.


It does not have to stay monolithic, we may create a multi-project. It does
not have to target Java 5. It just may not drop 80% of the code base,
because *you* cannot support it.


>> Nobody asked the latter of *you*, just to keep the code untouched
>> where you have no interest to work with.
>
> I already answered to that point.  Code is there; anyone can take from
> any point in its history and do whatever he pleases.
>
>> Nobody would stop you from working on the rest.
>
> You just did.


No. I just stopped you for now to work on the code after you teared it out
of CM into a new component. Nobody stops you from refactoring the same
packages in CM.


> As it happens you seem to acknowledge that the fork outside Apache is
> the only way to sort out the identified shortcomings of CM.
>
> Is it what you are aiming at by vetoing new components?
>
>>> I'm OK to go through the incubator to do that; but I don't see that
>>> it
>>> is an easier path.  Surely it looks longer.  And it seems that even
>>> the
>>> incubator people doubt that it will lead anywhere.
>>>
>>> Given the uncertain outcome, going through the incubator would be an
>>> attempt at rethinking the development of the currently unsupported
>>> code.  See e.g.
>>>    https://issues.apache.org/jira/browse/MATH-172
>>> [Or is that out of scope for an incubation proposal?]
>>
>>
>> The incubator seems at least to be an option to go forward with CM.
>
> How is that different from the POV of Commons?


Because an own TLP can setup his own rules for releases.

 
> This time could be better spent in rethinking the codebase in order
> to get it right (community-wise) this time.
>
> Legacy users will not upgrade to CM 4.0, whatever it contains.


If you don't left anything in it, you're probably right.


> New users/contributors will not come to maintain a legacy code.


You make it legacy by dropping it.

 
> CM is dead.  And we are loosing a lot of time in sterile discussions
> about scenarios that DO NOT exist (for CM).


I know, you scenario is the only truth. I only have non-arguments.


- Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Jörg Schaible
In reply to this post by Gilles Sadowski
Hi Gilles,


Gilles wrote:

> On Sat, 18 Jun 2016 11:00:34 -0700, Ted Dunning wrote:
>> On Sat, Jun 18, 2016 at 4:29 AM, Gilles

[snip]

>> You can never go home. No project stays the same.
>
> Well, some people in CM for years did their best to avoid change.
> I didn't like that view and argue with them because they were
> important contributors to CM.
>
> I still have to argue, but now with non-contributors.
> *This* makes no sense.

[snip]

>> This was your assertion in the long email thread. It seemed that
>> there was
>> significant counter-positions.
>
> By non-contributors, using arguments that do not fit the CM history.


Since this is now the second time in two weeks that you indirectly state
that I should keep my mouth, I simply refer here a mail of Phil in January
2015 on the PMC list about the "PMC member responsibilities".

As such a Commons PMC member you are responsible for *all* of the
components, all its users and the health of the ecosystem these components
live.

You seem to care currently for 20% of the code of one component only
ignoring any impact on the ecosystem your action with the other 80% may
have.


>>> I'm OK to go through the incubator to do that; but I don't see that
>>> it
>>> is an easier path.  Surely it looks longer.  And it seems that even
>>> the
>>> incubator people doubt that it will lead anywhere.
>>>
>>
>> The incubator is for building community and adapting to Apache. If
>> you
>> don't have a seed community, then incubator is the wrong place. You
>> need to
>> have more than just you.
>
> That's fair, but there are a few others; that was mentioned.


Right. And therefore incubation is a good way to build an own community for
this one component only (although it is big).


>>> Given the uncertain outcome, going through the incubator would be an
>>> attempt at rethinking the development of the currently unsupported
>>> code.  See e.g.
>>>   https://issues.apache.org/jira/browse/MATH-172
>>> [Or is that out of scope for an incubation proposal?]
>>
>>
>> Incubator is not a place to rethink code. It is primarily for
>> building
>> community.
>
> I thought so.
> So, that leaves us with TLP.  Back to square one.


Just because the way *you* like to act with CM is no option for a Commons
component.

- Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Gilles Sadowski
On Sun, 19 Jun 2016 01:55:12 +0200, Jörg Schaible wrote:

> Hi Gilles,
>
>
> Gilles wrote:
>
>> On Sat, 18 Jun 2016 11:00:34 -0700, Ted Dunning wrote:
>>> On Sat, Jun 18, 2016 at 4:29 AM, Gilles
>
> [snip]
>
>>> You can never go home. No project stays the same.
>>
>> Well, some people in CM for years did their best to avoid change.
>> I didn't like that view and argue with them because they were
>> important contributors to CM.
>>
>> I still have to argue, but now with non-contributors.
>> *This* makes no sense.
>
> [snip]
>
>>> This was your assertion in the long email thread. It seemed that
>>> there was
>>> significant counter-positions.
>>
>> By non-contributors, using arguments that do not fit the CM history.
>
>
> Since this is now the second time in two weeks that you indirectly
> state
> that I should keep my mouth, I simply refer here a mail of Phil in
> January
> 2015 on the PMC list about the "PMC member responsibilities".
>
> As such a Commons PMC member you are responsible for *all* of the
> components, all its users and the health of the ecosystem these
> components
> live.

This is a pretext.

Don't pretend that you don't know how unrealistic it is to expect that
anyone will be able to care for all the components.

You didn't move when the situation required it (when I explicitly asked
for the PMC to intervene), so please don't try to teach me a lesson
now!

> You seem to care currently for 20% of the code of one component only
> ignoring any impact on the ecosystem your action with the other 80%
> may
> have.

I'm fed up with the smearing.

My "action" has ZERO impact on Commons Math.
It is dead because people (who wanted it to be what it is) have left.

"Commons Math" will stay 100% clean of any interaction with me.

I advocated for a reboot of the codebase, with the long-term goal to
provide a sustainable service to a community of users potentially
interested in a (modern) Java scientific library.

Of course, I'm not going to veto people who'd like to commit fixes
in the "3.x" line.  I repeated that several times now.
However, have I the right to not want to do it myself?

>>>> I'm OK to go through the incubator to do that; but I don't see
>>>> that
>>>> it
>>>> is an easier path.  Surely it looks longer.  And it seems that
>>>> even
>>>> the
>>>> incubator people doubt that it will lead anywhere.
>>>>
>>>
>>> The incubator is for building community and adapting to Apache. If
>>> you
>>> don't have a seed community, then incubator is the wrong place. You
>>> need to
>>> have more than just you.
>>
>> That's fair, but there are a few others; that was mentioned.
>
>
> Right. And therefore incubation is a good way to build an own
> community for
> this one component only (although it is big).

Ted Dunning said that this is not a job for the Incubator, because the
problem is not the missing community.  It is the Commons PMC not
willing
to let go of the code.

>>>> Given the uncertain outcome, going through the incubator would be
>>>> an
>>>> attempt at rethinking the development of the currently unsupported
>>>> code.  See e.g.
>>>>   https://issues.apache.org/jira/browse/MATH-172
>>>> [Or is that out of scope for an incubation proposal?]
>>>
>>>
>>> Incubator is not a place to rethink code. It is primarily for
>>> building
>>> community.
>>
>> I thought so.
>> So, that leaves us with TLP.  Back to square one.
>
>
> Just because the way *you* like to act with CM is no option for a
> Commons
> component.

No, because of the way *you* acted in response to my wish to work
on what I deem feasible.  And you didn't come up with something
better than "let's wait and see", which is not an option anymore
(because I've *already* done that, for 6 months, and saw that it
didn't work).


Gilles


> - Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Niall Pemberton
In reply to this post by Gilles Sadowski
On Sat, Jun 18, 2016 at 6:56 PM, Gilles <[hidden email]>
wrote:

> On Sat, 18 Jun 2016 11:53:37 -0500, Matt Benson wrote:
>

>> I think it is indicative of the position held by many, myself included,
>> that a set of focused, math-related artifacts do not make sense at the
>> Commons component level, and should be grouped as separate artifacts of
>> Commons math or a TLP with the same basic structure.
>>
>
> We are getting close to the real problem.
>
> Can we draw the conclusion, at last, that Commons Math does not make
> sense in Commons?  [I'd hope so; since you make the point that even a
> general functionality like random number generation would not make
> sense here, then a monolithic library (with all sorts of math-related
> functionalities) makes even less sense here.]
>
> So I think that we could summarize the situation as follows:
>  * -1 for new components (Commons refuses)
>  * -1 for TLP (Commons refuses)
>  * -1 for incubator (until the situation is "clarified")
>  * -1 for no change (no committer left)


There are two routes to a Math TLP - either directly (by board resolution)
or via the Incubator. No-one here can veto either of those routes and with
both routes the first thing to do would be to put together a proposal [1].
The ASF board decides whether they will accept the "direct to TLP" route -
and its usually based on having an existing experienced viable community.
If thats not possible, then the route through the incubator is the
alternative. Either way, you need to gather the people interested and write
a proposal, which from the various threads looks like the following:

 - Gilles Sadowski
 - James Carmen
 - Gary Gregory   http://markmail.org/message/ydtkgvazec5bhzdk
 - Jochen Weidman   http://markmail.org/message/gbfqfppf4u3unqo4
 - Rob Tomkins   http://markmail.org/message/suq3ihvuqppinspf
 - Eric Barnhill   http://markmail.org/message/6wgf5rtcario2teb
 - Artem Barger   http://markmail.org/message/akfekuxp5ujyhbr3

Is there anyone else?

Niall

[1] http://incubator.apache.org/guides/proposal.html


>
>
>
> Gilles
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Jörg Schaible
In reply to this post by Gilles Sadowski
Hi Gilles,

Gilles wrote:

> On Sun, 19 Jun 2016 01:55:12 +0200, Jörg Schaible wrote:
>> Hi Gilles,
>>
>>
>> Gilles wrote:
>>
>>> On Sat, 18 Jun 2016 11:00:34 -0700, Ted Dunning wrote:
>>>> On Sat, Jun 18, 2016 at 4:29 AM, Gilles
>>
>> [snip]
>>
>>>> You can never go home. No project stays the same.
>>>
>>> Well, some people in CM for years did their best to avoid change.
>>> I didn't like that view and argue with them because they were
>>> important contributors to CM.
>>>
>>> I still have to argue, but now with non-contributors.
>>> *This* makes no sense.
>>
>> [snip]
>>
>>>> This was your assertion in the long email thread. It seemed that
>>>> there was
>>>> significant counter-positions.
>>>
>>> By non-contributors, using arguments that do not fit the CM history.
>>
>>
>> Since this is now the second time in two weeks that you indirectly
>> state
>> that I should keep my mouth, I simply refer here a mail of Phil in
>> January
>> 2015 on the PMC list about the "PMC member responsibilities".
>>
>> As such a Commons PMC member you are responsible for *all* of the
>> components, all its users and the health of the ecosystem these
>> components
>> live.
>
> This is a pretext.
>
> Don't pretend that you don't know how unrealistic it is to expect that
> anyone will be able to care for all the components.


It *not* unrealistic. But it seems that we have a totally different view of
what it means to "care". It you pretend "care" as support any of the
components into detail, then you're right. But as said before, nobody
expects that.


> You didn't move when the situation required it (when I explicitly asked
> for the PMC to intervene), so please don't try to teach me a lesson
> now!


I do this as long as you disqualify other views based on contributions and
therefore disrespecting the role of the Commons PMC. And I let it
uncommented the first time.


>> You seem to care currently for 20% of the code of one component only
>> ignoring any impact on the ecosystem your action with the other 80%
>> may
>> have.
>
> I'm fed up with the smearing.
>
> My "action" has ZERO impact on Commons Math.
> It is dead because people (who wanted it to be what it is) have left.
>
> "Commons Math" will stay 100% clean of any interaction with me.


You mean, there's suddenly no CM 4.0? Now I am confused.


> I advocated for a reboot of the codebase, with the long-term goal to
> provide a sustainable service to a community of users potentially
> interested in a (modern) Java scientific library.
>
> Of course, I'm not going to veto people who'd like to commit fixes
> in the "3.x" line.  I repeated that several times now.
> However, have I the right to not want to do it myself?


Absolutely. Again, nobody expects from you that you bug fix code you're not
interested in.


>>>>> I'm OK to go through the incubator to do that; but I don't see
>>>>> that
>>>>> it
>>>>> is an easier path.  Surely it looks longer.  And it seems that
>>>>> even
>>>>> the
>>>>> incubator people doubt that it will lead anywhere.
>>>>>
>>>>
>>>> The incubator is for building community and adapting to Apache. If
>>>> you
>>>> don't have a seed community, then incubator is the wrong place. You
>>>> need to
>>>> have more than just you.
>>>
>>> That's fair, but there are a few others; that was mentioned.
>>
>>
>> Right. And therefore incubation is a good way to build an own
>> community for
>> this one component only (although it is big).
>
> Ted Dunning said that this is not a job for the Incubator, because the
> problem is not the missing community.  It is the Commons PMC not
> willing
> to let go of the code.


Well, he had now two votes for Math TLP. Actually I don't know either, why
it does not proceed. Main concern seems to that the community is currently
still too small. But see Niall's response. At least the TLP will give you a
chance to reboot the code base completely.

[snip]


>> Just because the way *you* like to act with CM is no option for a
>> Commons
>> component.
>
> No, because of the way *you* acted in response to my wish to work
> on what I deem feasible.


And again, I am not the only one here who has no problem with releasing
again already released code independently if someone can currently support
it (they way you define "support") or if it has know bugs. It's just that
you refuse to act with such a handicap.


> And you didn't come up with something
> better than "let's wait and see", which is not an option anymore
> (because I've *already* done that, for 6 months, and saw that it
> didn't work).


I would not say that, it is just now that this topic has attention. And new
people stepped up now.


- Jörg


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Ralph Goers
In reply to this post by Niall Pemberton
This thread seems to have died. I am confused why no proposal has been created. 7 people is certainly enough to propose something. Or is the desire simply to remain a subproject of Commons?

Ralph

> On Jun 18, 2016, at 7:08 PM, Niall Pemberton <[hidden email]> wrote:
>
> On Sat, Jun 18, 2016 at 6:56 PM, Gilles <[hidden email]>
> wrote:
>
>> On Sat, 18 Jun 2016 11:53:37 -0500, Matt Benson wrote:
>>
>
>>> I think it is indicative of the position held by many, myself included,
>>> that a set of focused, math-related artifacts do not make sense at the
>>> Commons component level, and should be grouped as separate artifacts of
>>> Commons math or a TLP with the same basic structure.
>>>
>>
>> We are getting close to the real problem.
>>
>> Can we draw the conclusion, at last, that Commons Math does not make
>> sense in Commons?  [I'd hope so; since you make the point that even a
>> general functionality like random number generation would not make
>> sense here, then a monolithic library (with all sorts of math-related
>> functionalities) makes even less sense here.]
>>
>> So I think that we could summarize the situation as follows:
>> * -1 for new components (Commons refuses)
>> * -1 for TLP (Commons refuses)
>> * -1 for incubator (until the situation is "clarified")
>> * -1 for no change (no committer left)
>
>
> There are two routes to a Math TLP - either directly (by board resolution)
> or via the Incubator. No-one here can veto either of those routes and with
> both routes the first thing to do would be to put together a proposal [1].
> The ASF board decides whether they will accept the "direct to TLP" route -
> and its usually based on having an existing experienced viable community.
> If thats not possible, then the route through the incubator is the
> alternative. Either way, you need to gather the people interested and write
> a proposal, which from the various threads looks like the following:
>
> - Gilles Sadowski
> - James Carmen
> - Gary Gregory   http://markmail.org/message/ydtkgvazec5bhzdk
> - Jochen Weidman   http://markmail.org/message/gbfqfppf4u3unqo4
> - Rob Tomkins   http://markmail.org/message/suq3ihvuqppinspf
> - Eric Barnhill   http://markmail.org/message/6wgf5rtcario2teb
> - Artem Barger   http://markmail.org/message/akfekuxp5ujyhbr3
>
> Is there anyone else?
>
> Niall
>
> [1] http://incubator.apache.org/guides/proposal.html
>
>
>>
>>
>>
>> Gilles
>>
>>



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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Volunteers for a Math IPMC?

Benson Margulies
On Wed, Jun 22, 2016 at 3:28 PM, Ralph Goers <[hidden email]> wrote:
> This thread seems to have died. I am confused why no proposal has been created. 7 people is certainly enough to propose something. Or is the desire simply to remain a subproject of Commons?

I diagnose some authority confusion here. I fear that some people
think that since some members of the commons PMC made negative remarks
about the TLP strategy, that the strategy is '-1'd. While the board is
undoubtedly interested in the view of the commons PMC of a Math TLP, a
single -1 of a commons PMC member would not, I bet, be a veto.

So I'd join you in encouraging this group to write the proposal and
engage with the board. That's the clearest way to identify a
distinctive Math community and allow that community to get to work
independently of all the other currents in commons.


>
> Ralph
>
>> On Jun 18, 2016, at 7:08 PM, Niall Pemberton <[hidden email]> wrote:
>>
>> On Sat, Jun 18, 2016 at 6:56 PM, Gilles <[hidden email]>
>> wrote:
>>
>>> On Sat, 18 Jun 2016 11:53:37 -0500, Matt Benson wrote:
>>>
>>
>>>> I think it is indicative of the position held by many, myself included,
>>>> that a set of focused, math-related artifacts do not make sense at the
>>>> Commons component level, and should be grouped as separate artifacts of
>>>> Commons math or a TLP with the same basic structure.
>>>>
>>>
>>> We are getting close to the real problem.
>>>
>>> Can we draw the conclusion, at last, that Commons Math does not make
>>> sense in Commons?  [I'd hope so; since you make the point that even a
>>> general functionality like random number generation would not make
>>> sense here, then a monolithic library (with all sorts of math-related
>>> functionalities) makes even less sense here.]
>>>
>>> So I think that we could summarize the situation as follows:
>>> * -1 for new components (Commons refuses)
>>> * -1 for TLP (Commons refuses)
>>> * -1 for incubator (until the situation is "clarified")
>>> * -1 for no change (no committer left)
>>
>>
>> There are two routes to a Math TLP - either directly (by board resolution)
>> or via the Incubator. No-one here can veto either of those routes and with
>> both routes the first thing to do would be to put together a proposal [1].
>> The ASF board decides whether they will accept the "direct to TLP" route -
>> and its usually based on having an existing experienced viable community.
>> If thats not possible, then the route through the incubator is the
>> alternative. Either way, you need to gather the people interested and write
>> a proposal, which from the various threads looks like the following:
>>
>> - Gilles Sadowski
>> - James Carmen
>> - Gary Gregory   http://markmail.org/message/ydtkgvazec5bhzdk
>> - Jochen Weidman   http://markmail.org/message/gbfqfppf4u3unqo4
>> - Rob Tomkins   http://markmail.org/message/suq3ihvuqppinspf
>> - Eric Barnhill   http://markmail.org/message/6wgf5rtcario2teb
>> - Artem Barger   http://markmail.org/message/akfekuxp5ujyhbr3
>>
>> Is there anyone else?
>>
>> Niall
>>
>> [1] http://incubator.apache.org/guides/proposal.html
>>
>>
>>>
>>>
>>>
>>> Gilles
>>>
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

12