|
8 | 8 | ## Making Changes
|
9 | 9 |
|
10 | 10 | * Create a topic branch from where you want to base your work.
|
11 |
| - * This is the `master` branch in the case of rototiller |
12 |
| - * To quickly create a topic branch based on master use `git checkout -b my_contribution master`. Do not work directly on the `master` branch. |
| 11 | + * This is the `master` branch for breaking changes in major version releases, the `stable` branch for non-breaking changes and bug-fixes in Y or Z releases. |
| 12 | + * To quickly create a topic branch based on master use `git checkout -b my_contribution master`. Do not work directly on the `master` nor `stable` branches. |
13 | 13 | * Make commits of logical _working_ and _functional_ units.
|
14 | 14 | * Check for unnecessary whitespace with `git diff --check` before committing.
|
15 |
| -* Make sure your commit messages are in the proper format. |
| 15 | +* Make sure your commit messages are in the proper format (a ticket ID is required in most cases). |
16 | 16 |
|
17 | 17 | (BKR-1234) Make the example in CONTRIBUTING imperative and concrete
|
18 | 18 |
|
|
28 | 28 |
|
29 | 29 | * Make sure you have added [RSpec](http://rspec.info/) tests that exercise your new code. These test should be located in the appropriate `rototiller/spec/` subdirectory. The addition of new methods/classes or the addition of code paths to existing methods/classes requires additional RSpec coverage.
|
30 | 30 | * One should **NOT USE** the deprecated `should`/`stub` methods - **USE** `expect`/`allow`. Use of deprecated RSpec methods will result in your patch being rejected. See a nice blog post from 2013 on [RSpec's new message expectation syntax](http://teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/).
|
31 |
| -* Run the spec unit tests to assure nothing else was accidentally broken, using `rake test` |
32 |
| - * **Bonus**: if possible ensure that `[bundle exec] rake test` runs without failures for additional Ruby versions (1.9, 2.0, etc). Rototiller supports Ruby 1.9+, and breakage of support for other rubies will cause a patch to be rejected. |
33 |
| -* Make sure that if you have added new functionality of sufficiently high risk, and it can not be covered adequately via unit tests (mocking, requires disk, other classes, etc), you also include acceptance tests in your PR. |
| 31 | +* Run the rspec unit tests to assure nothing else was accidentally broken, using `rake test` |
| 32 | + * **Bonus**: if possible ensure that `[bundle exec] rake test` runs without failures for additional Ruby versions (1.9, 2.0, etc). Rototiller supports Ruby 1.9.3+, and breakage of support for other rubies will cause a patch to be rejected. |
| 33 | +* Make sure that if you have added new functionality of sufficiently high risk, and it can not be covered adequately via unit tests (mocking, requires disk, other classes, etc). |
| 34 | + * you should also include integration or acceptance tests in your PR, where applicable |
| 35 | + * integration tests are unit tests that access the filesystem, network, or fully integrate the product |
| 36 | + * acceptance tests are typically end-to-end tests ensuring changes to installers, or behavior that is difficult to validate in integration. |
34 | 37 | * Make sure that you have added documentation using [Yard](http://yardoc.org/), new methods/classes without appropriate documentation will be rejected.
|
35 | 38 | * Run the yardoc tool to ensure that your yard documentation is properly formatted and complete
|
36 | 39 | * `[bundle exec] rake docs:gen`
|
37 | 40 | * Yard docs are great for other developers, but often are difficult to read for users. If your change impacts user-facing functionality, please include changes to the human-readable markdown docs starting at README.md
|
38 |
| -* During the time that you are working on your patch the master Rototiller branch may have changed - you'll want to [rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) before you submit your PR with `git rebase master`. A successful rebase ensures that your patch will cleanly merge into Rototiller. |
39 |
| -* Submitted patches will be smoke tested through a series of acceptance level tests that ensures basic Rototiller functionality - the results of these tests will be evaluated by a Rototiller team member. Failures associated with the submitted patch will result in the patch being rejected. |
| 41 | +* During the time that you are working on your patch the master Rototiller branch may have changed - you'll want to [rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) before you submit your PR with `git rebase master`. A successful rebase ensures that your patch will cleanly merge into the project. |
| 42 | +* Submitted patches will be smoke tested through a series of tests that ensures code standards, code functionality and user functionality - the results of these tests will be evaluated by a team member. Failures associated with the submitted patch will result in the patch being rejected. |
40 | 43 |
|
41 | 44 | ## Submitting Changes
|
42 | 45 |
|
43 | 46 | * Sign the [Contributor License Agreement](http://links.puppet.com/cla).
|
44 | 47 | * Push your changes to a topic branch in _your_ fork of the repository.
|
45 |
| -* Submit a pull request to [Rototiller](https://github.com/puppetlabs/rototiller) |
| 48 | +* Submit a [pull request](http://help.github.com/send-pull-requests/) to [Rototiller](https://github.com/puppetlabs/rototiller) |
46 | 49 | * PRs are reviewed as time permits.
|
47 | 50 |
|
48 | 51 | # Additional Resources
|
|
55 | 58 | * [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
|
56 | 59 | * Questions? Comments? Contact the Rototiller team at [email protected]
|
57 | 60 | * The keyword `rototiller` is monitored and we'll get back to you as quick as we can.
|
58 |
| -* Rototiller's Architecture: [Rototiller's Architecture](docs/rototiller_class_graph.png) |
59 |
| - |
60 |
| -## Submitting Changes |
61 |
| - |
62 |
| -* Sign the [Contributor License Agreement](http://links.puppet.com/cla). |
63 |
| -* Push your changes to a topic branch in _your_ fork of the repository. |
64 |
| -* Submit a pull request to [Rototiller](https://github.com/puppetlabs/rototiller) |
65 |
| -* PRs are reviewed as time permits. |
66 |
| - |
67 |
| -# Additional Resources |
68 |
| - |
69 |
| -* [More information on contributing](http://links.puppet.com/contribute-to-puppet) |
70 |
| -* [Contributor License Agreement](http://links.puppet.com/cla) |
71 |
| -* [General GitHub documentation](http://help.github.com/) |
72 |
| -* [GitHub pull request documentation](http://help.github.com/send-pull-requests/) |
73 |
| -* Questions? Comments? Contact the Rototiller team at [email protected] |
74 |
| - * The keyword `rototiller` is monitored and we'll get back to you as quick as we can. |
0 commit comments