[SciPy-dev] The future of SciPy and its development infrastructure
Wed Feb 25 14:58:21 CST 2009
I'll add a couple comments regarding this whole discussion (including
the tools that will be used for scipy/numpy software development).
1) I'm not sure that it is a good idea to change everything at once
(e.g., svn->git, trac->roundup, etc), particularly if these changes
can be done incrementally. It's easy for those that hunger for these
changes to think of why doing sooner is better. I suspect there are
many other that may feel otherwise that may not be as vocal. And some
of the impacts may not be obvious. So if it is at all possible, even
if it means some extra work, try just doing one thing at a time and
evaluating its impact first before making other changes. Arguably the
same point can be made about process changes.
2) While I understand the desire to increase the quality of commits to
scipy by putting in a more formal process, like making sure code is
reviewed, tests are present, and documentation is provided, I too,
like Travis, worry that this may inhibit many useful contributions.
Rather than act as a barrier, why not just have some sort of "seal of
approval" for things that have gone through that process. As a user,
I'd rather have the choice of using an unreviewed, poorly tested, or
poorly documented module than have someone else decide that I can't
make that choice myself. Who knows, I might find it useful enough to
improve. Yes, it can be put in another area (e.g., scikits), but it
should be just as easy to get at and see that it is available. If one
thing should be most required it would be tests to ensure the main
functionality works on all supported platforms so that building
releases isn't held up by problems discovered on yet untested
platforms. I don't think the reviewing or documentation issues
generally affect how much work is involved in making releases though.
More information about the Scipy-dev