1 | # Contributing
|
2 |
|
3 | In addition to filing bugs, you may contribute by submitting patches to fix bugs in the library. Contributions may be submitted to <http://review.couchbase.com>. We use Gerrit as our code review system - and thus submitting a change requires an account there. While Github pull requests are not ignored, Gerrit pull requests will be responded to more quickly (and most likely with more detail).
|
4 |
|
5 | For something to be accepted into the codebase, it must be formatted properly and have undergone proper testing.
|
6 |
|
7 | ## Branches and Tags
|
8 |
|
9 | * The `master` branch represents the mainline branch. The master branch typically consists of content going into the next release.
|
10 | * For older series of the Couchbase Node.js SDK see the corresponding branches: 2.x = `v2` and 3.x = `v3`.
|
11 |
|
12 | ## Contributing Patches
|
13 |
|
14 | If you wish to contribute a new feature or a bug fix to the library, try to follow the following guidelines to help ensure your change gets merged upstream.
|
15 |
|
16 | ### Before you begin
|
17 |
|
18 | For any code change, ensure the new code you write looks similar to the code surrounding it. We have no strict code style policies, but do request that your code stand out as little as possible from its surrounding neighborhood (unless of course your change is stylistic in nature).
|
19 |
|
20 | If your change is going to involve a substantial amount of time or effort, please attempt to discuss it with the project developers first who will provide assistance and direction where possible.
|
21 |
|
22 | #### For new features
|
23 |
|
24 | Ensure the feature you are adding does not already exist, and think about how this feature may be useful for other users. In general less intrusive changes are more likely to be accepted.
|
25 |
|
26 | #### For fixing bugs
|
27 |
|
28 | Ensure the bug you are fixing is actually a bug (and not a usage) error, and that it has not been fixed in a more recent version. Please read the [release notes](https://docs.couchbase.com/nodejs-sdk/current/project-docs/sdk-release-notes.html) as well as the [issue tracker](https://issues.couchbase.com/projects/JSCBC/issues/) to see a list of open and resolved issues.
|
29 |
|
30 | ### Code Review
|
31 |
|
32 | #### Signing up on Gerrit
|
33 |
|
34 | Everything that is merged into the library goes through a code review process. The code review process is done via [Gerrit](http://review.couchbase.org).
|
35 |
|
36 | To sign up for a Gerrit account, go to http://review.couchbase.org and click on the _Register_ link at the top right. Once you've signed in you will need to agree to the CLA (Contributor License Agreement) by going you your Gerrit account page and selecting the _Agreements_ link on the left. When you've done that, everything should flow through just fine. Be sure that you have registered your email address at http://review.couchbase.org/#/settings/contact as many sign-up methods won't pass emails along. Note that your email address in your code commit and in the Gerrit settings must match.
|
37 |
|
38 | Add your public SSH key to Gerrit before submitting.
|
39 |
|
40 | #### Setting up your fork with Gerrit
|
41 |
|
42 | Assuming you have a repository created like so:
|
43 |
|
44 | ```
|
45 | $ git clone https://github.com/couchbase/couchnode.git
|
46 | ```
|
47 |
|
48 | you can simply perform two simple steps to get started with Gerrit:
|
49 |
|
50 | ```
|
51 | $ git remote add gerrit ssh://${USERNAME}@review.couchbase.org:29418/couchnode
|
52 | $ scp -P 29418 ${USERNAME}@review.couchbase.org:hooks/commit-msg .git/hooks
|
53 | $ chmod a+x .git/hooks/commit-msg
|
54 | ```
|
55 |
|
56 | The last change is required for annotating each commit message with a special header known as `Change-Id`. This allows Gerrit to group together different revisions of the same patch.
|
57 |
|
58 | #### Pushing a changeset
|
59 |
|
60 | Now that you have your change and a Gerrit account to push to, you need to upload the change for review. To do so, invoke the following incantation:
|
61 |
|
62 | ```
|
63 | $ git push gerrit HEAD:refs/for/master
|
64 | ```
|
65 |
|
66 | Where `gerrit` is the name of the _remote_ added earlier.
|
67 |
|
68 | #### Pushing a new patchset
|
69 |
|
70 | After a change has been pushed to Gerrit, further revisions can be made and then uploaded. These revisions are called patchsets and are associated with the the `Change-Id` created from the initial commit (see above). To push a new revision, simply ammend the commit (can also add the `--no-edit` option if no edits to the commit message are needed):
|
71 |
|
72 | ```
|
73 | $ git commit --amend
|
74 | ```
|
75 |
|
76 | Then push the revision to Gerrit:
|
77 |
|
78 | ```
|
79 | $ git push gerrit HEAD:refs/for/master
|
80 | ```
|
81 |
|
82 | Where `gerrit` is the name of the _remote_ added earlier.
|
83 |
|
84 | #### Troubleshooting
|
85 |
|
86 | You may encounter some errors when pushing. The most common are:
|
87 |
|
88 | * "You are not authorized to push to this repository". You will get this if your account has not yet been approved. Please reach out in the [forums](https://www.couchbase.com/forums/c/node-js-sdk/12) if blocked.
|
89 | * "Missing Change-Id". You need to install the `commit-msg` hook as described above. Note that even once you do this, you will need to ensure that any prior commits already have this header - this may be done by doing an interactive rebase (e.g. `git rebase -i origin/master` and selecting `reword` for all the commits; which will automatically fill in the Change-Id).
|
90 |
|
91 | #### Reviewers
|
92 |
|
93 | Once you've pushed your changeset you can add people to review. Currently these are:
|
94 |
|
95 | * Jared Casey
|
96 | * Matt Wozakowski
|
97 | * Brett Lawson
|