[SciPy-dev] Scipy workflow (and not tools).
Travis E. Oliphant
Thu Feb 26 12:01:55 CST 2009
Brian Granger wrote:
> Thanks for speaking up! I think there are *many* people in your
> situation, including myself - I too am mostly a silent watcher of
> SciPy and I would be much more likely to contribute if the things you
> list were a part of the Scipy development culture:
> * Tests
> * Code review
> * Documentation
What is standing in the way of these things being done more often?
Tests are happening, code review is happening, and documentation is
happening. What exactly is the problem except lack of time from people
who have historically committed to SciPy?
I want these things to happen and try to do them whenever I submit new
code. But, time is a factor, and people will disagree about "what
constitutes a test" and "what constitutes good documentation."
There is a lot of code in SciPy that was contributed by me very early on
that may not live up to the same standard of testing and documentation
that people have. Is that the fundamental problem --- history?
> * Good tools and workflow.
This, I do see as a problem. The value of DVCS is that it handles
branches better and new contributors *want* to work on branches and this
will encourage *everybody* (including me) to work on branches.
I've been committing to trunk for many years on SciPy and NumPy without
pre-commit code review. It's hard for me to break that habit and I'm
resisting requests that I stop doing that. I'm willing to stop it --
if it will really help SciPy progress. However, I'm not convinced that
this kind of commit behavior by me and others is what is really stalling
SciPy development. It could be that other commit patterns are not
advertised enough to assist newcomers and I'm all for advertising other
commit patterns that help people contribute. So, let's do that
I'm very encouraged by the experiments with a git-svn bridge and would
love to see an issue-tracker with a command-line interface. I'd also
love to see more volunteers who are willing to tackle release management
so that we can do it more regularly. Ultimately, those who do the
work of release management will define what SciPy *is*.
More information about the Scipy-dev