pingu_98/MrDraw
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Allow PRs against maintenance for bug fixes

Browse source
This commit is contained in:
Gina Häußge 2017-03-09 11:49:55 +01:00
parent 8a4934e6f8
commit 2d9c16e859
1 changed files with 17 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
CONTRIBUTING.md
View file

@ -258,15 +258,16 @@ See [the corresponding chapter in the documentation](http://docs.octoprint.org/e
just cause unnecessary work and frustration for everyone or
possibly get the PR rejected.
3. Create your pull request **from a custom branch** on your end (e.g.
`dev/myNewFeature`)[1] **against the `devel` branch**. Create **one pull request
per feature/bug fix**. If your PR contains an important bug fix, we will
make sure to backport it to the `maintenance` branch to also include it in
the next release.
4. Make sure there are **only relevant changes** included in your PR. No
`dev/myNewFeature`)[1].
4. Create your pull request **only against the `maintenance` or `devel` branch**:
* if it's a bug fix for a bug in the current stable version: `maintenance` branch
* otherwise: `devel` branch
5. Create **one pull request per feature/bug fix**.
6. Make sure there are **only relevant changes** included in your PR. No
changes to unrelated files, no additional files that don't belong (e.g.
commits of your full virtual environment). Make sure your PR consists
**ideally of only one commit** (use git's rebase and squash functionality).
5. Make sure you **follow the current coding style**. This means:
7. Make sure you **follow the current coding style**. This means:
* Tabs instead of spaces in the Python files[2]
* Spaces instead of tabs in the JavaScript sources
* English language (code, variables, comments, ...)
@ -277,22 +278,22 @@ See [the corresponding chapter in the documentation](http://docs.octoprint.org/e
``.less`` files from which the CSS is compiled.
* Make sure you do not add dead code (e.g. commented out left-overs
from experiments).
6. Ensure your changes **pass the existing unit tests**. PRs that break
8. Ensure your changes **pass the existing unit tests**. PRs that break
those cannot be accepted.
7. **Test your changes thoroughly**. That also means testing with usage
9. **Test your changes thoroughly**. That also means testing with usage
scenarios you don't normally use, e.g. if you only use access control, test
without and vice versa. If you only test with your printer, test with the
virtual printer and vice versa. State in your pull request how you tested
your changes. Ideally **add unit tests** - OctoPrint severely lacks in that
department, but we are trying to change that, so any new code already covered
with a test suite helps a lot!
8. In your pull request's description, **state what your pull request does**,
as in, what feature does it implement, what bug does it fix. The more
thoroughly you explain your intent behind the PR here, the higher the
chances it will get merged fast. There is a template provided below
that can help you here.
9. Don't forget to **add yourself to the [AUTHORS](./AUTHORS.md)
file** :)
10. In your pull request's description, **state what your pull request does**,
as in, what feature does it implement, what bug does it fix. The more
thoroughly you explain your intent behind the PR here, the higher the
chances it will get merged fast. There is a template provided below
that can help you here.
11. Don't forget to **add yourself to the [AUTHORS](./AUTHORS.md)
file** :)
Template to use for Pull Request descriptions:
@ -397,6 +398,7 @@ the local version identifier to allow for an exact determination of the active c
* 2016-09-23: Some more work on "How to file a bug report" based on recent
experiences
* 2017-01-25: Fixed a typo
* 2017-03-09: Allow PRs against `maintenance` branch for bugs in stable.
## Footnotes
* [1] - If you are wondering why, the problem is that anything that you add