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...
-Travis