|
|
|
@ -1,82 +1,45 @@
|
|
|
|
|
# How to Contribute |
|
|
|
|
|
|
|
|
|
CoreOS projects are Apache 2.0 licensed and accept contributions via Github |
|
|
|
|
pull requests. This document outlines some of the conventions on commit |
|
|
|
|
message formatting, contact points for developers and other resources to make |
|
|
|
|
getting your contribution accepted. |
|
|
|
|
CoreOS projects are [Apache 2.0 licensed](LICENSE) and accept contributions via |
|
|
|
|
GitHub pull requests. This document outlines some of the conventions on |
|
|
|
|
development workflow, commit message formatting, contact points and other |
|
|
|
|
resources to make it easier to get your contribution accepted. |
|
|
|
|
|
|
|
|
|
# Certificate of Origin |
|
|
|
|
|
|
|
|
|
By contributing to this project you agree to the Developer Certificate of |
|
|
|
|
Origin (DCO). This document was created by the Linux Kernel community and is a |
|
|
|
|
simple statement that you, as a contributor, have the legal right to make the |
|
|
|
|
contribution. |
|
|
|
|
|
|
|
|
|
``` |
|
|
|
|
Developer Certificate of Origin |
|
|
|
|
Version 1.1 |
|
|
|
|
|
|
|
|
|
Copyright (C) 2004, 2006 The Linux Foundation and its contributors. |
|
|
|
|
660 York Street, Suite 102, |
|
|
|
|
San Francisco, CA 94110 USA |
|
|
|
|
|
|
|
|
|
Everyone is permitted to copy and distribute verbatim copies of this |
|
|
|
|
license document, but changing it is not allowed. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Developer's Certificate of Origin 1.1 |
|
|
|
|
|
|
|
|
|
By making a contribution to this project, I certify that: |
|
|
|
|
|
|
|
|
|
(a) The contribution was created in whole or in part by me and I |
|
|
|
|
have the right to submit it under the open source license |
|
|
|
|
indicated in the file; or |
|
|
|
|
|
|
|
|
|
(b) The contribution is based upon previous work that, to the best |
|
|
|
|
of my knowledge, is covered under an appropriate open source |
|
|
|
|
license and I have the right under that license to submit that |
|
|
|
|
work with modifications, whether created in whole or in part |
|
|
|
|
by me, under the same open source license (unless I am |
|
|
|
|
permitted to submit under a different license), as indicated |
|
|
|
|
in the file; or |
|
|
|
|
|
|
|
|
|
(c) The contribution was provided directly to me by some other |
|
|
|
|
person who certified (a), (b) or (c) and I have not modified |
|
|
|
|
it. |
|
|
|
|
|
|
|
|
|
(d) I understand and agree that this project and the contribution |
|
|
|
|
are public and that a record of the contribution (including all |
|
|
|
|
personal information I submit with it, including my sign-off) is |
|
|
|
|
maintained indefinitely and may be redistributed consistent with |
|
|
|
|
this project or the open source license(s) involved. |
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
contribution. See the [DCO](DCO) file for details. |
|
|
|
|
|
|
|
|
|
# Email and Chat |
|
|
|
|
|
|
|
|
|
The project currently uses the general CoreOS email list and IRC channel: |
|
|
|
|
- Email: [coreos-dev](https://groups.google.com/forum/#!forum/coreos-dev) |
|
|
|
|
- IRC: #[coreos](irc://irc.freenode.org:6667/#coreos) IRC channel on freenode.org |
|
|
|
|
|
|
|
|
|
## Getting Started |
|
|
|
|
|
|
|
|
|
- Fork the repository on GitHub |
|
|
|
|
- Read the README.md for build instructions |
|
|
|
|
- Read the [README](README.md) for build and test instructions |
|
|
|
|
- Play with the project, submit bugs, submit patches! |
|
|
|
|
|
|
|
|
|
## Contribution Flow |
|
|
|
|
|
|
|
|
|
This is a rough outline of what a contributor's workflow looks like: |
|
|
|
|
|
|
|
|
|
- Create a topic branch from where you want to base your work. This is usually master. |
|
|
|
|
- Create a topic branch from where you want to base your work (usually master). |
|
|
|
|
- Make commits of logical units. |
|
|
|
|
- Make sure your commit messages are in the proper format, see below |
|
|
|
|
- Make sure your commit messages are in the proper format (see below). |
|
|
|
|
- Push your changes to a topic branch in your fork of the repository. |
|
|
|
|
- Submit a pull request |
|
|
|
|
- Make sure the tests pass, and add any new tests as appropriate. |
|
|
|
|
- Submit a pull request to the original repository. |
|
|
|
|
|
|
|
|
|
Thanks for you contributions! |
|
|
|
|
Thanks for your contributions! |
|
|
|
|
|
|
|
|
|
### Format of the Commit Message |
|
|
|
|
|
|
|
|
|
We follow a rough convention for commit messages borrowed from Angularjs. This |
|
|
|
|
We follow a rough convention for commit messages borrowed from AngularJS. This |
|
|
|
|
is an example of a commit: |
|
|
|
|
|
|
|
|
|
``` |
|
|
|
@ -86,7 +49,7 @@ is an example of a commit:
|
|
|
|
|
start for debugging. |
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
To make it more formal it looks something like this: |
|
|
|
|
The format can be described more formally as follows: |
|
|
|
|
|
|
|
|
|
``` |
|
|
|
|
<type>(<scope>): <subject> |
|
|
|
@ -96,29 +59,29 @@ To make it more formal it looks something like this:
|
|
|
|
|
<footer> |
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
The first line is the subject and should not be longer than 70 characters, the |
|
|
|
|
second line is always blank and other lines should be wrapped at 80 characters. |
|
|
|
|
This allows the message to be easier to read on github as well as in various |
|
|
|
|
The first line is the subject and should be no longer than 70 characters, the |
|
|
|
|
second line is always blank, and other lines should be wrapped at 80 characters. |
|
|
|
|
This allows the message to be easier to read on GitHub as well as in various |
|
|
|
|
git tools. |
|
|
|
|
|
|
|
|
|
### Subject Line |
|
|
|
|
#### Subject Line |
|
|
|
|
|
|
|
|
|
The subject line contains succinct description of the change. |
|
|
|
|
The subject line contains a succinct description of the change. |
|
|
|
|
|
|
|
|
|
### Allowed <type> |
|
|
|
|
- feat (feature) |
|
|
|
|
- fix (bug fix) |
|
|
|
|
- docs (documentation) |
|
|
|
|
- style (formatting, missing semi colons, …) |
|
|
|
|
- refactor |
|
|
|
|
- test (when adding missing tests) |
|
|
|
|
- chore (maintain) |
|
|
|
|
#### Allowed `<type>`s |
|
|
|
|
- *feat* (feature) |
|
|
|
|
- *fix* (bug fix) |
|
|
|
|
- *docs* (documentation) |
|
|
|
|
- *style* (formatting, missing semi colons, …) |
|
|
|
|
- *refactor* |
|
|
|
|
- *test* (when adding missing tests) |
|
|
|
|
- *chore* (maintain) |
|
|
|
|
|
|
|
|
|
### Allowed <scope> |
|
|
|
|
#### Allowed `<scope>`s |
|
|
|
|
|
|
|
|
|
Scopes could be anything specifying place of the commit change. For example store, api, etc. |
|
|
|
|
Scopes can anything specifying the place of the commit change in the code base - |
|
|
|
|
for example, "api", "store", etc. |
|
|
|
|
|
|
|
|
|
### More Details on Commits |
|
|
|
|
|
|
|
|
|
For more details see the [angularjs commit style |
|
|
|
|
For more details on the commit format, see the [AngularJS commit style |
|
|
|
|
guide](https://docs.google.com/a/coreos.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#). |
|
|
|
|