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: Wed, 03 Feb 2016 23:43:26 +0100
From: Gilles <gilles@harfang.homelinux.org>
To: <dev@commons.apache.org>
Subject: Re: [math] Name of the new TLP
In-Reply-To: <AD3DDD56-D8F8-4195-8A47-C7A843F0EF0C@dslextreme.com>
References: <56A53D38.30306@gmail.com>
 <CAPmHmDTgxj5ZgHuVQJk+jACo89eOYAcSOSfx4vLS=dv7ZXa2ug@mail.gmail.com>
 <CACZkXPzzhAeq==sp+tsnOvEt7GP1sU7pb=wyYqFn0LN7_yWCsg@mail.gmail.com>
 <e75ce6f0183ad8586e240346de53d26d@scarlet.be>
 <CACxRNRMbBYvZg47Q8nFiKzzK1BsOJtYEPYAxfSNDaRLbJVp4-g@mail.gmail.com>
 <CAGYFOCQnFHZrfAkfzO575BeShC8j_ddghK4=Ym0HrnBs3RVbug@mail.gmail.com>
 <109daf5bc5286e7a30a477e63e4097a9@scarlet.be>
 <CACZkXPxaPDd44UgJyuzxwYjCCC2K9NL-O7TPCfEBoAeMAK-CGw@mail.gmail.com>
 <92bcc15fa5bc63e155b92c5fc8fc29ef@scarlet.be>
 <AD3DDD56-D8F8-4195-8A47-C7A843F0EF0C@dslextreme.com>
Message-ID: <56784e397cee14afcb19136515e0fee7@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: eir; whitelist
X-Virus-Scanned: clamav-milter 0.98.1-exp at eir
X-Virus-Status: Clean

On Wed, 3 Feb 2016 08:58:19 -0700, Ralph Goers wrote:
> Just my 2 cents.
>
> When HttpClient left Commons I believe they took that opportunity to
> re-architect their code. In the end I think it paid off,

Thanks for mentioning it.
I indeed see the move as a similar opportunity.

> but for quite
> I while lots of folks (myself included) continued using Commons
> HttpClient because the new version was regarded as immature.

That would be fine, I think.
I indirectly suggested as much by saying that people who are
happy with older versions Commons Math don't need to upgrade.
It remains to define a sustainable bug-fixing policy for these
old versions.

> They
> also wanted to widen their scope a bit so they went from Apache
> Commons HttpClient to Apache Http Components.
>
> I don’t contribute to or use Apache Math myself, but given my
> experience with HttpClient I would say that using a name that strays
> very far from Math would be doing yourselves a disservice.  It is a
> bit of a stretch to expect people to remember that Commons Math is 
> now
> Apache Aardvark or some other obscure name when the one you have is
> pretty much perfect. The only way people will find you is via a link
> on the Commons home page whereas math.apache.org
> <http://math.apache.org/> just makes sense & is easy to remember.

That's a valid argument, just not the only one.
IMO, a change of name would have been a good opportunity to stress a
change in the development management.
Keeping the same name seems to announce similar "change but no change"
for other issues that have been stagnant for years.  I hope that the
(near) future will prove my fear was not justified.

Regards,
Gilles

> Ralph
>
>
>
>
>> On Feb 2, 2016, at 8:29 PM, Gilles <gilles@harfang.homelinux.org> 
>> wrote:
>>
>> On Tue, 2 Feb 2016 18:52:24 -0800, Gary Gregory wrote:
>>> On Tue, Feb 2, 2016 at 6:24 PM, Gilles 
>>> <gilles@harfang.homelinux.org> wrote:
>>>
>>>> On Wed, 3 Feb 2016 12:11:24 +1100, Peter Ansell wrote:
>>>>
>>>>> On 3 February 2016 at 11:30, Patrick Meyer <meyerjp3@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> The Apache commons math library already has a reputation and is 
>>>>>> well
>>>>>> kvown.
>>>>>> Any name that does not involve the words Apache and math will 
>>>>>> require a
>>>>>> lot
>>>>>> of rebranding or years of explaining to people that the TLP 
>>>>>> named X is
>>>>>> really just the library formerly known as commons math. Removing
>>>>>> "commons"
>>>>>> from the name is a good way to signal the maturity of the math 
>>>>>> library
>>>>>> while staying true to its Apache origin. That's why I like 
>>>>>> Apache math.
>>>>>>
>>>>>
>>>>> I don't think that outside of the Apache developer community that 
>>>>> the
>>>>> "Commons" reference is taken to mean immaturity. If anything, it 
>>>>> is
>>>>> taken to mean something that is stable and fairly slow to evolve 
>>>>> and
>>>>> hence can be reused fairly broadly (per the tight scopes of each 
>>>>> of
>>>>> the modules).
>>>>>
>>>>
>>>> Indeed.
>>>> And if establishing is going to serve anything, it is IMHO 
>>>> certainly
>>>> not to be stuck with an a priori reputation of "being stable and 
>>>> fairly
>>>> slow to evolve".
>>>>
>>>> Commons Math has been steadily growing, with less and less 
>>>> consideration
>>>> for evolving with the language which it uses. IMO, that means, 
>>>> among other
>>>> things, less and less hope to attract new contributors.
>>>> Being a TLP is by itself not going to change that.
>>>>
>>>> If anything, the new project should mean a radical departure of 
>>>> being
>>>> stable wrt the latest release.
>>>>
>>>> For users that don't care for new features and are happy with CM 
>>>> 3.6,
>>>> no problem; until they find a bug. What happens then should be 
>>>> discussed
>>>> as soon as possible, as the default policy has been to support 
>>>> only the
>>>> latest release.
>>>>
>>>> To change that, more people are needed to maintain legacy code 
>>>> while
>>>> not hindering development, including major refactoring to 
>>>> modernize
>>>> the code.
>>>>
>>>> FWIW, the word "Math" on its own is fairly geographically 
>>>> localised.
>>>>> The base word Mathematics is less localised. However, given that 
>>>>> the
>>>>> module has always been known as "Math", there are no qualms from 
>>>>> me in
>>>>> staying with that term.
>>>>>
>>>>
>>>> Staying with the old name is much less of a problem than staying
>>>> with the old ways.
>>>>
>>>
>>> Which "old ways"? I certainly hope you do not plan on shooting 
>>> yourself in
>>> the foot by breaking BC on purpose.
>>>
>>> Gary
>>>
>>
>> IIRC, BC has never been broken in the last 7+ years, thanks to 
>> changing the
>> package name.
>> Yet this non-issue comes back every time I indicate that a project 
>> like CM
>> cannot be based on the postulate that refactoring is never needed.
>> The package name changes, hence the whole library can change while 
>> BC being
>> still safe.
>>
>> The old ways are that the default is that the same code gets 
>> transported to
>> the new package so that users can use old code in new clothes, just 
>> applying
>> a trivial search and replace.
>> That's (relatively) fine when all the current developers agree that 
>> no
>> better alternative can be provided for the next release.
>> When a problem has been identified, the new release should be taken 
>> as an
>> opportunity to solve it, even if it implies refactoring (and thus a 
>> major
>> release). [Someone said that we won't run out of release numbers.]
>>
>> If an identified need for bridging between old and new design 
>> arises, it
>> will be more interesting to find a way to achieve that, rather than 
>> having
>> to beg for every change on the assumption that some unknown user 
>> might be
>> unduly, affected by the evolution of the library (which is not true 
>> if the
>> package name has changed).
>>
>> Having multiple JARs would also alleviate the tension (provided that 
>> we drop
>> the postulate that everything should be "stable").
>>
>>
>> Gilles


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