Update development process README to reflect current reality
This commit is contained in:
parent
429915bd0d
commit
b67b9e7077
52
README.md
52
README.md
@ -22,21 +22,45 @@ or are controversial.
|
|||||||
|
|
||||||
The master branch is regularly built and tested, but is not guaranteed
|
The master branch is regularly built and tested, but is not guaranteed
|
||||||
to be completely stable. Tags are regularly created to indicate new
|
to be completely stable. Tags are regularly created to indicate new
|
||||||
official, stable release versions of Bitcoin. If you would like to
|
official, stable release versions of Bitcoin.
|
||||||
help test the Bitcoin core, please contact QA@BitcoinTesting.org.
|
|
||||||
|
|
||||||
Feature branches are created when there are major new features being
|
Testing
|
||||||
worked on by several people.
|
=======
|
||||||
|
|
||||||
From time to time a pull request will become outdated. If this occurs, and
|
Testing and code review is the bottleneck for development; we get more
|
||||||
the pull is no longer automatically mergeable; a comment on the pull will
|
pull requests than we can review and test. Please be patient and help
|
||||||
be used to issue a warning of closure. The pull will be closed 15 days
|
out, and remember this is a security-critical project where any
|
||||||
after the warning if action is not taken by the author. Pull requests closed
|
mistake might cost people lots of money.
|
||||||
in this manner will have their corresponding issue labeled 'stagnant'.
|
|
||||||
|
|
||||||
Issues with no commits will be given a similar warning, and closed after
|
Automated Testing
|
||||||
15 days from their last activity. Issues closed in this manner will be
|
-----------------
|
||||||
labeled 'stale'.
|
|
||||||
|
|
||||||
Requests to reopen closed pull requests and/or issues can be submitted to
|
Developers are strongly encouraged to write unit tests for new code,
|
||||||
QA@BitcoinTesting.org.
|
and to submit new unit tests for old code.
|
||||||
|
|
||||||
|
Unit tests for the core code are in src/test/
|
||||||
|
To compile and run them:
|
||||||
|
cd src; make -f makefile.linux test
|
||||||
|
|
||||||
|
Unit tests for the GUI code are in src/qt/test/
|
||||||
|
To compile and run them:
|
||||||
|
qmake BITCOIN_QT_TEST=1 -o Makefile.test bitcoin-qt.pro
|
||||||
|
make -f Makefile.test
|
||||||
|
./Bitcoin-Qt
|
||||||
|
|
||||||
|
Every pull request is built for both Windows and
|
||||||
|
Linux on a dedicated server, and unit and sanity
|
||||||
|
tests are automatically run. The binaries
|
||||||
|
produced may be used for manual QA testing
|
||||||
|
(a link to them will appear in a comment on the pull request
|
||||||
|
from 'BitcoinPullTester').
|
||||||
|
See https://github.com/TheBlueMatt/test-scripts for the
|
||||||
|
build/test scripts.
|
||||||
|
|
||||||
|
Manual Quality Assurance (QA) Testing
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
Large changes should have a test plan, and should be tested
|
||||||
|
by somebody other than the developer who wrote the code.
|
||||||
|
|
||||||
|
See https://github.com/bitcoin/QA/ for how to create a test plan.
|
||||||
|
Loading…
Reference in New Issue
Block a user