You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(keep reading if you're contributing on behalf of your employer)
13
13
* Create a ticket for your change on the [bug tracker](http://tickets.opscode.com)
14
14
* Link to your patch as a rebased git branch or pull request from the ticket
@@ -19,7 +19,7 @@ We regularly review contributions and will get back to you if we have any sugges
19
19
## The Apache License and the CLA/CCLA
20
20
21
21
Licensing is very important to open source projects, it helps ensure the software continues to be available under the terms that the author desired.
22
-
Chef uses the Apache 2.0 license to strike a balance between open contribution and allowing you to use the software however you would like to.
22
+
Chef uses the Apache 2.0 license to strike a balance between open contribution and allowing you to use the software however you would like to.
23
23
24
24
The license tells you what rights you have that are provided by the copyright holder. It is important that the contributor fully understands what rights
25
25
they are licensing and agrees to them. Sometimes the copyright holder isn't the contributor, most often when the contributor is doing work for a company.
@@ -43,26 +43,26 @@ such as:
43
43
* Discussion regarding the design and merits of features
44
44
* Error output to aid in finding similar bugs
45
45
46
-
Each ticket should aim to fix one bug or add one feature.
46
+
Each ticket should aim to fix one bug or add one feature.
47
47
48
48
## Using git
49
49
50
-
You can get a quick copy of the chef repository by running `git clone git://github.com/opscode/chef.git`.
50
+
You can get a quick copy of the chef repository by running `git clone git://github.com/opscode/chef.git`.
51
51
52
-
For collaboration purposes, it is best if you create a Github account and fork the repository to your own account.
52
+
For collaboration purposes, it is best if you create a Github account and fork the repository to your own account.
53
53
Once you do this you will be able to push your changes to your Github repository for others to see and use.
54
54
55
55
### Branches and Commits
56
56
57
57
You should submit your patch as a git branch named after the ticket, such as CHEF-1337.
58
-
This is called a _topic branch_ and allows users to associate a branch of code with the ticket.
58
+
This is called a _topic branch_ and allows users to associate a branch of code with the ticket.
59
59
60
60
It is a best practice to have your commit message have a _summary line_ that includes the ticket number,
61
61
followed by an empty line and then a brief description of the commit. This also helps other contributors
62
62
understand the purpose of changes to the code.
63
63
64
64
CHEF-3435: Create deploy dirs before calling scm_provider
65
-
65
+
66
66
The SCM providers have an assertation that requires the deploy directory to
67
67
exist. The deploy provider will create missing directories, we don't converge
68
68
the actions before we call run_action against the SCM provider, so it is not
@@ -76,7 +76,7 @@ helpful to be clear about your use case and change so they can understand it eve
76
76
77
77
All of Opscode's open source projects are available on [Github](http://www.github.com/opscode).
78
78
79
-
We don't require you to use Github, and we will even take patch diffs attached to tickets on the tracker.
79
+
We don't require you to use Github, and we will even take patch diffs attached to tickets on the tracker.
80
80
However Github has a lot of convenient features, such as being able to see a diff of changes between a
81
81
pull request and the main repository quickly without downloading the branch.
82
82
@@ -92,14 +92,14 @@ Additional help with git is available on the [Working with Git](http://wiki.opsc
92
92
93
93
There are rspec unit tests in the 'spec' directory. If you don't have rspec already installed, you can use the 'bundler'
94
94
gem to help you get the necessary prerequisites by running `sudo gem install bundler` and then `bundle install` from
95
-
the chef respository. You can run the chef client spec tests by running `rspec spec/*` or `rake spec` from the chef
95
+
the chef respository. You can run the chef client spec tests by running `rspec spec/*` or `rake spec` from the chef
96
96
directory of the chef repository.
97
97
98
-
These tests should pass successfully on Ruby 1.8 and 1.9 on all of the platforms that Chef runs on. It is good to run the tests
98
+
These tests should pass successfully on Ruby 1.8 and 1.9 on all of the platforms that Chef runs on. It is good to run the tests
99
99
once on your system before you get started to ensure they all pass so you have a valid baseline. After you write your patch,
100
100
run the tests again to see if they all pass.
101
101
102
-
If any don't pass, investigate them before submitting your patch.
102
+
If any don't pass, investigate them before submitting your patch.
103
103
104
104
These tests don't modify your system, and sometimes tests fail because a command that would be run has changed because of your
105
105
patch. This should be a simple fix. Other times the failure can show you that an important feature no longer works because of
@@ -136,7 +136,7 @@ The versioning for the Chef project is X.Y.Z.
136
136
137
137
Major releases and have historically been once a year. Minor releases for Chef average every two months and patch releases come as needed.
138
138
139
-
There are usually beta releases and release candidates (RC) of major and minor releases announced on
139
+
There are usually beta releases and release candidates (RC) of major and minor releases announced on
140
140
the [chef-dev mailing list](http://lists.opscode.com/sympa/info/chef-dev). Once an RC is released, we wait at least three
141
141
days to allow for testing for regressions before the final release. If a blocking regression is found then another RC is made containing
0 commit comments