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

[Nathan Bell]

On Mon, Feb 23, 2009 at 11:04 AM, Stéfan van der Walt <stefan at sun.ac.za> wrote:
>
> process.  As it is, we have many patches waiting on Trac for up to a year or
> more without any feedback; that is not acceptable.
>
> My view on testing is simple: untested code is probably broken code (and I
> can show examples from the past year's commit logs to corroborate this
> statement).  As for documentation, we cannot afford to be without it.
>

I agree that these are problems, but I don't see why a different
revision management system or bugtracker is going to bring about
qualitative change.  If a patch has languished on Trac for a year it's
because: (1) the patch is not going to be included and no one has
closed it, (2) the relevant authorities lack the time, or (3) no one
actively maintains that part of scipy.

Perhaps Git + whatever will be a better combination than SVN + Trac.
However, I'd argue that having a dedicate maintainer/supervisor for
each instance of scipy.X is more valuable, and the lack thereof is our
current problem.

Can anyone claim that using SVN or Trac is so onerous that *it* is the
problem?  I own at least one 6+ month old ticket with a patches.  I
can locate this ticket with Trac in about 30 seconds.  The problem is
that integrating the patch would take a few hours of my time, and I
simply haven't had time to dedicate to it.  How many other patches are
like this?

I'm neutral on Git vs. SVN since they seem roughly equivalent for
basic tasks ( http://git.or.cz/course/svn.html ).  However, I think
the following are more significant problems:
- limited maintenance of scipy.X (i.e. who do we blame when tests fail?)
- distribution woes (setup.py build should just work)
- packaging woes (installers should just work, creating binary
installers should be easy)
- unreasonably long release cycle (why commit a fix, or report a bug
when the next version is 18 months away)
- lack of automated testing (build bots)

And I'd argue for:
- someone who we can spam when scipy.X fails
- a setup.py that didn't lead to questions about Fortran ABI incompatibilities
- a setup.py (or equivalent) with bdist_foo for every foo we care about
- a ~6 month cycle and nightly builds (with binary installers)
- a website where the scipy.X maintainer can see errors for their
module on a dozen different platforms

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/