[SciPy-dev] Scipy workflow (and not tools).
Travis E. Oliphant
Wed Feb 25 12:07:01 CST 2009
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
> 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
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.
More information about the Scipy-dev