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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
