[SciPy-dev] The future of SciPy and its development infrastructure
Stéfan van der Walt
Mon Feb 23 23:39:43 CST 2009
2009/2/24 Travis E. Oliphant <email@example.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
> 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