[SciPy-dev] The future of SciPy and its development infrastructure

[Perry Greenfield]

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.

Perry