Hi Matthew,
On Tue, Feb 24, 2009 at 11:59 AM, Matthew Brett <matthew.brett@gmail.com>wrote:
> Hi,
>> 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
> bugtracker).
>> 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
> below.
>> > 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.
>
I don't think there are enough eyes at this point for a strict review
policy. How many of the current packages have any maintainer? Who was
maintaining the stats package before Josef got involved? How many folks
besides Robert could look over the changes usefully? How many folks looked
over Travis' recent addition to optimize? Who is working on the
interpolation package?
I think at this point we would be better off trying to recruit at least one
person to "own" each package. For new packages that is usually the person
who committed it but we also need ownership of older packages. Someone with
a personal stake in a package is likely to do more for quality assurance at
this point than any amount of required review.
I don't have a problem with folks complaining about missing tests, etc., but
I worry that if we put too many review steps into the submission path there
won't be enough people to make it work.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/scipy-dev/attachments/20090224/c844ad87/attachment.html