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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4