Important: Feature freeze / release candidate phase for Betaflight 3.3
From 01/02/2018 until the release of Betaflight 3.3.0 (scheduled for 01/03/2018), the project is in a 'feature freeze / release candidate' phase. This means:
Pull requests can still be submitted as normal. Comments / discussions will probably be slower than normal due to shifted priorities;
If your pull request is a fix for an existing bug, or an update for a single target that has a low risk of side effect for other targets, it will be reviewed, and if accepted merged into master for the 3.3 release;
All other pull requests will be scheduled for 3.4, and discussed / reviewed / merged into master after 3.3.0 has been released. Please keep in mind that this will potentially mean that you will have to rebase your changes if they are broken by bugfixes made to 3.3.
Important considerations when opening a pull request:
Pull requests will only be accepted if they are opened against the master branch. Pull requests opened against other branches without prior consent from the maintainers will be closed;
Keep your pull requests as small and concise as possible. One pull request should only ever add / update one feature. If the change that you are proposing has a wider scope, consider splitting it over multiple pull requests. In particular, pull requests that combine changes to features and one or more new targets are not acceptable.
Ideally, a pull request should contain only one commit, with a descriptive message. If your changes use more than one commit, rebase / squash them into one commit before submitting a pull request. If you need to amend your pull request, make sure that the additional commit has a descriptive message, or - even better - use git commit --amend to amend your original commit.
All pull requests are reviewed. Be ready to receive constructive criticism, and to learn and improve your coding style. Also, be ready to clarify anything that isn't already sufficiently explained in the code and text of the pull request, and to defend your ideas.
If your pull request is a fix for one or more issues that are open in GitHub, add a comment to your pull request, and add the issue numbers of the issues that are fixed in the form Fixes #<issue number>. This will cause the issues to be closed when the pull request is merged;
Important: Feature freeze / release candidate phase for Betaflight 3.3
From 01/02/2018 until the release of Betaflight 3.3.0 (scheduled for 01/03/2018), the project is in a 'feature freeze / release candidate' phase. This means:
Pull requests can still be submitted as normal. Comments / discussions will probably be slower than normal due to shifted priorities;
If your pull request is a fix for an existing bug, or an update for a single target that has a low risk of side effect for other targets, it will be reviewed, and if accepted merged into
masterfor the 3.3 release;All other pull requests will be scheduled for 3.4, and discussed / reviewed / merged into
masterafter 3.3.0 has been released. Please keep in mind that this will potentially mean that you will have to rebase your changes if they are broken by bugfixes made to 3.3.Important considerations when opening a pull request:
Pull requests will only be accepted if they are opened against the
masterbranch. Pull requests opened against other branches without prior consent from the maintainers will be closed;Please follow the coding style guidlines: https://github.com/cleanflight/cleanflight/blob/master/docs/development/CodingStyle.md
Keep your pull requests as small and concise as possible. One pull request should only ever add / update one feature. If the change that you are proposing has a wider scope, consider splitting it over multiple pull requests. In particular, pull requests that combine changes to features and one or more new targets are not acceptable.
Ideally, a pull request should contain only one commit, with a descriptive message. If your changes use more than one commit, rebase / squash them into one commit before submitting a pull request. If you need to amend your pull request, make sure that the additional commit has a descriptive message, or - even better - use
git commit --amendto amend your original commit.All pull requests are reviewed. Be ready to receive constructive criticism, and to learn and improve your coding style. Also, be ready to clarify anything that isn't already sufficiently explained in the code and text of the pull request, and to defend your ideas.
If your pull request is a fix for one or more issues that are open in GitHub, add a comment to your pull request, and add the issue numbers of the issues that are fixed in the form
Fixes #<issue number>. This will cause the issues to be closed when the pull request is merged;Remove this Text :).