On Fri, 13 Jun 2008 18:22:42 -0400, Barry Warsaw <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
