[SciPy-dev] scipy.optimize.nonlin rewrite

[Stéfan van der Walt]

2008/12/1 David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
> The only goal of a beta is to see whether we have unexpected failures,
> and solve them until the release. If we add new code, there is no point
> in doing beta. Even without taking into account this, having a window
> where no new feature is allowed is a really common process; even linux,
> which changes extremely rapidly, has a limited time window for merges.

You are preaching to the converted, but just to point out a subtlety:
Linux and most other projects allow contributions to be accepted while
they freeze, albeit to a different branch, tree, etc.  We should have
a similar mechanism in place (we've tried SVN branches without much
success in the past).

> Every project with a proper release management enforce those very
> strictly, because that's the whole point, really. Otherwise, releases
> are nothing more than a snapshot of the source code at a given time

Ideally, releases should simply be snapshots.  In practice, that is
seldom feasible.

> before releases helps that, rushing new code does not. It is not
> theoretical: almost all my time spent on scipy the last few weeks have
> been related to recently added code.

Just because the old code builds, does not mean that there isn't deep
underlying pathology.  But yes, "rushing" code through is a bad idea.
Only, in this case I trust the capabilities of the programmer, and if
he were to provide unit tests, I think we would have been better off.
But let me re-iterate, I am quite happy to postpone, as long as there
is no back-lash upon changing the API just after 0.7 has been
released.

Cheers
Stéfan