cerc-io/laconicd
17
0
Fork 2
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases 9 Wiki Activity

address PR comments

Browse Source
This commit is contained in:
Jack Zampolin 2018-07-09 18:18:30 -07:00
parent a18d98a24e
commit 3355a59bf8
1 changed files with 9 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
CONTRIBUTING.md
View File

@ -23,8 +23,8 @@ For instance, to create a fork and work on a branch of it, One would:
* `git remote rename origin upstream` * `git remote rename origin upstream`
* `git remote add origin git@github.com:<username>/ethermint.git` * `git remote add origin git@github.com:<username>/ethermint.git`
Now `origin` refers to my fork and `upstream` refers to the Cosmos-SDK version. Now `origin` refers to my fork and `upstream` refers to the Ethermint version.
So I can `git push -u origin <branch>` to update my fork, and make pull requests to Cosmos-SDK from there. So I can `git push -u origin <branch>` to update my fork, and make pull requests to Ethermint from there.
Of course, replace `<username>` with your git handle. Of course, replace `<username>` with your git handle.
To pull in updates from the origin repo, run To pull in updates from the origin repo, run
@ -45,7 +45,7 @@ software.
Since some dependencies are not under our control, a third party may break our Since some dependencies are not under our control, a third party may break our
build, in which case we can fall back on `dep ensure` (or `make build, in which case we can fall back on `dep ensure` (or `make
get_vendor_deps`). Even for dependencies under our control, `dep` helps us to get-vendor-deps`). Even for dependencies under our control, `dep` helps us to
keep multiple repos in sync as they evolve. Anything with an executable, such keep multiple repos in sync as they evolve. Anything with an executable, such
as apps, tools, and the core, should use `dep`. as apps, tools, and the core, should use `dep`.
@ -68,19 +68,21 @@ That is, these repos should be well versioned, and any merge to master requires
Libraries need not follow the model strictly, but would be wise to. Libraries need not follow the model strictly, but would be wise to.
The SDK utilizes [semantic versioning](https://semver.org/). Ethermint utilizes [semantic versioning](https://semver.org/).
### Development Procedure: ### Development Procedure:
- the latest state of development is on `develop` - the latest state of development is on `develop`
- `develop` must never fail `make test` - `develop` must never fail `make test`
- `develop` should not fail `make test_lint` - `develop` should not fail `make test-lint`
- no --force onto `develop` (except when reverting a broken commit, which should seldom happen) - no --force onto `develop` (except when reverting a broken commit, which should seldom happen)
- create a development branch either on github.com/cosmos/cosmos-sdk, or your fork (using `git remote add origin`) - create a development branch either on github.com/cosmos/ethermint, or your fork (using `git remote add origin`)
- [squash your commits](https://github.com/todotxt/todo.txt-android/wiki/Squash-All-Commits-Related-to-a-Single-Issue-into-a-Single-Commit) into an individual commit
- before submitting a pull request, begin `git rebase` on top of `develop` - before submitting a pull request, begin `git rebase` on top of `develop`
### Pull Merge Procedure: ### Pull Merge Procedure:
- ensure pull branch is rebased on develop - ensure pull branch is rebased on develop
- run `make test` and `make test_cli` to ensure that all tests pass - [squash your commits](https://github.com/todotxt/todo.txt-android/wiki/Squash-All-Commits-Related-to-a-Single-Issue-into-a-Single-Commit) into an individual commit
- run `make test` and `make test-cli` to ensure that all tests pass
- merge pull request - merge pull request
- push master may request that pull requests be rebased on top of `unstable` - push master may request that pull requests be rebased on top of `unstable`