[Python-Dev] We should be using a tool for code reviews
a.badger at gmail.com
Thu Sep 30 11:10:14 CEST 2010
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
* 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Python-Dev