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

Matthew Brett matthew.brett@gmail....
Tue Feb 24 12:59:01 CST 2009


I've split this off into a new thread because I felt there were two
issues in Stefan's original thread.

This is in the hope that we can stimulate discussion on the workflow
(as opposed to - say - which version control system to use, or which

I would be very interested to see if we can come to a consensus on the
important discussion of whether to introduce fairly formal code review
into the scipy workflow.  I've appended the key piece of discussion

> 2009/2/24 Travis E. Oliphant <oliphant@enthought.com>:
>> I think the biggest problem has been time and adding too formal of a
>> process will just increase the time it takes to get code into SciPy.
>> I'm fine with emphasizing documentation and tests as we discuss things
>> and we should encourage each other, but I'm not comfortable with
>> hard-line statements like the ones being made above.  Yes, such things
>> are helpful, but they are also expensive and I worry more about what we
>> lose in contributions.
> Having so little time means that we cannot be cavalier about adding
> broken code to SciPy.  Like Matthew mentioned, this becomes an immense
> maintenance burden.
>> The quality of what we create should emerge as all interested parties
>> critically look at the code that is available in SciPy.
> I agree with that sentiment; and looking critically at code in SciPy
> starts with our own patches.
>> Not everyone
>> can do that on the same schedule.  I'm opposed to trying to force that
>> to happen.  I very much favor cultivating a culture that wants someone
>> to fix the problems in their code.
> Sure, let's be inclusive, but also set a bar.  If you make the time to
> write a patch, make the time to do it well (it does not take long to
> construct a test -- you have to make sure your code works properly
> anyhow).
>> But, my favorite workflow is a bit more chaotic, than that.  People
>> create their own DVCS versions of SciPy using their best judgment and
>> publish revisions they consider to be working code.
>> Branches that are given the thumbs up by 2 people (or 1 on the steering
>> committee) get pushed to the main branch.      This review happens
>> regularly, on IRC channels at regularly scheduled times.
> Two eyes on every piece of code in SciPy, that's all we need.  Two
> critical eyes that realise the value of tests and documentation.  Your
> outline above fits in with my view of how this could happen.



More information about the Scipy-dev mailing list