xref: /netbsd-src/external/apache2/llvm/dist/llvm/utils/benchmark/CONTRIBUTING.md (revision 7330f729ccf0bd976a06f95fad452fe774fc7fd1)
1*7330f729Sjoerg# How to contribute #
2*7330f729Sjoerg
3*7330f729SjoergWe'd love to accept your patches and contributions to this project.  There are
4*7330f729Sjoerga just a few small guidelines you need to follow.
5*7330f729Sjoerg
6*7330f729Sjoerg
7*7330f729Sjoerg## Contributor License Agreement ##
8*7330f729Sjoerg
9*7330f729SjoergContributions to any Google project must be accompanied by a Contributor
10*7330f729SjoergLicense Agreement.  This is not a copyright **assignment**, it simply gives
11*7330f729SjoergGoogle permission to use and redistribute your contributions as part of the
12*7330f729Sjoergproject.
13*7330f729Sjoerg
14*7330f729Sjoerg  * If you are an individual writing original source code and you're sure you
15*7330f729Sjoerg    own the intellectual property, then you'll need to sign an [individual
16*7330f729Sjoerg    CLA][].
17*7330f729Sjoerg
18*7330f729Sjoerg  * If you work for a company that wants to allow you to contribute your work,
19*7330f729Sjoerg    then you'll need to sign a [corporate CLA][].
20*7330f729Sjoerg
21*7330f729SjoergYou generally only need to submit a CLA once, so if you've already submitted
22*7330f729Sjoergone (even if it was for a different project), you probably don't need to do it
23*7330f729Sjoergagain.
24*7330f729Sjoerg
25*7330f729Sjoerg[individual CLA]: https://developers.google.com/open-source/cla/individual
26*7330f729Sjoerg[corporate CLA]: https://developers.google.com/open-source/cla/corporate
27*7330f729Sjoerg
28*7330f729SjoergOnce your CLA is submitted (or if you already submitted one for
29*7330f729Sjoerganother Google project), make a commit adding yourself to the
30*7330f729Sjoerg[AUTHORS][] and [CONTRIBUTORS][] files. This commit can be part
31*7330f729Sjoergof your first [pull request][].
32*7330f729Sjoerg
33*7330f729Sjoerg[AUTHORS]: AUTHORS
34*7330f729Sjoerg[CONTRIBUTORS]: CONTRIBUTORS
35*7330f729Sjoerg
36*7330f729Sjoerg
37*7330f729Sjoerg## Submitting a patch ##
38*7330f729Sjoerg
39*7330f729Sjoerg  1. It's generally best to start by opening a new issue describing the bug or
40*7330f729Sjoerg     feature you're intending to fix.  Even if you think it's relatively minor,
41*7330f729Sjoerg     it's helpful to know what people are working on.  Mention in the initial
42*7330f729Sjoerg     issue that you are planning to work on that bug or feature so that it can
43*7330f729Sjoerg     be assigned to you.
44*7330f729Sjoerg
45*7330f729Sjoerg  1. Follow the normal process of [forking][] the project, and setup a new
46*7330f729Sjoerg     branch to work in.  It's important that each group of changes be done in
47*7330f729Sjoerg     separate branches in order to ensure that a pull request only includes the
48*7330f729Sjoerg     commits related to that bug or feature.
49*7330f729Sjoerg
50*7330f729Sjoerg  1. Do your best to have [well-formed commit messages][] for each change.
51*7330f729Sjoerg     This provides consistency throughout the project, and ensures that commit
52*7330f729Sjoerg     messages are able to be formatted properly by various git tools.
53*7330f729Sjoerg
54*7330f729Sjoerg  1. Finally, push the commits to your fork and submit a [pull request][].
55*7330f729Sjoerg
56*7330f729Sjoerg[forking]: https://help.github.com/articles/fork-a-repo
57*7330f729Sjoerg[well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
58*7330f729Sjoerg[pull request]: https://help.github.com/articles/creating-a-pull-request
59