|
|
|
|
|
|
|
|
|
Bitcoin integration/staging tree
|
|
|
|
|
|
|
|
|
|
Development process
|
|
|
|
|
===================
|
|
|
|
|
|
|
|
|
|
Developers work in their own trees, then submit pull requests when
|
|
|
|
|
they think their feature or bug fix is ready.
|
|
|
|
|
|
|
|
|
|
If it is a simple/trivial/non-controversial change, then one of the
|
|
|
|
|
bitcoin development team members simply pulls it.
|
|
|
|
|
|
|
|
|
|
If it is a more complicated or potentially controversial
|
|
|
|
|
change, then the patch submitter will be asked to start a
|
|
|
|
|
discussion (if they haven't already) on the mailing list:
|
|
|
|
|
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development
|
|
|
|
|
|
|
|
|
|
The patch will be accepted if there is broad consensus that it is a
|
|
|
|
|
good thing. Developers should expect to rework and resubmit patches
|
|
|
|
|
if they don't match the project's coding conventions (see coding.txt)
|
|
|
|
|
or are controversial.
|
|
|
|
|
|
|
|
|
|
The master branch is regularly built and tested, but is not guaranteed
|
|
|
|
|
to be completely stable. Tags are regularly created to indicate new
|
|
|
|
|
official, stable release versions of Bitcoin. If you would like to
|
|
|
|
|
help test the Bitcoin core, please contact QA@BitcoinTesting.org.
|
|
|
|
|
|
|
|
|
|
Feature branches are created when there are major new features being
|
|
|
|
|
worked on by several people.
|
|
|
|
|
|
