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

[Matthew Turk]

Hi there,

I've only just subscribed to this list (after following on GMANE-RSS)
because I wanted to contribute to the discussion.  I'd like to echo
Perry's first point below, and add on some specific concerns I have
about the entire workflow discussion.

An aspect I worry is being overlooked is that in some communities
change comes rather slowly.  I have helped out a number of people with
user-space deployment of Python packages, and the biggest impediment
is -- as with many things -- installation.  I worry that if the
release schedule of SciPy doesn't speed up substantially, accessing
source control will be the primary means of getting the code.
Installing git and mercurial (and maybe Bazaar, but I've had the most
trouble with that) into some user-space area is not difficult, but it
adds on another layer of overhead.  Until all of the supercomputing
centers provide DVCS, users (and developers!) targeting deployment
there will have yet another barrier to entry for using SciPy.  (And as
a result, they may fall back on old habits: IDL, for instance.)  To
that end, I'd like to strongly and plaintively request that some kind
of mirror in SVN, or even archived nightly tarballs, be kept of the
primary tree of development.

Those concerns aside, I think that anything that reduces the barrier
to entry for developers is likely to be a great boon to SciPy.  For
me, the biggest barrier to using and deploying SciPy is still
installation, but in recent months that has become substantially
easier -- largely due to the efforts by everyone here.  (That being
said, I do know that some of my colleagues do on occasion still
struggle with the installation process.)

Thanks for listening.  :)

-Matt

On Wed, Feb 25, 2009 at 12:58 PM, Perry Greenfield <perry at stsci.edu> wrote:
> 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
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>