Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
Guido van Rossum wrote: On Thu, Jun 12, 2008 at 8:49 PM, Neal Norwitz [EMAIL PROTECTED] wrote: Ben mentions this in the post, but it's a good reminder: comments on python-checkins are *not* personal. The goal is to make the code better and/or gain better understanding. We all make mistakes, better to correct them early before they become big problems.. And this reminder applies to reviewer *and* reviewees! (I know I've made this mistake in both roles. :-) I still love the last entry from Raymond's school of hard knocks [1]: do everything right (formatting, procedure, profiling, testing, etc) and watch the Timbot come along five minutes later and improve your code making it faster, clearer, more conformant, more elegant, and also gel neatly with the vaguaries of memory allocation, cache performance, and compilers you've never heard of. Cheers, Nick. [1] http://mail.python.org/pipermail/python-dev/2002-September/028725.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
On Thu, Jun 12, 2008 at 10:41 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Let's all remember this and make sure not to drop code bombs on each other. :-) Ok! I'd like everybody to know that I'm working on Python tests on a Bazaar branch. [1] (That's only a bzr co --lightweight away.) Go ahead and send me angry emails about how it's totally wrong, and your cat could do better. [1] http://code.python.org/python/users/benjamin.peterson/new_testing/main/ -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
Let's all remember this and make sure not to drop code bombs on each other. :-) Benjamin Ok! I'd like everybody to know that I'm working on Python Benjamin tests on a Bazaar branch. [1] (That's only a bzr co Benjamin --lightweight away.) Go ahead and send me angry emails about Benjamin how it's totally wrong, and your cat could do better. No problem, as long as it doesn't take five months and touch every file in the distribution. wink I don't think Ben was suggesting there is never a good reason to work in relative isolation. I interpreted it as a rule of thumb for joint projects. In your case, while it can have a wide-ranging effect on the unit test code it's likely that you will be able to manage syncing from trunk/py3k just fine and you already have plenty of examples of how things work now and how they should work when you're done. That said, if you can commit in chunks that would probably still be a win. Where I work most of the projects are one-person, due largely to the business we are in and thus how management wants things done. I think that contributes to a number of issues, the most problematic being that APIs are developed largely in isolation, often with the needs of only one or two applications in mind. That creates problems for people who come along later and need to use those APIs, only to discover that they are fundamentally flawed in some way. Skip ___ 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
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 12, 2008, at 11:41 PM, Guido van Rossum wrote: My colleague and SVN developer Ben Sussman-Collins occasionally blogs about the social side of (mostly open source) software development. He just posted a new one that struck a chord: http://blog.red-bean.com/sussman/?p=96 The story's main moral: submit your code for review early and often; work in a branch if you need to, but don't hide your code from review in a local repository until it's perfect. Let's all remember this and make sure not to drop code bombs on each other. :-) Very interesting article. I'm short on time and don't want to rant (though I likely will ;), but I whole-heartedly agree with the moral of the story! I disagree with some of the details though. I actually think that a dvcs is /better/ suited to transparency, when used right, and when coupled with a public open code hosting facility. Sure, a lot depends on social engineering, and I agree with Ben that the tools make a difference, I just think that a good dvcs solves more problems than it creates. Also, there are a few things we do at my job that I think contribute significantly and positively to our productivity, quality and sense of shared community code. Briefly: * pre-implementation calls - you do not start hacking code until you've discussed your design or approach with at least one other person, either over the phone or on irc (preferably the former). Yes, there are exceptions but they are discouraged. This means that when you actually sit in front of your editor, you have a much better idea of what you are trying to accomplish. * 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. - -Barry P.S. I can't leave this without one little plug. Some folks really like the model that a non-dvcs imposes on development, others thrive on the freedom a dvcs gives you. Bazaar is flexible enough to support both models, even at the same time. It's not either-or. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFLzMnEjvBPtnXfVAQLm3QQAptABUXBoWeshMJAvHno1IDMZavL9D2BG q9d3wz8O5u2pbvuZyh44w4fhm7w7fscGvmPygifNbjPTVMeUYQUkunuEfWEIzf6B f6hm1KQm5gi9B4eqSUh3ItIAjGAnkVnCJ8VHeRH/Hff9FZhHqPhtP26LBrecMoho q0g80DrALB8= =J936 -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
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
[Python-Dev] Interesting blog post by Ben Sussman-Collins
My colleague and SVN developer Ben Sussman-Collins occasionally blogs about the social side of (mostly open source) software development. He just posted a new one that struck a chord: http://blog.red-bean.com/sussman/?p=96 The story's main moral: submit your code for review early and often; work in a branch if you need to, but don't hide your code from review in a local repository until it's perfect. Let's all remember this and make sure not to drop code bombs on each other. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
On Thu, Jun 12, 2008 at 8:41 PM, Guido van Rossum [EMAIL PROTECTED] wrote: My colleague and SVN developer Ben Sussman-Collins occasionally blogs about the social side of (mostly open source) software development. He just posted a new one that struck a chord: http://blog.red-bean.com/sussman/?p=96 The story's main moral: submit your code for review early and often; work in a branch if you need to, but don't hide your code from review in a local repository until it's perfect. Let's all remember this and make sure not to drop code bombs on each other. :-) Ben mentions this in the post, but it's a good reminder: comments on python-checkins are *not* personal. The goal is to make the code better and/or gain better understanding. We all make mistakes, better to correct them early before they become big problems.. n ___ 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
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
On Thu, Jun 12, 2008 at 8:49 PM, Neal Norwitz [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 8:41 PM, Guido van Rossum [EMAIL PROTECTED] wrote: My colleague and SVN developer Ben Sussman-Collins occasionally blogs about the social side of (mostly open source) software development. He just posted a new one that struck a chord: http://blog.red-bean.com/sussman/?p=96 The story's main moral: submit your code for review early and often; work in a branch if you need to, but don't hide your code from review in a local repository until it's perfect. Let's all remember this and make sure not to drop code bombs on each other. :-) Ben mentions this in the post, but it's a good reminder: comments on python-checkins are *not* personal. The goal is to make the code better and/or gain better understanding. We all make mistakes, better to correct them early before they become big problems.. And this reminder applies to reviewer *and* reviewees! (I know I've made this mistake in both roles. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
