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

[David Cournapeau]

Nathan Bell wrote:
> 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?  

Yes, I claim this. Doing bug triaging in a web interface is already not
a pleasant experience, but with trac, it just becomes very frustrating.
When preparing for releases (massive bug triaging), I waste hours doing
things which could be at least partially automated.

> 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)

I think that I spent quite some time on most of those issues myself.
Trac has been the most frustrating point in the whole process. For a
release, you need the following from a bug POV
    - a good idea of bugs + regressions
    - a good idea of what changed
    - a quick way to retriage things
None of this is made easy with trac, at least wo a command line interface.

Also, my recent work on several builds issues on windows, etc... were
done in branches (to avoid breaking the trunk for everyone), but this is
a huge time waster for me.

> 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

I would argue those issues are not orthogonal to the quality of the
tools we are using. The time I waste on trac and svn is time I don't
spend on those issues, and this time easily go up to hours now.

cheers,

David