commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] release plan for 3.0 ?
Date Wed, 23 Nov 2011 20:44:19 GMT
Le 23/11/2011 16:57, Gilles Sadowski a écrit :
> Hi Luc.

Hi Gilles,

> 
>>
>> I have had several questions about release plans for 3.0.
>>
>> I feel guilty for not having pushed this version out yet.
> 
> "Release early, release often ..." would alleviate this feeling.
> And would reduce the tensions here because much less *new* things would be
> under discussion between releases, because much less new bugs and new
> features accumulate, thus further delaying the next release.
> 
> Please, don't take this as a rant; I don't want this thread to become
> another endless and useless discussion.  But it is a fact that the current
> release policy is obscure:  E.g. the last release has been "self-serving"
> without regards to the implications on the mid-term agenda (i.e. the
> long-overdue release of 3.0)
> Again, don't take it personally; I think that the problem is related to the
> a so-called "user-centric" development model, in a context where we rarely
> see those users who are not developers.
> In the absence of "users-only", the CM developers should, IMHO, foremost be
> working towards making releases that reflect the changing state of the
> library. We could define some metrics that objectively characterize the
> development flux[1]; when some threshol is reached, we *must* start to
> prepare a release, freezing the development and having everyone
> concentrating on issues that block that new release.
> 
>> It is not in
>> release shape now and many thing are still ongoing.
> 
> Yes, despite several commitments that new features should be deferred to
> after 3.0.
> 
>> Typically, a new
>> thread as been started a few hours ago about an important change in the
>> linear algebra API (a needed change, so something important to discuss now).
> 
> I agree that it would be nice to fix this issue. But I note that it is not
> *required* to be done before releasing 3.0.
> Many things will surely to need breaking updates fairly soon, and it
> shouldn't be considered harmful to assume that 4.0 could come relatively
> soon after 3.0. IMO, more than 2 years for a new major release belies the
> actual work that has been performed.[2]

OK, if we think we can push this later, this is fine with me.

> 
>> As far as I am concerned, here are the points I want to address myself
>> (but if other people want to help, chime in!). I would like to see what
>> other developers have in mind so wa can set up a release plan, and
>> really work toward a release which is past due.
>>
>> My personal tasks are:
>>   - finish the adapters wrapping unbounded optimizers into simple bounds
>>     optimizers as set up by Gilles, using the two function adapters
>>     already available
>>   - stabilize Adams based ODE integrators using the
>>     MathUtils.linearCombination feature to ensure better accuracy and
>>     error estimates in the Nordsieck vectors
>>   - perhaps add back the BDF integrator for stiff problems, using the
>>     Nordsieck vectors once it has been stabilized for Adams methods
>>   - perhaps add a Radau integrator
>>   - replace the reset() method in step handler interface by init()
>>     (it's a simple rename), and add a similar init() in the events
>>     interface
>>   - fix the mapping between boundary representation/BSP representation
>>     in 2D/3D
> 
> It's not polite to tell other people what to work on, but please forgive me:
> Are those issues *blocking*? I suspect that everything that starts with "Add
> ..." is not. Even some improvements that are foreseen could wait for 3.x.
> Part of the policy should be to refrain from wanting "everything, now". In
> fact, I'm pretty sure that by releasing often, we'll be able to offer more
> features in less time.

BDF and Radau can wait. Adams is really needed and the change of reset
to init is trivial, but introduces an incompatibility, so it is much
better to do it now (it's a five minutes work).

> 
>> could other people add to this list the features they want to have in 3.0 ?
> 
> I think that more important is the review of opened tickets, asking for
> people to commit working on them... [Oops, sorry again.]

Yes, this was what I meant. sorry to have used the term "feature"
inappropriately.

Luc

> 
> 
> Best regards,
> Gilles
> 
> [1] Based on the number of commits, number of opened and resolved issues,
>     and so on. [Please add your preferred criteria.]
> [2] And the side-effect is that it makes it difficult for "users-only" to
>     actually have a say on individual design changes, as the more time
>     passes, the more difficult it will be to reverse a change thay may have
>     become intertwined with later ones.
> 
> ---------------------------------------------------------------------
> 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