README.md: modify installation instructions after repo split (#1407)
This commit is contained in:
Anton Evangelatov
committed by
GitHub
GitHub
parent
b046760db1
commit
c5430df218
24
README.md
24
README.md
@ -4,7 +4,7 @@
|
||||
|
||||
Swarm is a distributed storage platform and content distribution service, a native base layer service of the ethereum web3 stack. The primary objective of Swarm is to provide a decentralized and redundant store for dapp code and data as well as block chain and state data. Swarm is also set out to provide various base layer services for web3, including node-to-node messaging, media streaming, decentralised database services and scalable state-channel infrastructure for decentralised service economies.
|
||||
|
||||
[](https://travis-ci.org/ethereum/go-ethereum)
|
||||
[](https://travis-ci.org/ethersphere/swarm)
|
||||
[](https://gitter.im/ethersphere/orange-lounge?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
|
||||
|
||||
## Table of Contents
|
||||
@ -27,15 +27,15 @@ Swarm is a distributed storage platform and content distribution service, a nati
|
||||
|
||||
Building Swarm requires Go (version 1.10 or later).
|
||||
|
||||
go get -d github.com/ethereum/go-ethereum
|
||||
go get -d github.com/ethersphere/swarm
|
||||
|
||||
go install github.com/ethereum/go-ethereum/cmd/swarm
|
||||
go install github.com/ethersphere/swarm/cmd/swarm
|
||||
|
||||
## Running Swarm
|
||||
|
||||
Going through all the possible command line flags is out of scope here, but we've enumerated a few common parameter combos to get you up to speed quickly on how you can run your own Swarm node.
|
||||
|
||||
To run Swarm you need an Ethereum account. You can create a new account by running the following command:
|
||||
To run Swarm you need an Ethereum account. Download and install [Geth](https://geth.ethereum.org) if you don't have it on your system. You can create a new Ethereum account by running the following command:
|
||||
|
||||
geth account new
|
||||
|
||||
@ -88,14 +88,14 @@ Swarm documentation can be found at [https://swarm-guide.readthedocs.io](https:/
|
||||
|
||||
### Go Environment
|
||||
|
||||
We assume that you have Go v1.10 installed, and `GOPATH` is set.
|
||||
We assume that you have Go v1.11 installed, and `GOPATH` is set.
|
||||
|
||||
You must have your working copy under `$GOPATH/src/github.com/ethereum/go-ethereum`.
|
||||
You must have your working copy under `$GOPATH/src/github.com/ethersphere/swarm`.
|
||||
|
||||
Most likely you will be working from your fork of `go-ethereum`, let's say from `github.com/nirname/go-ethereum`. Clone or move your fork into the right place:
|
||||
Most likely you will be working from your fork of `swarm`, let's say from `github.com/nirname/swarm`. Clone or move your fork into the right place:
|
||||
|
||||
```
|
||||
git clone git@github.com:nirname/go-ethereum.git $GOPATH/src/github.com/ethereum/go-ethereum
|
||||
git clone git@github.com:nirname/swarm.git $GOPATH/src/github.com/ethersphere/swarm
|
||||
```
|
||||
|
||||
|
||||
@ -115,7 +115,7 @@ This section explains how to run unit, integration, and end-to-end tests in your
|
||||
Testing one library:
|
||||
|
||||
```
|
||||
go test -v -cpu 4 ./swarm/api
|
||||
go test -v -cpu 4 ./api
|
||||
```
|
||||
|
||||
Note: Using options -cpu (number of cores allowed) and -v (logging even if no error) is recommended.
|
||||
@ -123,7 +123,7 @@ Note: Using options -cpu (number of cores allowed) and -v (logging even if no er
|
||||
Testing only some methods:
|
||||
|
||||
```
|
||||
go test -v -cpu 4 ./eth -run TestMethod
|
||||
go test -v -cpu 4 ./api -run TestMethod
|
||||
```
|
||||
|
||||
Note: here all tests with prefix TestMethod will be run, so if you got TestMethod, TestMethod1, then both!
|
||||
@ -228,9 +228,9 @@ Please make sure your contributions adhere to our coding guidelines:
|
||||
* Code must adhere to the official Go [formatting](https://golang.org/doc/effective_go.html#formatting) guidelines (i.e. uses [gofmt](https://golang.org/cmd/gofmt/)).
|
||||
* Code must be documented adhering to the official Go [commentary](https://golang.org/doc/effective_go.html#commentary) guidelines.
|
||||
* Pull requests need to be based on and opened against the `master` branch.
|
||||
* [Code review guidelines](https://github.com/ethereum/go-ethereum/wiki/Code-Review-Guidelines).
|
||||
* [Code review guidelines](https://github.com/ethersphere/swarm/blob/master/docs/Code-Review-Guidelines.md).
|
||||
* Commit messages should be prefixed with the package(s) they modify.
|
||||
* E.g. "swarm/fuse: ignore default manifest entry"
|
||||
* E.g. "fuse: ignore default manifest entry"
|
||||
|
||||
|
||||
## License
|
||||
|
||||
100
docs/Code-Review-Guidelines.md
Normal file
100
docs/Code-Review-Guidelines.md
Normal file
@ -0,0 +1,100 @@
|
||||
# Code Review Guidelines
|
||||
|
||||
The only way to get code into Swarm is to send a pull request. Those pull requests
|
||||
need to be reviewed by someone. This document is a guide that explains our expectations
|
||||
around PRs for both authors and reviewers.
|
||||
|
||||
## Terminology
|
||||
|
||||
* The **author** of a pull request is the entity who wrote the diff and submitted it to
|
||||
GitHub.
|
||||
* The **team** consists of people with commit rights on the Swarm repository.
|
||||
* The **reviewer** is the person assigned to review the diff. The reviewer must be a team
|
||||
member.
|
||||
* The **code owner** is the person responsible for the subsystem being modified by the PR.
|
||||
|
||||
## The Process
|
||||
|
||||
The first decision to make for any PR is whether it's worth including at all. This
|
||||
decision lies primarily with the code owner, but may be negotiated with team members.
|
||||
|
||||
To make the decision we must understand what the PR is about. If there isn't enough
|
||||
description content or the diff is too large, request an explanation. Anyone can do this
|
||||
part.
|
||||
|
||||
We expect that reviewers check the style and functionality of the PR, providing comments
|
||||
to the author using the GitHub review system. Reviewers should follow up with the PR until
|
||||
it is in good shape, then **approve** the PR. Approved PRs can be merged by any code owner.
|
||||
|
||||
When communicating with authors, be polite and respectful.
|
||||
|
||||
### Code Style
|
||||
|
||||
We expect `gofmt`ed code. For contributions of significant size, we expect authors to
|
||||
understand and use the guidelines in [Effective Go][effgo]. Authors should avoid common
|
||||
mistakes explained in the [Go Code Review Comments][revcomment] page.
|
||||
|
||||
### Functional Checks
|
||||
|
||||
For PRs that fix an issue, reviewers should try reproduce the issue and verify that the
|
||||
pull request actually fixes it. Authors can help with this by including a unit test that
|
||||
fails without (and passes with) the change.
|
||||
|
||||
For PRs adding new features, reviewers should attempt to use the feature and comment on
|
||||
how it feels to use it. Example: if a PR adds a new command line flag, use the program
|
||||
with the flag and comment on whether the flag feels useful.
|
||||
|
||||
We expect appropriate unit test coverage. Reviewers should verify that new code is covered
|
||||
by unit tests.
|
||||
|
||||
### CI
|
||||
|
||||
Code submitted must pass all unit tests and static analysis ("lint") checks. We use Travis
|
||||
CI to test code on Linux, macOS and AppVeyor to test code on Microsoft Windows.
|
||||
|
||||
For failing CI builds, the issue may not be related to the PR itself. Such failures are
|
||||
usually related to flaky tests. These failures can be ignored (authors don't need to fix
|
||||
unrelated issues), but please file a GH issue so the test gets fixed eventually.
|
||||
|
||||
### Commit Messages
|
||||
|
||||
Commit messages on the master branch should follow the rule below. PR authors are not
|
||||
required to use any particular style because the message can be modified at merge time.
|
||||
Enforcing commit message style is the responsibility of the person merging the PR.
|
||||
|
||||
The commit message style we use is similar to the style used by the Go project:
|
||||
|
||||
The first line of the change description is conventionally a one-line summary of the
|
||||
change, prefixed by the primary affected Go package. It should complete the sentence "This
|
||||
change modifies Swarm to _____." The rest of the description elaborates and should
|
||||
provide context for the change and explain what it does.
|
||||
|
||||
Template:
|
||||
|
||||
```text
|
||||
package/path: change XYZ
|
||||
|
||||
Longer explanation of the change in the commit. You can use
|
||||
multiple sentences here. It's usually best to include content
|
||||
from the PR description in the final commit message.
|
||||
|
||||
issue notices, e.g. "Fixes #42353".
|
||||
```
|
||||
|
||||
### Special Situations And How To Deal With Them
|
||||
|
||||
As a reviewer, you may find yourself in one of the situations below. Here's how to deal
|
||||
with those:
|
||||
|
||||
* The author doesn't follow up: ping them after a while (i.e. after a few days). If there
|
||||
is no further response, close the PR or complete the work yourself.
|
||||
|
||||
* Author insists on including refactoring changes alongside bug fix: We can tolerate small
|
||||
refactorings alongside any change. If you feel lost in the diff, ask the author to
|
||||
submit the refactoring as an independent PR, or at least as an independent commit in the
|
||||
same PR.
|
||||
|
||||
* Author keeps rejecting your feedback: reviewers have authority to reject any change for technical reasons. If you're unsure, ask the team for a second opinion. You may close the PR if no consensus can be reached.
|
||||
|
||||
[effgo]: https://golang.org/doc/effective_go.html
|
||||
[revcomment]: https://github.com/golang/go/wiki/CodeReviewComments
|
||||
Reference in New Issue
Block a user