On Jun 18, 2016 9:28 AM, "Gilles" <gil...@harfang.homelinux.org> 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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
