[SciPy-dev] scipy.optimize.nonlin rewrite
Stéfan van der Walt
Mon Dec 1 07:30:16 CST 2008
2008/12/1 David Cournapeau <email@example.com>:
> 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
> 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
More information about the Scipy-dev