I'm starting to work on PEP 200, the release schedule for 2.0. As
part of that document, I'd like to write down some rules for
contributing code to that release.
I've come up with some guidelines based on the discussion we've had on
python-dev since moving to SourceForge as well as some offline
discussions at PythonLabs. I've included them below for comment and
review. Once we have reached some agreement on what the rules should
be, I'll add them to PEP 200 and check them in.
Jeremy
Use good sense when committing changes. You should know what we mean
by good sense or we wouldn't have given you commit privileges <0.5
wink>. Some specific examples of good sense include:
- Do whatever the dictator tells you.
- Discuss any controversial changes on python-dev first. If you
get a lot of +1 votes and no -1 votes, make the change. If you
get a some -1 votes, think twice; consider asking Guido what he
thinks.
- If the change is to code you contributed, it probably makes
sense for you to fix it.
- If the change affects code someone else wrote, it probably makes
sense to ask him or her first.
- You can use the SF Patch Manager to submit a patch and assign it
to someone for review.
Any significant new feature must be described in a PEP and approved
before it is checked in.
Any significant code addition, such as a new module or large patch,
MUST include test cases for the regression test and documentation. A
patch should not be checked in until the tests and documentation are
ready.
If you fix a bug, you SHOULD write a test case that would have caught
the bug.
If you commit a patch from the SF Patch Manager or fix a bug from the
Jitterbug database, be sure to reference the patch/bug number in the
CVS log message. Also be sure to change the status in the patch
manager or bug database.
It is not acceptable for any checked in code to cause the regression
test to fail. If a checkin causes a failure, it MUST be fixed within
24 hours or it will be backed out.
All contributed C code MUST be ANSI C. If possible check it with two
different compilers, e.g. gcc and MSVC.
All contributed Python code MUST follow Guido's Python style guide.
http://www.python.org/doc/essays/styleguide.html
It is understood that any code contributed will be released under an
Open Source license. Do not contribute code if it can't be released
this way.
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