On Fri, Oct 1, 2010 at 12:56 AM, Guido van Rossum <guido at python.org> wrote: >> (I am strongly in favor of this, but I don't think many core committers >> are.) > > Having worked in this style for almost 5 years now, I am also strongly > in favor. Jesse expressed it better than I could. I'll be one of those to object (but only slightly). I think one of the privileges/responsibilities that goes with commit access is the ability to make the call between: - "this is a simple change/fix, I'll just check it in with possible post hoc review via python-checkins" - "I want feedback on the idea and/or details before I commit this, I'll post a patch for review to the tracker" - "I may want help in getting this working and/or this may take a while to get right, so I'll create a branch for it" (with the balance between 2 and 3 apparently shifting more in favour of 3 once we have hg to play with) Particularly for user visible API changes, I think getting a sanity check from at least one other dev before committing is a good idea. For smaller stuff, I think python-checkins after the fact reviews are enough to cover it (particularly now that one person asking a question will kick the entire diff over to python-dev for broader review). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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