User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
cppdev:submitpatches [2010-11-04 16:55] Carsten Added maintenance info about applied patches |
cppdev:submitpatches [2012-04-10 22:32] Carsten [Mechanics of Patch Submission] clarified the text |
||
|---|---|---|---|
| Line 50: | Line 50: | ||
| === Make atomic patches === | === Make atomic patches === | ||
| - | Do not split a single code change into multiple patches. A patch should be self-contained -- //one patch for one thing//. | + | A patch should be self-contained -- //one patch for one thing//. |
| - | A patch that adds bitmaps to menu items and fixes a bug in the network code is a bad patch. It should be splitted into two patches. On the other hand, two patches, one of them being "implementation of new member-functions", the other "changes in class description to accommodate new members" are two bad patches. They are related to one, logically indivisible thing, so they should be part of one patch. | + | Do not combine multiple new features in a single patch: |
| + | A patch that adds bitmaps to menu items and fixes a bug in the network code is a bad patch. It should be splitted into two patches. | ||
| - | Another example: if you adapted the build system to work on a new, previously unsupported platform, we would gladly accept your patch. Just send us single patch, not 10 patches, one for each modified file. | + | On the other hand, do not split a single code change into multiple patches: |
| + | Two patches, one of them being "implementation of new member-functions", the other "changes in class documentation to accommodate new members" are two bad patches. They are related to one, logically indivisible thing, so they should be in one common patch. | ||
cppdev/submitpatches.txt · Last modified: 2017-02-05 13:37 by Carsten