forked from micropython/micropython-lib
-
Notifications
You must be signed in to change notification settings - Fork 0
ContributorGuidelines
Paul Sokolovsky edited this page Sep 2, 2015
·
8 revisions
This is placeholder for contributor guidelines.
- Golden rule: Please do "git log"/"git log -p" and follow the same approach with your changes. Some specifics:
- One changed module/package per commit.
- Every commit message starts with "<module>: "
- Each module's
setup.pyis autogenerated frommetadata.txtbymake_metadata.pyscript, so please make changes to metadata.txt, runmake_metadata.pyand then commit bothmetadata.txtandsetup.py. - Name something
test_*.pyonly if it's a real unittest (which will checks results itself and will fail if there's error). Otherwise if human should check test results, name itexample_*.py
When porting a module from CPython or other 3rd-party source:
- Do some research to find suitable source. CPython 3.3 stdlib should still be considered as a base version to take modules from, as more recent versions has some modules bloated, which isn't really good direction for MicroPython. (But again, try to look at different versions and sources beyond CPython (e.g. PyPy) to find the best.)
- Start with committing 3rd-party source as-is, clearly stating in commit message from where it was taken (exact version, preferrably with URL to tarball, or VCS revision, preferrably with URL to it).
- Follow up with your changes as a next commit.
- When making your changes, the criteria should be minimizing size of a diff. Change as few lines as possible, within lines, don't change more chars than needed. Prefer commenting out to removal of lines. Don't fix typos, formatting, etc. - if you want them to be fixed, submit patches directly to upstream.
- Prefer taking (and porting) tests from CPython rather than duplicating effort and making your own.