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

David Cournapeau cournape@gmail....
Wed Feb 25 12:16:32 CST 2009

On Thu, Feb 26, 2009 at 2:55 AM, Travis E. Oliphant
<oliphant@enthought.com> wrote:
> Andrew Straw wrote:
>> I also want to point out that a formal code review process that is open
>> (such as a web gui) encourages participation by people who may not feel
>> they have the time or abilities to write new code, but would feel
>> comfortable commenting on a patch sitting in front of them. I think it
>> new developers could be fostered this way, too.
> Great idea!  Let's have review/mentoring processes to assist
> new-comers.  I'm all for that.
> I would like to move those people who are timid at first to the point of
> being willing to dive in and get their hands dirty.   I suspect my view
> is a bit organic for some,  but I've encouraged people for a long time
> to commit code with as much documentation and testing as can be
> provided.   Then, let the process of further documenting and using that
> code "harden" it rather than a "review" process.
> If we feel that there have been too many "buggy-commits" then what are
> examples of that?  I think the switch to NumPy and the integration of
> ndimage did bring in some "less-reviewed" code with API changes that
> were possibly too hurried.  But, that was a time-problem again.   Is
> imposing an extra burden on the developer really going to solve that
> problem more than just a willingness to allow your own code to be
> critiqued and being willing to speak up when you see specifics you
> disagree with.
> I don't see this discussion as review or not review.   Open source
> *will* be reviewed.  It's just "when."  On the question of whether or
> not you make the code available until you can guarantee someone else has
> looked at it, I come down on the side of "make it available" so that
> other people will look at it when it becomes interesting to them.
> Tools that let us monitor the results of commits (buildbots, dashboards,
> automatic emails, etc...) are much more valuable in my mind than
> (difficult-to-quantify and establish) processes that try to prevent any
> problems.
> More tools please is fundamentally what I say to the question of formal
> review...

I agree. I know the topic is not about tools, but at least in my case,
I don't do review because it is too much of a pain right now. It is
not so much about tools as much as barrier of entry: I am honestly not
really interested in doing code review if the process to be aware of
the code to review, look at it, test it makes up 75 % of the time. And
that's exactly the situation right now. More concretely, if I could:
 - receive email specifically for the packages/topics I want to
review, not others
 - I can get the code/test it ideally without even having to click
once in a website
 - send back what's wrong/what's not
 - mark a review as done
That would make me much more willing to do review.

I think discussing about review process in the dark, without actual
experiments is a bit useless at this point - like Robert, I think as
long as we don't have any process on how to do things, we won't have
much more than gut feeling. To see actual problems, limitations, we
have to try things at some point.


More information about the Scipy-dev mailing list