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

Stéfan van der Walt stefan@sun.ac...
Tue Feb 24 17:02:43 CST 2009


2009/2/25 Charles R Harris <charlesr.harris@gmail.com>:
>> On Tue, Feb 24, 2009 at 1:13 PM, Charles R Harris
>> <charlesr.harris@gmail.com> wrote:
>> > I don't think there are enough eyes at this point for a strict review
>> > policy. How many of the current packages have any maintainer? Who was
>> > maintaining the stats package before Josef got involved? How many folks
>> > besides Robert could look over the changes usefully? How many folks
>> > looked
>> > over Travis' recent addition to optimize?  Who is working on the
>> > interpolation package?

Thank you for providing some prime examples on why code review and
testing is needed.

I didn't know about the changes to the optimisation module, but now I
have to ask these questions:

1. Is it quality code, suitable for SciPy?  (It is, I read the code,
or in other words *reviewed* it)

2. Does it work?  I don't know.  Nobody does.  There aren't any tests,
no guarantees.

That would be my reaction to one change, but there were 6 or more,
none with any tests (and at least one contains a spelling mistake!).
How do we know that they work under Windows, Solaris, Linux and OSX?

Worse; what if I decide to make some updates to that code but, not
having understood the author's intention perfectly, break it horribly.
 Who would be any the wiser?

Tests protect the user and the developer alike.  It is irresponsible
to carry on the way we do.

> Are we adding a lot of broken code?

Yes, we are.  And it is OK to write broken code, we all do.  My
argument is that, together, we write better code (review), and by
using the tools at our proposal (testing), we minimise the chances of

> Does the gain offset the pain? I think
> we need more folks with commit privileges and interest. In the short term I
> would propose the following.

More folks with commit priviledges would just perpetuate this chaos.
Our community is sophisticated enough not to apply a brute-force
solution to the problem.

> 1) Additions get posted on the mailing list for comment before commit. I'll
> bet few knew of the additions to optimize.

Simply being aware of a patch does not improve its quality.

> 3) We put together a list of needed tests. Then we will see how serious
> folks are about writing tests.

It should not be anyone's job to clean up after his/her peers.  If
each patch is accompanied by appropriate tests, this situation would
never occur.


More information about the Scipy-dev mailing list