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

[Travis E. Oliphant]

Anne Archibald wrote:
> wrote some. I don't foresee this changing without some major change
> (e.g. a company suddenly hiring ten people to work full-time on
> scipy). So the question is how to make this model produce reliable
> code.
>
> Suggestions people have made to accomplish this:
>
> (1) Don't allow anything into SVN without tests and documentation.
> (2) Make sure everything gets reviewed before it goes in.
> (3) Appoint owners for parts of scipy.
>
> Of these, I strongly approve of (1). It's really not a barrier.
>   
As long as we don't do #2, then having the rule of #1 is completely 
fine.   Say it in a similar way to that: "Don't commit to trunk until 
there are tests and documentation."  

I would be opposed to attempts to modify the nouns with fuzzy words like 
"complete" or "full" or something impossible to quantify.   Here's an 
attempt at the wording:

"Don't commit new code to trunk until you are sure the code works by 
passing unit-tests and being documented by a doc-string that follows the 
pattern established"

Bug-fixes should (usually be accompanied by a unit test) unless they are 
"bug-guard changes" (i.e. like the one-liner I recently made to NumPy to 
catch the error-condition which I've never actually seen and don't know 
how to test for):

I definitely think review should be encouraged but absolutely optional 
pre-commit.  We should then encourage each other to review post-commit.

As far as "ownership".   How about we just have a posted list of 
"interested committers" that people can refer to in order to direct 
code-review requests and patch-submission.    More than one person can 
be listed for each sub-project.

-Travis