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