| | 1 | |
| | 2 | Bitcoin integration/staging tree |
| | 3 | |
| | 4 | Development process |
| | 5 | =================== |
| | 6 | |
| | 7 | Developers work in their own trees, then submit pull requests when |
| | 8 | they think their feature or bug fix is ready. |
| | 9 | |
| | 10 | If it is a simple/trivial/non-controversial change, then one of the |
| | 11 | bitcoin development team members simply pulls it. |
| | 12 | |
| | 13 | If it is a more complicated or potentially controversial |
| | 14 | change, then the patch submitter will be asked to start a |
| | 15 | discussion (if they haven't already) on the mailing list: |
| | 16 | http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development |
| | 17 | |
| | 18 | The patch will be accepted if there is broad consensus that it is a |
| | 19 | good thing. Developers should expect to rework and resubmit patches |
| | 20 | if they don't match the project's coding conventions (see coding.txt) |
| | 21 | or are controversial. |
| | 22 | |
| | 23 | The master branch is regularly built and tested, but is not guaranteed |
| | 24 | to be completely stable. Tags are regularly created to indicate new |
| | 25 | official, stable release versions of Bitcoin. If you would like to |
| | 26 | help test the Bitcoin core, please contact [email protected]. |
| | 27 | |
| | 28 | Feature branches are created when there are major new features being |
| | 29 | worked on by several people. |
projects / VerusCoin.git / blame_incremental