Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 13 Oct 2016 01:10:09 +0200
From: Gilles <gilles@harfang.homelinux.org>
To: <dev@commons.apache.org>
Subject: Re: [Math] Changes on the 3.x line
In-Reply-To: <ntlrag$jhg$1@blaine.gmane.org>
References: <b83d6be857e613a5eeb3f28c250ef0b7@scarlet.be>
 <7cfac90c-4f0a-ebca-0391-561ef78fa7bd@apache.org>
 <033e6bc251cf574c9a0a5873e6b989d8@scarlet.be>
 <ntlrag$jhg$1@blaine.gmane.org>
Message-ID: <1e812ac2060d9293430e93043e041b68@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: hel; whitelist
X-Virus-Scanned: clamav-milter 0.98.1-exp at hel
X-Virus-Status: Clean
archived-at: Wed, 12 Oct 2016 23:10:21 -0000

On Wed, 12 Oct 2016 19:18:50 +0200, Jörg Schaible wrote:
> Hi Gilles,
>
> Gilles wrote:
>
>> On Wed, 12 Oct 2016 16:57:03 +0200, Emmanuel Bourg wrote:
>>> Le 12/10/2016 à 16:15, Gilles a écrit :
>>>
>>>> The 3.x line is obsolete.
>>>> No new feature or bug-fix should be introduced there.
>>>
>>> Hi Gilles,
>>>
>>> I understand you don't want to invest time in maintaining the 3.x
>>> line
>>> and I respect that, but others might be interested. I don't think
>>> pushing minor bug fixes to CM 3 will undermine CM 4.
>>
>> Work on 3.X did undermine CM4.
>>
>> [The problem here is that you want me to be synthetic, but you
>> seem to have no clue about the history, thereby forcing me to
>> recollect facts from the past, because you don't believe my
>> synthetic statement above.]
>>
>> So, what you say in substance is that you'd rather _wait_ for
>> someone to come by who will want to work with you on 3.x, rather
>> than continue with people, here and now, a work (CM4) that
>> started more than 3 years ago.
>
> No, that's not what Emmanuel said, that's what you have implied. Your 
> plan
> is still valid to extract parts of the code base into own smaller
> components. Once that components are created, we can deprecate the 
> extracted
> code in the CM3 code base and have a release. That's what we should 
> do for
> our existing users.

IIRC, many PMC members did not "like" the idea of having more
components.
Even less so if those components are being extracted from Commons
Math.
The least "problematic" one, Commons RNG, barely collected the
number of required votes for a release.

Has that changed?
Shall we request git repositories for the candidate components
which I suggested back in May?

> You made it very clear that you have no intention to put any 
> additional
> effort into CM3. Fine. And most of us will agree that CM4 is dead. 
> But that
> does not prevent any other committer from maintaining the CM3 line 
> i.e.
> applying bug fixes or small improvements as long as binary 
> compatibility is
> ensured.
>
>> There is no sufficient manpower to work on both (cf. the backlog
>> of issues). [There wasn't before, and the situation did not
>> improve after the fork.]
>
> Obviously some work was done.
>
>> It will be a waste for everyone if we split the already scarce
>> resources to work on the two lines, of which the 3.x line will
>> always be a "sub-Hipparchus".
>
> Noone wastes *your* time ;-)

Let me assure you that plenty of my time has been wasted.
First and foremost because I continued the maintenance of
CM4 for months.
Then because I had to argue for salvaging some CM4 codes
(rather than simply "do it" as Apache would have it).

Of course, you can say that its my fault, and it is; that
I should not have tried to convince people, and should
have left, like others did.

>> In some areas/packages, code in the CM4 is still the same as
>> in 3.x.  And there is no one left in Commons that would want
>> to significantly modify those areas, for which I have no qualms
>> if you maintain them in 3.x.
>>
>> In areas where major changes were introduced in the development
>> branch, my proposal is still that we try to split them off CM
>> (see rationale in my posts sent in May).
>>
>> Commits should be done either in the 3.x line or in master, but
>> not both.
>
> This depends on the fact what code base you intent to extract for a 
> new
> component. Fixing code that exists in CM3 as well as in CM4 and that 
> is
> target for a new component is IMHO completely valid as long as the 
> new
> component does not yet exist. It is not clear in any case whether 
> your
> intention is to extract the code from CM3 or CM4,

Sorry, but CM4 is obviously the up-to-date code. See the log.
It would make no sense to "extract" anything from CM3.

[It should be ensured indeed that all fixes are consistently
applied to either the component, or the legacy code.]

> but after all it should
> contain the bug fix.

Sure.
That's why I asked for a constructive discussion on "legacy code"
(CM3-compatible) vs "new components" (extracted from CM master).

>> Can we agree on a list of legacy packages (maintained in 3.x),
>> and a list of actively modified ones (worked on in master, in
>> view of releasing them as independent tools)?
>
> This list is obvious when all extracted code is marked as deprecated.

A circular argument: Some decision must be made to start working,
and to deprecate codes.

As far as CM code is concerned, PMC members, even those who do
not contribute, should either support the creation of new
components), or propose alternatives (e.g. volunteer to
actively maintain CM3).
An attitude that amounts to block whatever work is being done
(in the way of not voting a release) does not qualify as
"management".

Regards,
Gilles

>
> Cheers,
> Jörg
>
>


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