mirror of
https://github.com/ethereum/go-ethereum.git
synced 2026-03-10 13:19:04 +00:00
388d8ccd9f
* simv2: wip * simulation: exec adapter start/stop * simulation: add node status to exec adapter * simulation: initial simulation code * simulation: exec adapter, configure path to executable * simulation: initial docker adapter * simulation: wip kubernetes adapter * simulation: kubernetes adapter proxy * simulation: implement GetAll/StartAll/StopAll * simulation: kuberentes adapter - set env vars and resource limits * simulation: discovery test * simulation: remove port definitions within docker adapter * simulation: simplify wait for healthy loop * simulation: get nat ip addr from interface * simulation: pull docker images automatically * simulation: NodeStatus -> NodeInfo * simulation: move discovery test to example dir * simulation: example snapshot usage * simulation: add goclient specific simulation * simulation: add peer connections to snapshot * simulation: close rpc client * simulation: don't export kubernetes proxy server * simulation: merge simulation code * simulation: don't export nodemap * simulation: rename SimulationSnapshot -> Snapshot * simulation: linting fixes * simulation: add k8s available helper func * simulation: vendor * simulation: fix 'no non-test Go files' when building * simulation: remove errors from interface methods where non were returned * simulation: run getHealthInfo check in parallel
67 lines
3.1 KiB
Markdown
67 lines
3.1 KiB
Markdown
# How to contribute #
|
|
|
|
We'd love to accept your patches and contributions to this project. There are
|
|
a just a few small guidelines you need to follow.
|
|
|
|
|
|
## Contributor License Agreement ##
|
|
|
|
Contributions to any Google project must be accompanied by a Contributor
|
|
License Agreement. This is not a copyright **assignment**, it simply gives
|
|
Google permission to use and redistribute your contributions as part of the
|
|
project.
|
|
|
|
* If you are an individual writing original source code and you're sure you
|
|
own the intellectual property, then you'll need to sign an [individual
|
|
CLA][].
|
|
|
|
* If you work for a company that wants to allow you to contribute your work,
|
|
then you'll need to sign a [corporate CLA][].
|
|
|
|
You generally only need to submit a CLA once, so if you've already submitted
|
|
one (even if it was for a different project), you probably don't need to do it
|
|
again.
|
|
|
|
[individual CLA]: https://developers.google.com/open-source/cla/individual
|
|
[corporate CLA]: https://developers.google.com/open-source/cla/corporate
|
|
|
|
|
|
## Submitting a patch ##
|
|
|
|
1. It's generally best to start by opening a new issue describing the bug or
|
|
feature you're intending to fix. Even if you think it's relatively minor,
|
|
it's helpful to know what people are working on. Mention in the initial
|
|
issue that you are planning to work on that bug or feature so that it can
|
|
be assigned to you.
|
|
|
|
1. Follow the normal process of [forking][] the project, and setup a new
|
|
branch to work in. It's important that each group of changes be done in
|
|
separate branches in order to ensure that a pull request only includes the
|
|
commits related to that bug or feature.
|
|
|
|
1. Go makes it very simple to ensure properly formatted code, so always run
|
|
`go fmt` on your code before committing it. You should also run
|
|
[golint][] over your code. As noted in the [golint readme][], it's not
|
|
strictly necessary that your code be completely "lint-free", but this will
|
|
help you find common style issues.
|
|
|
|
1. Any significant changes should almost always be accompanied by tests. The
|
|
project already has good test coverage, so look at some of the existing
|
|
tests if you're unsure how to go about it. [gocov][] and [gocov-html][]
|
|
are invaluable tools for seeing which parts of your code aren't being
|
|
exercised by your tests.
|
|
|
|
1. Do your best to have [well-formed commit messages][] for each change.
|
|
This provides consistency throughout the project, and ensures that commit
|
|
messages are able to be formatted properly by various git tools.
|
|
|
|
1. Finally, push the commits to your fork and submit a [pull request][].
|
|
|
|
[forking]: https://help.github.com/articles/fork-a-repo
|
|
[golint]: https://github.com/golang/lint
|
|
[golint readme]: https://github.com/golang/lint/blob/master/README
|
|
[gocov]: https://github.com/axw/gocov
|
|
[gocov-html]: https://github.com/matm/gocov-html
|
|
[well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
|
[squash]: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits
|
|
[pull request]: https://help.github.com/articles/creating-a-pull-request
|