...
- Be mindful of the Criteria For Acceptance, and
- Feel free to communicate with the dev@nuttx.apache.org mailing list as often as you need to for guidance.
- Submit Your Changes
- At this point, you have fixed a bug, implemented a new feature, or made some other improvement to your local copy of NuttX. To get your changes into the official NuttX repositories, it helps tremendously if you can package them into a format that conveys the changes accurately.
Submit Your Changes For Review
As stated earlier, how you submit changes will depend upon what kind of local environment you have created to manage your NuttX-based development:
- If you are using a versioned NuttX release, which comes with no SCM information, you will probably need to send patches. See If Working From a Versioned NuttX Release below.
- If you are using a clone or fork of the GIT repositories, then you might want to send have several options, including Pull Requests (PRs) to submit changes, but. See If Working From a Clone or Fork of the GIT Repositories below.
- If you are using a versioned release branch in the GIT repositories, then you will have to do things a little differently.
These are described in detail in the following sections:
Submit Your Changes For Review
- See If Working Using a Versioned Release Branch below.
If Working From a Versioned NuttX Release
REVISIT: Describe in detail, how to make the relevant patch(es) .when working with a versioned NuttX release tarball with no SCM information.
If Working From a Clone or Fork of the GIT Repositories
...
When working from a clone or form of the GIT repositories, you can submit your changes by one of the following methods:
- Generating a Patch from a Clone
- Generating a GitHub Pull-Request from a Fork
- Generating a Textual GIT Pull-Request from a Clone
Generating a Patch from a Clone
. If you are working from a clone of the repository, you can create a patch using this GIT command:
...
The generated patch should be sent to dev@nuttx.apache.org. To make sure that your patch email is noticed, please start the subject line with [PATCH] and a brief description. It is best to send the patch as an attachment with a .txt extension, as that ensures it gets the correct MIME type and isn't blocked by the mailing list's spam filter.
Generating a GitHub Pull-
...
Request from a Fork
. If you are working on a fork, you have the option of creating a Pull-Request (PR) instead. To create a pull request on a fork, do the following steps (from https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork):
...
REVISIT: Use of multiple forks would require multiple accounts. Unlike Bitbucket, GitHub will not let you have multiple forks with different names under the same account. (Note from Nathan: For this reason, each functionally unrelated change should be done in its own branch, with each PR created from the branch. I recommend to always develop on a branch, never on master.)
REVISIT: By emailing a patch: Describe how to make the relevant patch(es) (git format-patch) and send them to dev@nuttx.apache.org.
Generating a Textual GIT Pull-Request from a Clone
A textual GIT pull-request is similar to a GIT patch, except that it provides additional context that makes it easier to integrate the change with the upstream repository.
REVISIT: Describe how to make a textual GIT pull request REVISIT: By emailing a textual GIT pull request: Describe how to make the relevant file (git request-pull) and send to dev@nuttx.apache.org.
...