[Python-Dev] We should be using a tool for code reviews

[Toshio Kuratomi]

On Wed, Sep 29, 2010 at 01:23:24PM -0700, Guido van Rossum wrote:
> On Wed, Sep 29, 2010 at 1:12 PM, Brett Cannon <brett at python.org> wrote:
> > On Wed, Sep 29, 2010 at 12:03, Guido van Rossum <guido at python.org> wrote:
> >> A problem with that is that we regularly make matching improvements to
> >> upload.py and the server-side code it talks to. While we tend to be
> >> conservative in these changes (because we don't control what version
> >> of upload.py people use) it would be a pain to maintain backwards
> >> compatibility with a version that was distributed in Misc/ two years
> >> ago -- that's kind of outside our horizon.
> >
> > Well, I would assume people are working from a checkout. Patches from
> > an outdated checkout simply would fail and that's fine by me.
> 
> Ok, but that's an extra barrier for contributions. Lots of people when
> asked for a patch just modify their distro in place and you can count
> yourself lucky if they send you a diff from a clean copy.
> 
> But maybe with Hg it's less of a burden to ask people to use a checkout.
> 
> > How often do we even get patches generated from a downloaded copy of
> > Python? Is it enough to need to worry about this?
> 
> I used to get these frequently. I don't know what the experience of
> the current crop of core developers is though, so maybe my gut
> feelings here are outdated.
> 
When helping out on a Linux distribution, dealing with patches against the
latest tarball is a fairly frequent occurrence.  The question would be
whether these patches get filtered through the maintainer of the package
before landing in roundup/rietveld and whether the distro maintainer is
sufficiently in tune with python development that they're maintaining both
patches against the last tarball and a checkout of trunk with the patches
applied intelligently there.

A few other random thoughts:

* hg could be more of a burden in that it may be unfamiliar to the casual
  python user who happens to have found a fix for a bug and wants to submit
  it.  cvs and svn are similar enough that people comfortable with one are
  usually comfortable with the other but hg has different semantics.
* The barrier to entry seems to be higher the less well integrated the tools
  are.  I occassionally try to contribute patches to bzr in launchpad and
  the integration there is horrid.  You end up with two separate streams of
  comments and you don't automatically get subscribed to both.  There's
  several UI elements for associating a branch with a bug but some of them
  are buggy (or else are very strict on what input they're expecting) while
  other ones are hard to find.  Since I only contribute a patch two or three
  times a year, I have to re-figure out the process each time I try to
  contribute.
* I like the idea of patch complexity being a measure of whether the patch
  needs to go into a code review tool in that it keeps simple things simple
  and gives more advanced tools to more advanced cases.  I dislike it in
  that for someone who's just contributing a patch to fix a problem that
  they're encountering which happens to be somewhat complex, they end up
  having to learn a lot about tools that they may never use again.
* It seems like code review will be a great aid to people who submit changes
  or review changes frequently.  The trick will be making it
  non-intimidating for someone who's just going to contribute changes
  infrequently.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100930/a578a0e4/attachment.pgp>