mirrors
/
micropython
mirror of https://github.com/micropython/micropython.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

some cleanup of previous edits

Angus Gratton 2023-09-05 16:07:11 +10:00
parent 3bd5b123b1
commit 10164fa150
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
ContributorGuidelines.md

@ -53,12 +53,14 @@ Some guidelines if adding a new Python library feature (like a new function or a
### Adding Python syntax features
If you want to change the Python language features exposed by MicroPython, it's a good idea to discuss this with the maintainers first.
If you want to change the Python language features supported by MicroPython, then it's a good idea to discuss this with the maintainers first.
### Adding hardware features
* If implementing an existing [machine](https://docs.micropython.org/en/latest/library/machine.html) API on a new port (for example, to add `machine.I2S` to a port which has I2S hardware but no MicroPython driver yet), then the API must match the existing `machine` API whenever possible. Additions that substantially change an existing `machine` API for a single port only, or have too many "special case" notes, may be better suited as port-specific APIs (see below).
* Contributing a new [machine](https://docs.micropython.org/en/latest/library/machine.html) API that adds brand new functionality (for example, adding a `machine.TenGbpsEthernet` class for 10Gbps Ethernet controllers) must be very carefully implemented and designed. These APIs must be as generic to work on multiple ports, while still being efficient and small in code size. If you're planning to contribute such a driver, please discuss with the maintainers and the community first. You could start with a [Discussion](https://github.com/micropython/micropython/discussions) or make a Pull Request that only adds the docs for your proposed API.
New hardware driver support or functionality is always welcome:
* If implementing an existing [machine](https://docs.micropython.org/en/latest/library/machine.html) API for a new port (for example, adding `machine.I2S` to a port which has I2S hardware but no MicroPython driver yet), then the API must match the existing `machine` API whenever possible. Additions that substantially change an existing `machine` API for a single port only, or have non-trivial "special case" notes, may be better suited as port-specific APIs (see below).
* Contributing a new [machine](https://docs.micropython.org/en/latest/library/machine.html) API that adds brand new functionality (for example, adding a `machine.TenGbpsEthernet` class for 10Gbps Ethernet controllers) must be very carefully implemented and designed. These APIs must be generic to work on multiple ports, while still being efficient and small in code size. If you're planning to contribute such a driver, please discuss with the maintainers and the community first. You could start with a [Discussion](https://github.com/micropython/micropython/discussions) or make a Pull Request that only adds the docs for your proposed API.
* If a new driver has port- or hardware-specific features that aren't suitable for a [machine](https://docs.micropython.org/en/latest/library/machine.html) API then consider adding them to a [port-specific library](https://docs.micropython.org/en/latest/library/index.html#port-specific-libraries). (Except `pyb`, this is legacy and new code should go into `stm` instead). This allows more freedom to expose the hardware's exact capabilities.
## Ports
@ -83,4 +85,4 @@ All PRs will trigger GitHub Actions to run the continuous integration (CI). This
## Updating PRs
When updating a PR, either due to review feedback or to fix CI issues, you should update your branch locally and then force push it to your GitHub branch that the PR was created from. When updating your branch, this typically involves either editing the commits directly via rebase, or adding new commits then "fix"-ing them into the existing commits during a rebase. Please fetch the upstream and rebase your branch on `master` before pushing.
When updating a PR, either due to review feedback or to fix CI issues, you should update your branch locally and then force push it to your GitHub branch that the PR was created from. When updating your branch, this typically involves either editing the commits directly via rebase, or adding new commits then "fix"-ing them into the existing commits during a rebase. Please fetch the upstream and rebase your branch on `master` before pushing.