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

[David Cournapeau]

On Tue, Feb 24, 2009 at 4:10 AM, Nathan Bell <wnbell at gmail.com> wrote:
> On Mon, Feb 23, 2009 at 1:34 PM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp> wrote:
>>> 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.
>>
>
> The collective time wasted by Fortran ABI problems *alone* is 10x more
> than that wasted by the problems you seek to remedy.

I think that's a bit unfair. I built ubuntu packages for scipy/numpy,
I built a win32 binary which solved another common ABI problem, I have
added unit tests to detect fortran ABI problems, I have set up a build
bot on the build service from open source for automatic rpm builds
with correct fortran ABI. I spent hours on a broken platform I don't
even use because I think it is important for windows to be a first
class citizen for numpy/scipy.

But I think you don't realize all the work that some of us need to do
to make decent releases, properly tested on a vast range of platforms,
without a lot of resources. Just looking at new bugs and assigning
them takes a lot of time, and with an email interface and/or command
line interface, it would be a matter of one minute or two.

I personally don't care too much about using git instead of svn -
because git-svn gets me a lot of advantages already, without changing
anyone workflow. But concerning the bug tracker, something has to be
done: I don't care what, as long as it enables a command-line and
offline handling.

cheers,

David