[Python-Dev] Interesting blog post by Ben Sussman-Collins

[Jean-Paul Calderone]

On Fri, 13 Jun 2008 18:22:42 -0400, Barry Warsaw <barry at python.org> wrote:
> [snip]
>
>* small branches - we have a strict limit on diffs no greater than 800 
>lines.  Yes we have exceptions, but they are rare and pre-arranged.   Having 
>such a strict limit really forces you to be disciplined,  organized and very 
>effectively diffuses code bombs.
>
>* everyone can see (lots of) everyone else's code - this is great  because 
>everyone needs some advice or guidance along the way.  If you  get stuck, 
>you can push a branch and I can pull it and look at it, run  it, test it, 
>even modify it and push my own branch for you to see.   This is /much/ more 
>effective than trading patches, and I don't see  how this could even work 
>without a dvcs.
>
>* nothing lands without being reviewed - this is a hard and fast rule,  no 
>exceptions.  Someone else has to review your code, and most  developers are 
>also reviewers (we have a mentoring program to train  new reviewers).  You 
>get over the fear pretty quickly, and learn /a  lot/ both by reviewing and 
>getting reviewed.  Coding standards emerge,  best practices are established, 
>and overall team productivity goes way  up.  Small branches are critical to 
>this process, as is our goal of  reviewing every branch within 24 hours of 
>its submission.
>
>* nothing lands without passing all tests - speaking from experience,  this 
>is the one thing I wish Python would adopt!  This means the trunk  is 
>/always/ releasable and stable.  The trade-off is that it can take  quite a 
>while for your branch to land once it's been approved, since  this process 
>is serialized and is dependent on full test suite  execution time.  Python's 
>challenge here is that what passes on one  platform does not necessarily 
>pass on another.  Still, if this week is  any indication, passing on /any/ 
>platform would be nice. ;)
>
>I'm not saying Python can or should adopt these guidelines.  An open  source 
>volunteer project is different than a corporate environment,  even if the 
>latter is very open-source-y.  But it is worthwhile to  continually evaluate 
>and improve the process because over time, you  definitely improve 
>efficiency in ways that are happily adopted by the  majority of the 
>community.

A big +1 on all these points.  I can also add that Twisted is developed
following many of these rules so it *can* work for open source volunteer
projects, if the developers want it to.

Jean-Paul