Commit 5131d80e authored by asynchronous rob's avatar asynchronous rob
Browse files

move over some files

parent 3bc0d72b
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
### Facilitation, Not Strongarming
We recognise that this software is merely a tool for users to create and maintain their blockchain of preference. We see that blockchains are naturally community platforms with users being the ultimate decision makers. We assert that good software will maximise user agency by facilitate user-expression on the network. As such:
* This project will strive to give users as much choice as is both reasonable and possible over what protocol they adhere to; but
* use of the project's technical forums, commenting systems, pull requests and issue trackers as a means to express individual protocol preferences is forbidden.
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [][version]
## `Polkadot` projects is a **OPENISH Open Source Project**
## What?
Individuals making significant and valuable contributions are given commit-access to a project to contribute as they see fit. A project is more like an open wiki than a standard guarded open source project.
## Rules
There are a few basic ground-rules for contributors (including the maintainer(s) of the project):
1. **No `--force` pushes** or modifying the Git history in any way. If you need to rebase, ensure you do it in your own repo.
1. **Non-master branches**, prefixed with a short name moniker (e.g. `gav-my-feature`) must be used for ongoing work.
1. **All modifications** must be made in a **pull-request** to solicit feedback from other contributors.
1. A pull-request *must not be merged until CI* has finished successfully.
1. Contributors should adhere to the [house coding style](
Merging pull requests once CI is successful:
1. A pull request that does not alter any logic (e.g. comments, dependencies, docs) may be tagged [`insubstantial`]( and merged by its author.
1. A pull request with no large change to logic that is an urgent fix may be merged after a non-author contributor has reviewed it well.
1. All other PRs should sit for 48 hours with the [`pleasereview`]( tag in order to garner feedback.
1. No PR should be merged until all reviews' comments are addressed.
Reviewing pull requests:
When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:
1. Buggy behaviour.
1. Undue maintenance burden.
1. Breaking with house coding style.
1. Pessimisation (i.e. reduction of speed as measured in the projects benchmarks).
1. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
1. Uselessness (i.e. it does not strictly add a feature or fix a known issue).
Reviews may not be used as an effective veto for a PR because:
1. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
1. It does not fit well with some other contributors' longer-term vision for the project.
## Releases
Declaring formal releases remains the prerogative of the project maintainer(s).
## Changes to this arrangement
This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.
## Heritage
These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project:
name = "polkadot"
path = "src/"
name = "polkadot"
version = "0.3.0"
authors = ["Parity Technologies <>"]
build = ""
error-chain = "0.12"
polkadot-cli = { path = "cli" }
futures = "0.1"
ctrlc = { git = "" }
vergen = "0.1"
members = [
exclude = [
travis-ci = { repository = "paritytech/polkadot", branch = "master" }
maintenance = { status = "actively-developed" }
is-it-maintained-issue-resolution = { repository = "paritytech/polkadot" }
is-it-maintained-open-issues = { repository = "paritytech/polkadot" }
# Substrate runtime requires unwinding.
panic = "unwind"
FROM phusion/baseimage:0.10.1 as builder
LABEL maintainer ""
LABEL description="This is the build stage for Polkadot. Here we create the binary."
WORKDIR /polkadot
COPY . /polkadot
RUN apt-get update && \
apt-get upgrade -y && \
apt-get install -y cmake pkg-config libssl-dev git
RUN curl -sSf | sh -s -- -y && \
export PATH=$PATH:$HOME/.cargo/bin && \
cargo build --$PROFILE
# ===== SECOND STAGE ======
FROM phusion/baseimage:0.10.0
LABEL maintainer ""
LABEL description="This is the 2nd stage: a very small image where we copy the Polkadot binary."
COPY --from=builder /polkadot/target/$PROFILE/polkadot /usr/local/bin
RUN mv /usr/share/ca* /tmp && \
rm -rf /usr/share/* && \
mv /tmp/ca-certificates /usr/share/ && \
rm -rf /usr/lib/python* && \
mkdir -p /root/.local/share/Polkadot && \
ln -s /root/.local/share/Polkadot /data
RUN rm -rf /usr/bin /usr/sbin
EXPOSE 30333 9933 9944
VOLUME ["/data"]
CMD ["/usr/local/bin/polkadot"]
This diff is collapsed.
= Polkadot
:Author: Polkadot developers
:Revision: 0.2.0
Implementation of a node in Rust.
== To play
If you'd like to play with Polkadot, you'll need to install a client like this
one. First, get Rust (1.26.1 or later) and the support software if you don't already have it:
[source, shell]
curl -sSf | sh
sudo apt install make clang pkg-config libssl-dev
Then, install Polkadot PoC-2:
[source, shell]
cargo install --git --branch v0.2 polkadot
You'll now have a `polkadot` binary installed to your `PATH`. You can drop the
`--branch v0.2` or run `cargo install --git polkadot`
to get the very latest version of Polkadot, but these instructions might not work in that case.
If you want a specific version of polkadot, say `0.2.2`, you may run `cargo install --git --tag v0.2.2 polkadot`.
=== Krumme Lanke Testnet
You will connect to the global Krumme Lanke testnet by default. To do this, just use:
[source, shell]
If you want to do anything on it (not that there's much to do), then you'll need
to get some Krumme Lanke DOTs. Ask in the Polkadot watercooler.
=== Development
You can run a simple single-node development "network" on your machine by
running in a terminal:
[source, shell]
polkadot --dev
You can muck around by cloning and building the and or just heading to
== Local Two-node Testnet
If you want to see the multi-node consensus algorithm in action locally, then
you can create a local testnet. You'll need two terminals open. In one, run:
[source, shell]
polkadot --chain=local --validator --key Alice -d /tmp/alice
and in the other, run:
[source, shell]
polkadot --chain=local --validator --key Bob -d /tmp/bob --port 30334 --bootnodes '/ip4/'
Ensure you replace `ALICE_BOOTNODE_ID_HERE` with the node ID from the output of
the first terminal.
== Hacking on Polkadot
If you'd actually like hack on Polkadot, you can just grab the source code and
build it. Ensure you have Rust and the support software installed:
[source, shell]
curl -sSf | sh
rustup update nightly
rustup target add wasm32-unknown-unknown --toolchain nightly
rustup update stable
cargo install --git
sudo apt install cmake pkg-config libssl-dev git
Then, grab the Polkadot source code:
[source, shell]
git clone
cd polkadot
Then build the code:
[source, shell]
./scripts/ # Builds the WebAssembly binaries
cargo build # Builds all native code
You can run the tests if you like:
[source, shell]
cargo test --all
You can start a development chain with:
[source, shell]
cargo run -- --dev
== Using Docker
=== The easiest way
The easiest/faster option is to use the latest image.
.First run
Let´s first check the version we have. The first time you run this command, the polkadot docker image will be downloaded. This takes a bit of time and bandwidth, be patient:
[source, shell]
docker run --rm -it chevdor/polkadot:latest polkadot --version
.Polkadot arguments
You can also pass any argument/flag that polkadot supports:
[source, shell]
docker run --rm -it chevdor/polkadot:latest polkadot --name "PolkaDocker"
.Run as deamon
Once you are done experimenting and picking the best node name :) you can start polkadot as daemon, exposes the polkadot ports and mount a volume that will keep your blockchain data locally:
[source, shell]
docker run -d -p 30333:30333 -p 9933:9933 -p 9944:9944 -v /my/local/folder:/data chevdor/polkadot:latest polkadot
.Docker image update
If you have an image such as `latest` locally, docker will *not* bother downloading the very latest that may be available.
To update:
- stop and delete your containers (`docker stop ...` `docker rm ...`)
- delete your previous image (`docker rmi chevdor/polkadot:latest`)
- run as daemon again, the very latest image will be downloaded again
=== Build your own image
To get up and running with the smallest footprint on your system, you may use the Polkadot Docker image.
You can either build it yourself (it takes a while...):
[source, shell]
=== Reporting issues
If you run into issues with polkadot when using docker, please run the following command
(replace the tag with the appropriate one if you do not use latest):
[source, shell]
docker run --rm -it chevdor/polkadot:latest polkadot --version
This will show you the polkadot version as well as the git commit ref that was used to build your container.
Just paste that in the issue you create.
== Shell completion
The Polkadot cli command supports shell auto-completion. For this to work, you will need to run the completion script matching you build and system.
Assuming you built a release version using `cargo build --release` and use `bash` run the following:
[source, shell]
source target/release/completion-scripts/polkadot.bash
You can find completion scripts for:
- bash
- fish
- zsh
- elvish
- powershell
To make this change persistent, you can proceed as follow:
=== First install
[source, shell]
mkdir -p $COMPL_DIR
cp -f target/release/completion-scripts/polkadot.bash $COMPL_DIR/
echo "source $COMPL_DIR/polkadot.bash" >> $HOME/.bash_profile
source $HOME/.bash_profile
=== Update
When you build a new version of Polkadot, the following will ensure you auto-completion script matches the current binary:
[source, shell]
mkdir -p $COMPL_DIR
cp -f target/release/completion-scripts/polkadot.bash $COMPL_DIR/
source $HOME/.bash_profile
// Copyright 2015-2018 Parity Technologies (UK) Ltd.
// This file is part of Polkadot.
// Polkadot is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
// Polkadot is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License
// along with Polkadot. If not, see <>.
extern crate vergen;
use vergen::{vergen, OutputFns};
const ERROR_MSG: &'static str = "Failed to generate metadata files";
fn main() {
// Copyright 2017 Parity Technologies (UK) Ltd.
// This file is part of Polkadot.
// Polkadot is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
// Polkadot is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License
// along with Polkadot. If not, see <>.
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment