mirrors/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2024-11-20 02:25:40 +01:00
Code Issues Projects Releases Wiki Activity

Merge #19072: doc: Expand section on Getting Started

Browse Source 
facef3d413 doc: Explain that anyone can work on good first issues, move text to CONTRIBUTING.md (MarcoFalke)
fae2fb2a19 doc: Expand section on Getting Started (MarcoFalke)
100000d1b2 doc: Add headings to CONTRIBUTING.md (MarcoFalke)
fab893e0ca doc: Fix unrelated typos reported by codespell (MarcoFalke)

Pull request description:

  Some random doc changes:

  * Add sections to docs, so that they can be linked to
  * Explain that anyone (even maintainers) are allowed to work on good first issues
  * Expand section on Getting Started slightly

ACKs for top commit:
  hebasto:
    ACK facef3d413
  fanquake:
    ACK facef3d413

Tree-SHA512: 8998e273a76dbf4ca77e79374c14efe4dfcc5c6df6b7d801e1e1e436711dbe6f76b436f9cbc6cacb45a56827babdd6396f3bd376a9426ee7be3bb9b8a3b8e383
This commit is contained in:
fanquake 2020-06-01 15:14:29 +08:00
commit a8327fd71f
No known key found for this signature in database
GPG Key ID: 2EEB9F5CC09526C1
7 changed files with 59 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
.github/ISSUE_TEMPLATE/good_first_issue.md vendored
View File

@ -7,6 +7,9 @@ assignees: ''
---
<!-- A good first issue is an uncontroversial issue, that has a relatively unique and obvious solution -->
<!-- Motivate the issue and explain the solution briefly -->
#### Useful skills:
@ -14,8 +17,4 @@ assignees: ''
#### Want to work on this issue?
The purpose of the `good first issue` label is to highlight which issues are suitable for a new contributor without a deep understanding of the codebase.
You do not need to request permission to start working on this. You are encouraged to comment on the issue if you are planning to work on it. This will help other contributors monitor which issues are actively being addressed and is also an effective way to request assistance if and when you need it.
For guidance on contributing, please read [CONTRIBUTING.md](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md) before opening your pull request.

58
CONTRIBUTING.md
View File

@ -14,15 +14,49 @@ purposes. As such there are repository "maintainers" who are responsible for
merging pull requests as well as a "lead maintainer" who is responsible for the
release cycle, overall merging, moderation and appointment of maintainers.
Getting Started
---------------
New contributors are very welcome and needed.
Reviewing and testing is the most effective way you can contribute as a new
contributor, and it also will teach you much more about the code and process
than opening PRs. Please refer to the section [peer review](#peer-review) later
in this document.
Before you start contributing, familiarize yourself with the Bitcoin Core build
system and tests. Refer to the documentation in the repository on how to build
Bitcoin Core and how to run the unit and functional tests.
There are many open issues of varying difficulty waiting to be fixed.
If you're looking for somewhere to start contributing, check out the
[good first issue](https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
list or participate in a weekly [Bitcoin Core PR Review Club](https://bitcoincore.reviews/) meeting.
list or changes that are
[up for grabs](https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=label%3A%22Up+for+grabs%22).
Some of them might no longer be applicable. So if you are interested, but
unsure, you might want to leave a comment on the issue first.
You may also participate in the weekly
[Bitcoin Core PR Review Club](https://bitcoincore.reviews/) meeting.
### Good First Issue Label
The purpose of the `good first issue` label is to highlight which issues are
suitable for a new contributor without a deep understanding of the codebase.
However, good first issues can be solved by anyone. If they remain unsolved
for a longer time, a frequent contributor might address them.
You do not need to request permission to start working on an issue. However,
you are encouraged to leave a comment if you are planning to work on it. This
will help other contributors monitor which issues are actively being addressed
and is also an effective way to request assistance if and when you need it.
Communication Channels
----------------------
Most communication about Bitcoin Core development happens on IRC, in the
#bitcoin-core-dev channel on Freenode. The easiest way to participate on IRC is
`#bitcoin-core-dev` channel on Freenode. The easiest way to participate on IRC is
with the web client, [webchat.freenode.net](https://webchat.freenode.net/). Chat
history logs can be found
on [http://www.erisian.com.au/bitcoin-core-dev/](http://www.erisian.com.au/bitcoin-core-dev/)
@ -33,7 +67,7 @@ requests.
The developer
[mailing list](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)
should be used to discuss complicated or controversial changes before working on
should be used to discuss complicated or controversial consensus or P2P protocol changes before working on
a patch set.
@ -53,6 +87,8 @@ To contribute a patch, the workflow is as follows:
The project coding conventions in the [developer notes](doc/developer-notes.md)
must be followed.
### Committing Patches
In general, [commits should be atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention)
and diffs should be easy to read. For this reason, do not mix any formatting
fixes or code moves with actual code changes.
@ -76,6 +112,8 @@ about Git.
- Push changes to your fork
- Create pull request
### Creating the Pull Request
The title of the pull request should be prefixed by the component or area that
the pull request affects. Valid areas as:
@ -100,18 +138,24 @@ Examples:
qt: Add feed bump button
log: Fix typo in log message
The body of the pull request should contain enough description about what the
patch does together with any justification/reasoning. You should include
references to any discussions (for example other tickets or mailing list
discussions).
### Translation changes
Note that translations should not be submitted as pull requests. Please see
[Translation Process](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md)
for more information on helping with translations.
### Work in Progress Changes and Requests for Comments
If a pull request is not to be considered for merging (yet), please
prefix the title with [WIP] or use [Tasks Lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#task-lists)
in the body of the pull request to indicate tasks are pending.
The body of the pull request should contain enough description about what the
patch does together with any justification/reasoning. You should include
references to any discussions (for example other tickets or mailing list
discussions).
### Address Feedback
At this stage, one should expect comments and review from other contributors. You
can add more commits to your pull request by committing them locally and pushing

2
configure.ac
View File

@ -811,7 +811,7 @@ if test x$use_hardening != xno; then
fi
dnl These flags are specific to ld64, and may cause issues with other linkers.
dnl For example: GNU ld will intepret -dead_strip as -de and then try and use
dnl For example: GNU ld will interpret -dead_strip as -de and then try and use
dnl "ad_strip" as the symbol for the entry point.
if test x$TARGET_OS = xdarwin; then
AX_CHECK_LINK_FLAG([[-Wl,-dead_strip]], [LDFLAGS="$LDFLAGS -Wl,-dead_strip"],, [[$LDFLAG_WERROR]])

2
src/psbt.h
View File

@ -41,7 +41,7 @@ static constexpr uint8_t PSBT_OUT_BIP32_DERIVATION = 0x02;
static constexpr uint8_t PSBT_SEPARATOR = 0x00;
// BIP 174 does not specify a maximum file size, but we set a limit anyway
// to prevent reading a stream indefinately and running out of memory.
// to prevent reading a stream indefinitely and running out of memory.
const std::streamsize MAX_FILE_SIZE_PSBT = 100000000; // 100 MiB
/** A structure for PSBTs which contain per-input information */

2
src/qt/walletview.cpp
View File

@ -258,7 +258,7 @@ void WalletView::gotoLoadPSBT()
TransactionError result = BroadcastTransaction(*clientModel->node().context(), tx, err_string, DEFAULT_MAX_RAW_TX_FEE_RATE.GetFeePerK(), /* relay */ true, /* wait_callback */ false);
if (result == TransactionError::OK) {
Q_EMIT message(tr("Success"), tr("Broadcasted transaction sucessfully."), CClientUIInterface::MSG_INFORMATION | CClientUIInterface::MODAL);
Q_EMIT message(tr("Success"), tr("Broadcasted transaction successfully."), CClientUIInterface::MSG_INFORMATION | CClientUIInterface::MODAL);
} else {
Q_EMIT message(tr("Error"), QString::fromStdString(err_string), CClientUIInterface::MSG_ERROR);
}

2
src/rpc/mining.cpp
View File

@ -179,7 +179,7 @@ static bool getScriptFromDescriptor(const std::string& descriptor, CScript& scri
throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, strprintf("Cannot derive script without private keys"));
}
// Combo desriptors can have 2 or 4 scripts, so we can't just check scripts.size() == 1
// Combo descriptors can have 2 or 4 scripts, so we can't just check scripts.size() == 1
CHECK_NONFATAL(scripts.size() > 0 && scripts.size() <= 4);
if (scripts.size() == 1) {

2
test/functional/rpc_getaddressinfo_label_deprecation.py
View File

@ -4,7 +4,7 @@
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
"""
Test deprecation of the RPC getaddressinfo `label` field. It has been
superceded by the `labels` field.
superseded by the `labels` field.
"""
from test_framework.test_framework import BitcoinTestFramework