On 01:38 pm, rdmurray at bitdance.com wrote: >On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano ><steve at pearwood.info> wrote: >>No, of course not. There are always other reasons, the biggest is too >>many things to do and not enough time to do it. If I did review >>patches, would they be accepted on the strength on my untrusted >>reviews? > >It is very very helpful for *anyone* to review patches. Let's see if >I can clarify the process a little. (This is, of course, my take >on it, others can chime in if they think I got anything wrong.) > >Someone submits a bug. Someone submits a patch to fix that bug (or add >the enhancement). Is that patch ready for commit? No. Is it ready >for *commit review* (ie: someone with commit privileges to look at it >with an eye toward committing it)? Probably not. > >What makes a patch ready for commit review? The patch should: > > 1) conform to pep 7/8 > 2) have unit tests that fail before the patch and succeed after > 3) have documentation updates if needed > 4) have a py3k port *if and only if* the port is non-trivial > (well, if someone wants to add one when it is trivial that's OK, > but it probably won't get used) > 5) if it is at all likely to have system dependencies, be tested > on at least linux and windows This list would make a good addition to one of the cpython development pages. If potential contributors could find this information, then they'd be much more likely to participate by doing reviews. 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