Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.212.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=IltSW3mvq+d7DTFwYwJfKTjxo6kXAyzNvtngqibaOu2HFmuc/Jl2lUWGKypll5FmzJ
         B4/Lh6Osay9Dz6rwHKRdcBTSLxpAYlwtSnZ5r1VBNGqgrGH/r+EeP8jqavRO3oSaKend
         RcjLUA9oxFDGKVy9td0TOOEIyUuutwJlpJtRU=
Message-ID: <4D55A2DF.4080103@gmail.com>
Date: Fri, 11 Feb 2011 15:58:07 -0500
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] the 2.2 release saga conclusion ?
References: <4D5576B4.8080203@free.fr> <4D557ADF.3090407@gmail.com>
 <4D5585C7.5000102@free.fr> <4D558CAD.4090006@gmail.com>
 <4D5595F6.4070907@free.fr> <4D559D42.7030806@gmail.com>
 <4D559F39.1030405@free.fr>
In-Reply-To: <4D559F39.1030405@free.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 2/11/11 3:42 PM, Luc Maisonobe wrote:
> Le 11/02/2011 21:34, Phil Steitz a écrit :
>> On 2/11/11 3:03 PM, Luc Maisonobe wrote:
>>> Le 11/02/2011 20:23, Phil Steitz a écrit :
>>>> On 2/11/11 1:53 PM, Luc Maisonobe wrote:
>>>>> Le 11/02/2011 19:07, Phil Steitz a écrit :
>>>>>> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I would like to have 2.2 out as soon as possible. I would like to
>>>>>>> propose yet another intermediate solution, not a perfect one, but trying
>>>>>>> to mitigate everything that has been said here. Remember this is *only*
>>>>>>> for 2.2 and it does *not* mean anything about 3.0 or any further
>>>>>>> discussions.
>>>>>>>
>>>>>>> So I propose we release 2.2 with the following changes relative to what
>>>>>>> is currently in the repository:
>>>>>>>
>>>>>>>  - change FunctionEvaluationException, DerivativeException and
>>>>>>>    MatrixVisitorException to unchecked again by making them
>>>>>>>    extend o.a.c.math.exception.MathUserException
>>>>>>>  - change ConvergenceException to unchecked by making it extend
>>>>>>>    o.a.c.math.exception.MathIllegalStateException
>>>>>>>  - undeprecate all these exceptions
>>>>>>>  - accept the 17 CLIRR errors remaining after these changes
>>>>>>>    (13 related to exceptions, 4 related to ODE)
>>>>>>>  - accept the 30 CLIRR warnings remaining after these changes
>>>>>>>    (all of them related to exceptions)
>>>>>>>  - accept the 422 CLIRR infos remaining after these changes
>>>>>>>
>>>>>>> This is by no means a perfect solution, I really tried to reach a
>>>>>>> compromise between several points of view. As each compromise, everyone
>>>>>>> would have something to tell against it but please don't start another
>>>>>>> lengthy discussion and even less a flame war. There is no hidden
>>>>>>> intention behind this and the choices presented would be put only in 2.2
>>>>>>> branch, not in trunk. The only intention is to be able to publish 2.2.
>>>>>>>
>>>>>>> What do you think ?
>>>>>>>
>>>>>> Can you create a Clirr report showing the issues above and put it in
>>>>>> ~luc so we can all look at it?
>>>>> Yes, I have put it there:
>>>>> <http://people.apache.org/~luc/clirr-report.html>.
>>>>>
>>>>>> Also, what would it take to fully eliminate the exceptions-related
>>>>>> errors?
>>>>> This would mean going back to checked exception as most errors are
>>>>> "Removed org.apache.commons.math.MathException from the list of
>>>>> superclasses"
>>>> So from the user perspective, the compatibility issue is that code
>>>> that catches MathException will in some cases propagate runtime
>>>> exceptions instead.   This sounds ridiculous, but what would be the
>>>> implications of just reverting the hierarchy so catching
>>>> MathException would work as before, but make MathException itself
>>>> unchecked?
>>> This could be done. I sincerely simply did not think about it.
>>>
>>>> Sorry if this seems to be walking into the kind of discussion you
>>>> did not want to reopen at this point; but I am just trying to see
>>>> what we might be able to do to prevent users having to make code
>>>> changes to have their apps that use 2.1 work safely in 2.2.
>>> I would say we can't do anything. There are the ODE changes which are
>>> flagged as errors by CLIRR even for things which clearly do not belong
>>> to the public API like private fields having been replaced. There are
>>> also the 2.1 tests that Sebb checked against 2.2 and which fail due to
>>> other changes which are not flagged at all by CLIRR because they are
>>> semantic changes.
>>>
>> What if we reverted all of the incompatible changes other than those
>> required to fix the ODE bug?  That would mean
>>
>> 1. Revert changes in exception hierarchy
>> 2. Revert semantic changes in equals that Sebb flagged
>> 3. Anything else?
>>
>> I honestly don't recall anything else and we could look through the
>> tickets to verify no other semantic changes
>>>> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
>>>> am fine releasing as is.
>>> 2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad
>>> idea as it would imply telling to users « we have done great changes,
>>> look at them » to only change everything again.
>>>
>>> Current 3.0 is more in line with what we want. It will certainly not be
>>> perfect either, but much better.
>>>
>>> So rather than patching this mess once again, we could simply drop 2.2
>>> completely and concentrate our efforts in 3.0 to be able to publish it
>>> soon. However, this is not an easy decision. As some of you already
>>> know, and as Gary said in his interview recently, we have some great
>>> news to publish about some uses of [math]. Dropping 2.2 and waiting
>>> months for 3.0 would be really really bad for this.
>>>
>>> The alternative is therefore:
>>>  - do we publish a 2.2 that is clumsy but fixes many important bugs
>>>    and introduces some incompatibilities
>>>  - do we consider we can publish 3.0 in the next two months so we
>>>    can afford dropping 2.2
>>>
>>> Please, choose one option and stick to it. I am exhausted and depressed,
>>> I don't want to argue anymore.
>>>
>> I am really sorry about this, Luc.  I should have complained more
>> about the incompatible changes as they were introduced.  We now have
>> a mess to clean up and I have to take the lion's share of the blame
>> for that.  So I will volunteer to do the compatability-restoring
>> changes if we can agree to them and get a 2.2 RC that has only the
>> ODE issue (which looks minor, from a user standpoint).   Would you
>> be OK with a third alternative, which is release 2.2 with only the
>> ODE incompatibility?
> Yes.
>
Great.  As long as others are OK with this, I will get to work on
this this weekend.

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


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