diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -34,8 +34,8 @@ reviewed, and committed. Changes should not sit in a queue for long. Here are some tips to help keep the development working as intended. These -are guidelines for the normal and expected development process. Developers -can use their judgement to deviate from these guidelines when they have a +are guidelines for the normal and expected development process. Developers +can use their judgement to deviate from these guidelines when they have a good reason to do so. - Keep each change small and self-contained. @@ -56,7 +56,7 @@ - Don't break the build, it is important to keep master green as much as possible. If a Diff is landed, and breaks the build, fix it quickly. If it cannot be fixed quickly, it should be reverted, and re-applied later when it no longer breaks the build. -- As soon as you see a bug, you fix it. Do not continue on. Fixing the bug becomes the +- As soon as you see a bug, you fix it. Do not continue on. Fixing the bug becomes the top priority, more important than completing other tasks. - Automate as much as possible, and spend time on things only humans can do. @@ -64,7 +64,7 @@ - [Developer Notes](doc/developer-notes.md) - [Statement of Bitcoin ABC Values and Visions](https://www.yours.org/content/bitcoin-abc---our-values-and-vision-a282afaade7c) -- [How to Do Code Reviews Like a Human - Part 1](https://mtlynch.io/human-code-reviews-1/) +- [How to Do Code Reviews Like a Human - Part 1](https://mtlynch.io/human-code-reviews-1/) - [How to Do Code Reviews Like a Human - Part 2](https://mtlynch.io/human-code-reviews-2/) - [Large Diffs Are Hurting Your Ability To Ship](https://medium.com/@kurtisnusbaum/large-diffs-are-hurting-your-ability-to-ship-e0b2b41e8acf) - [Stacked Diffs: Keeping Phabricator Diffs Small](https://medium.com/@kurtisnusbaum/stacked-diffs-keeping-phabricator-diffs-small-d9964f4dcfa6) diff --git a/contrib/README.md b/contrib/README.md --- a/contrib/README.md +++ b/contrib/README.md @@ -32,12 +32,12 @@ PGP keys used for signing Bitcoin Core [Gitian release](/doc/release-process.md) results. ### [MacDeploy](/contrib/macdeploy) ### -Scripts and notes for Mac builds. +Scripts and notes for Mac builds. ### [Gitian-build](/contrib/gitian-build.sh) ### Script for running full Gitian builds. -Test and Verify Tools +Test and Verify Tools --------------------- ### [TestGen](/contrib/testgen) ### diff --git a/depends/description.md b/depends/description.md --- a/depends/description.md +++ b/depends/description.md @@ -1,4 +1,4 @@ -This is a system of building and caching dependencies necessary for building Bitcoin. +This is a system of building and caching dependencies necessary for building Bitcoin. There are several features that make it different from most similar systems: ### It is designed to be builder and host agnostic @@ -26,7 +26,7 @@ consists of a hash of all files used to build the package (Makefiles, packages, etc), and as well as a hash of the same data for each recursive dependency. If any portion of a package's build recipe changes, it will be rebuilt as well as -any other package that depends on it. If any of the main makefiles (Makefile, +any other package that depends on it. If any of the main makefiles (Makefile, funcs.mk, etc) are changed, all packages will be rebuilt. After building, the results are cached into a tarball that can be re-used and distributed. diff --git a/depends/packages.md b/depends/packages.md --- a/depends/packages.md +++ b/depends/packages.md @@ -32,15 +32,15 @@ $(package)_build_subdir: cd to this dir before running configure/build/stage commands. - + $(package)_download_file: The file-name of the upstream source if it differs from how it should be stored locally. This can be used to avoid storing file-names with strange characters. - + $(package)_dependencies: Names of any other packages that this one depends on. - + $(package)_patches: Filenames of any patches needed to build the package @@ -134,7 +134,7 @@ Stage the build results. If undefined, does nothing. The following variables are available for each recipe: - + $(1)_staging_dir: package's destination sysroot path $(1)_staging_prefix_dir: prefix path inside of the package's staging dir $(1)_extract_dir: path to the package's extracted sources diff --git a/doc/backporting.md b/doc/backporting.md --- a/doc/backporting.md +++ b/doc/backporting.md @@ -61,7 +61,7 @@ 1. Backport each diff individually 2. Squash the commits together for backporting. -In either case, you will find there are likely merge conflicts. +In either case, you will find there are likely merge conflicts. Backport each diff individually ------------------------------- diff --git a/doc/build-osx.md b/doc/build-osx.md --- a/doc/build-osx.md +++ b/doc/build-osx.md @@ -45,7 +45,7 @@ You can disable the GUI build by passing `-DBUILD_BITCOIN_QT=OFF` to cmake. - It is recommended to create a build directory to build out-of-tree. + It is recommended to create a build directory to build out-of-tree. mkdir build cd build diff --git a/doc/build-windows.md b/doc/build-windows.md --- a/doc/build-windows.md +++ b/doc/build-windows.md @@ -53,7 +53,7 @@ Cross-compilation for Ubuntu and Windows Subsystem for Linux ------------------------------------------------------------ -At the time of writing the Windows Subsystem for Linux installs Ubuntu Bionic 18.04. +At the time of writing the Windows Subsystem for Linux installs Ubuntu Bionic 18.04. The steps below can be performed on Ubuntu (including in a VM) or WSL. The depends system will also work on other Linux distributions, however the commands for installing the toolchain will be different. diff --git a/doc/developer-notes.md b/doc/developer-notes.md --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -63,16 +63,16 @@ - Use CamelCase for functions/methods, and lowerCamelCase for variables. - GLOBAL_CONSTANTS should use UPPER_SNAKE_CASE. - namespaces should use lower_snake_case. - - Function names should generally start with an English command-form verb + - Function names should generally start with an English command-form verb (e.g. `ValidateTransaction`, `AddTransactionToMempool`, `ConnectBlock`) - Variable names should generally be nouns or past/future tense verbs. (e.g. `canDoThing`, `signatureOperations`, `didThing`) - Avoid using globals, remove existing globals whenever possible. - Class member variable names should be prepended with `m_` - - DO choose easily readable identifier names. + - DO choose easily readable identifier names. - DO favor readability over brevity. - DO NOT use Hungarian notation. - - DO NOT use abbreviations or contractions within identifiers. + - DO NOT use abbreviations or contractions within identifiers. - WRONG: mempool - RIGHT: MemoryPool - WRONG: ChangeDir @@ -104,11 +104,11 @@ public: /** * The documentation before a function or class method should follow Doxygen - * spec. The name of the function should start with an english verb which + * spec. The name of the function should start with an english verb which * indicates the intended purpose of this code. - * + * * The function name should be should be CamelCase. - * + * * @param[in] s A description * @param[in] n Another argument description * @pre Precondition for function... @@ -650,7 +650,7 @@ e.g.: `#include ` - Native C++ headers should be preferred over C compatibility headers. - e.g.: use `` instead of `` + e.g.: use `` instead of `` - In order to make the code consistent, header files should be included in the following order, with each section separated by a newline: @@ -660,7 +660,7 @@ 4. The 3rd party libraries headers. Different libraries should be in different sections. 5. The system libraries. -All headers should be lexically ordered inside their block. +All headers should be lexically ordered inside their block. - Use include guards to avoid the problem of double inclusion. The header file `foo/bar.h` should use the include guard identifier `BITCOIN_FOO_BAR_H`, e.g. @@ -696,7 +696,7 @@ Unit Tests ----------- - - Test suite naming convention: The Boost test suite in file + - Test suite naming convention: The Boost test suite in file `src/test/foo_tests.cpp` should be named `foo_tests`. Test suite names must be unique. diff --git a/doc/functional-tests.md b/doc/functional-tests.md --- a/doc/functional-tests.md +++ b/doc/functional-tests.md @@ -150,7 +150,7 @@ A python debugger can be attached to tests at any point. Just add the line: ```py -import pdb; pdb.set_trace() +import pdb; pdb.set_trace() ``` anywhere in the test. You will then be able to inspect variables, as well as diff --git a/doc/gitian-building.md b/doc/gitian-building.md --- a/doc/gitian-building.md +++ b/doc/gitian-building.md @@ -89,7 +89,7 @@ ./gitian-build.py --setup satoshi 0.18.5 ``` -Where `satoshi` is your Github name and `0.18.5` is the most recent tag (without `v`). +Where `satoshi` is your Github name and `0.18.5` is the most recent tag (without `v`). Build binaries -------------- @@ -109,7 +109,7 @@ ```bash export NAME=satoshi -gpg --output $VERSION-linux/$NAME/bitcoin-abc-linux-0.18.5-build.assert.sig --detach-sign 0.18.5-linux/$NAME/bitcoin-abc-linux-0.18.5-build.assert -gpg --output $VERSION-osx-unsigned/$NAME/bitcoin-abc-osx-0.18.5-build.assert.sig --detach-sign 0.18.5-osx-unsigned/$NAME/bitcoin-abc-osx-0.18.5-build.assert -gpg --output $VERSION-win-unsigned/$NAME/bitcoin-abc-win-0.18.5-build.assert.sig --detach-sign 0.18.5-win-unsigned/$NAME/bitcoin-abc-win-0.18.5-build.assert +gpg --output $VERSION-linux/$NAME/bitcoin-abc-linux-0.18.5-build.assert.sig --detach-sign 0.18.5-linux/$NAME/bitcoin-abc-linux-0.18.5-build.assert +gpg --output $VERSION-osx-unsigned/$NAME/bitcoin-abc-osx-0.18.5-build.assert.sig --detach-sign 0.18.5-osx-unsigned/$NAME/bitcoin-abc-osx-0.18.5-build.assert +gpg --output $VERSION-win-unsigned/$NAME/bitcoin-abc-win-0.18.5-build.assert.sig --detach-sign 0.18.5-win-unsigned/$NAME/bitcoin-abc-win-0.18.5-build.assert ``` diff --git a/doc/init.md b/doc/init.md --- a/doc/init.md +++ b/doc/init.md @@ -53,11 +53,11 @@ All three configurations assume several paths that might need to be adjusted. -Binary: `/usr/bin/bitcoind` -Configuration file: `/etc/bitcoin/bitcoin.conf` -Data directory: `/var/lib/bitcoind` -PID file: `/var/run/bitcoind/bitcoind.pid` (OpenRC and Upstart) or `/var/lib/bitcoind/bitcoind.pid` (systemd) -Lock file: `/var/lock/subsys/bitcoind` (CentOS) +Binary: `/usr/bin/bitcoind` +Configuration file: `/etc/bitcoin/bitcoin.conf` +Data directory: `/var/lib/bitcoind` +PID file: `/var/run/bitcoind/bitcoind.pid` (OpenRC and Upstart) or `/var/lib/bitcoind/bitcoind.pid` (systemd) +Lock file: `/var/lock/subsys/bitcoind` (CentOS) The configuration file, PID directory (if applicable) and data directory should all be owned by the bitcoin user and group. It is advised for security @@ -67,8 +67,8 @@ 3b) macOS -Binary: `/usr/local/bin/bitcoind` -Configuration file: `~/Library/Application Support/Bitcoin/bitcoin.conf` +Binary: `/usr/local/bin/bitcoind` +Configuration file: `~/Library/Application Support/Bitcoin/bitcoin.conf` Data directory: `~/Library/Application Support/Bitcoin` Lock file: `~/Library/Application Support/Bitcoin/.lock` diff --git a/doc/release-process.md b/doc/release-process.md --- a/doc/release-process.md +++ b/doc/release-process.md @@ -15,7 +15,7 @@ - Run `arc lint --everything` and check there is no linter error - Ensure that bitcoind and bitcoin-qt run with no issue on all supported platforms. Manually test bitcoin-qt by sending some transactions and navigating through the menus. - + 3. Update the documents / code which needs to be updated every release - Check that [release-notes.md](doc/release-notes.md) is complete, and fill in any missing items. - Update [bips.md](/doc/bips.md) to account for changes since the last release. @@ -67,6 +67,6 @@ 15. Announce Release: - [Reddit](https://www.reddit.com/r/BitcoinABC/) - Twitter @Bitcoin_ABC - - Public slack channels friendly to Bitcoin ABC announcements + - Public slack channels friendly to Bitcoin ABC announcements (eg. #abc-announce on BTCforks, #hardfork on BTCchat) diff --git a/doc/tor.md b/doc/tor.md --- a/doc/tor.md +++ b/doc/tor.md @@ -93,7 +93,7 @@ Bitcoin Core has been updated to make use of this. This means that if Tor is running (and proper authentication has been configured), -Bitcoin Core automatically creates a hidden service to listen on. This will positively +Bitcoin Core automatically creates a hidden service to listen on. This will positively affect the number of available .onion nodes. This new feature is enabled by default if Bitcoin ABC is listening (`-listen`), and