[SciPy-dev] Scipy workflow (and not tools).

[Jonathan Guyer]

On Feb 26, 2009, at 12:42 AM, Neil Martinsen-Burrell wrote:

> other projects have trained me to unit test my contributions, so  
> that is
> what I would most likely be doing if I were to contribute and I  
> would like to
> feel that my effort to write tests is valued.

I've never seen a single post in this thread, or on this list for that  
matter, that indicated that anybody thought that the effort to write  
tests was not valued. Quite the contrary. Everybody wants tests; it's  
just a question of whether there's something else they want even more.

If I may very unfairly summarize the debate this far:

Stéfan, et al.: There aren't enough tests. All code must have tests!  
Under penalty of death!
Travis, et al.: But then we we shall have neither code *nor* tests!
Stéfan, et al.: Good!

I would characterize the debate as the value of writing tests  
*relative* to the value of writing anything else, not whether you  
should be writing and using tests at all. Absolutely you should.


> One of the things that keeps me from developing even small patches  
> for Scipy
> is SVN.  If I want to make a change, I have to check out the trunk  
> and then
> develop my change *completely without the benefit of version control*.

Nothing forces you to develop without version control. See the SVN  
Book's discussion on "vendor branches" for one approach. We hack on  
several other people's tools in our own repository and periodically  
synch to their efforts or send them patches from ours. I am *not*  
saying that DVCS is a bad idea. I don't think it is. In this instance,  
it's clearly superior to the svn model, but please let's stop making  
svn out to be worse than it is, because I guarantee that you're going  
to be bitten by some variant of the same issues with bzr, git, or  
whatever. Look at David Cournapeau's blog on why he's ditching bzr in  
favor of git, after ditching svn in favor of bzr; I look forward to  
his essay on the atrocities of git. I don't mean that to be snide;  
it's *good* that tools are getting better and it's *good* that people  
like David are actually comparing them head to head and telling us  
about their experiences.

I get that good and pleasant tools make people more productive, e.g.,  
while I can get work done with Windows, I can get a lot more work done  
with something else because I don't have to devote so much energy to  
profanity. If some DVCS will make life more pleasant for both release  
managers and new contributors like yourself, by all means go for it,  
but don't kid yourself about the strengths of the tool you're leaving  
behind or the weaknesses of the tool you're adopting.