[SciPy-dev] Scipy workflow (and not tools).
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 <firstname.lastname@example.org>:
>> 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
>> 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