commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] releasing 2.0 ?
Date Sun, 05 Apr 2009 02:34:25 GMT
sebb wrote:
> On 04/04/2009, Phil Steitz <phil.steitz@gmail.com> wrote:
>   
>> sebb wrote:
>>
>>     
>>> On 04/04/2009, Phil Steitz <phil.steitz@gmail.com> wrote:
>>>
>>>
>>>       
>>>> Luc Maisonobe wrote:
>>>>
>>>>
>>>>
>>>>         
>>>>> Hello,
>>>>>
>>>>> A lot of work has been done on [math] last months.
>>>>> There are 9 issues still open in Jira with a target set to 2.0. Some
>>>>>           
>> of
>>     
>>>>> them have already been almost processed, some could be finished soon,
>>>>> some could be postponed to 2.1.
>>>>>
>>>>> What do you think about preparing to release 2.0 in the next few weeks
>>>>>           
>> ?
>>     
>>>>> I volunteer to do the realese work. For those of you who have taken
>>>>>           
>> the
>>     
>>>>> burden of the remaining issues, do you intend to complete your work on
>>>>> them or do you prefer I assign them to me and close what I can do ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>  I am +1 on pushing out 2.0.   Here are some comments on the issues
>>>>         
>> assigned
>>     
>>>> to me.  My geologic-time progress is unfortunately not likely to improve
>>>> over the next couple of weeks, so I am more than happy to let others
>>>>         
>> jump
>>     
>>>> in.
>>>>
>>>>
>>>>         
>>> Math is now dependent on Java 1.5 (according to the pom), but there
>>> seem to be quite a few missing @Override annotations. There are also
>>> some raw types. Of course these are not essential, but they would
>>> help.
>>>
>>>
>>>       
>>  I don't see either of these as essential and regarding the raw types, I
>> would prefer to limit the changes that are not backward-compatible.
>>     
>
> What do you mean by backward-compatible here?
> Do you mean compile-time or run-time?
>
>   
Both.  I want to minimize the impact of the upgrade to users.

Phil
>>> Also, what about thread-safety? There are a few Synchronized classes,
>>> which are presumably intended to be thread-safe. I'm not sure it's
>>> particularly necessary to have thread-safe Math classes, so long as
>>> the classes are not thread-hostile (there's at least one such; I'll
>>> file a JIRA shortly), but it would be useful to document which classes
>>> are which.
>>>
>>>
>>>       
>>  +1 to add general comments to user guide and web site.
>>     
>
> I'd like to see the individual class Javadoc include the details as
> well, but that could be added in due course as it will take a while.
>
>   
>>>       
>>>>  MATH-207 - I am close to committing David's great patch with only minor
>>>> modifications and that should make us pretty much complete from code
>>>> perspective for the initial genetics release, modulo comments on the API
>>>> that may still come in.  What will remain on this is user guide update.
>>>> Patches welcome!
>>>>  MATH-114 - User guide update is all that remains.  I should be able to
>>>>         
>> do
>>     
>>>> that.
>>>>  MATH-136 - I would like to get this in, but there is some work
>>>>         
>> involved.
>>     
>>>> +0 to moving to 2.1
>>>>  MATH-169 - pushed to 2.1
>>>>
>>>>  I will look at MATH-197 if Brent does not catch this.
>>>>
>>>>  MATH-194 is a can of worms that we should collectively open and clean
>>>>         
>> up.
>>     
>>>>  I suppose I should open an issue to track it, but the general problem
>>>>         
>> of
>>     
>>>> the multiple regression API being incomplete and the GLS class being
>>>> numerically suspect makes me think we may want to hold at least the GLS
>>>> class from the release.  I will see what I can do.  I am leaning toward
>>>> flattening the hierarchy, adding some basic stuff to the OLS class and
>>>> releasing just that class.  I will start a separate thread on this issue
>>>> when I have a plan.
>>>>
>>>>
>>>>  Thanks for volunteering for the RM duty!
>>>>
>>>>  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


Mime
View raw message