commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL] Volunteers for a Math IPMC?
Date Sat, 18 Jun 2016 14:28:45 GMT
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message