philippe | a501f12 | 2013-12-01 12:42:30 +0000 | [diff] [blame] | 1 | This file documents various "processes" that are used by Valgrind |
| 2 | developers for development and release activities. |
| 3 | This file contains one section for each process. |
| 4 | A summary of each process is given here. Each process is described |
| 5 | more in details afterwards. |
| 6 | |
| 7 | |
| 8 | * Update of the NEWS file: NEWS describes fixed bugs and new features. |
| 9 | It is updated and committed together with the code fixing the bug/implementing |
| 10 | the feature. |
| 11 | |
| 12 | * Major release production: |
| 13 | See docs/internals/release-HOWTO.txt (currently a bit out of date) |
| 14 | |
| 15 | * Minor/correction release production: TBD |
| 16 | |
| 17 | |
| 18 | Processes detailed descriptions: |
| 19 | |
| 20 | Update of the NEWS file. |
| 21 | ======================== |
| 22 | The NEWS file gives for each release: |
| 23 | - the list of fixed bugs, |
| 24 | - a short description of each functional change, |
| 25 | - a short description of each technical change impacting the users. |
| 26 | |
| 27 | The update of the NEWS file should be committed together with the |
| 28 | code change (or as part of the last committed change) that fixes the |
| 29 | bug or implements the new feature/technical change. |
| 30 | The documentation (e.g. user manual) should also be committed as part of |
| 31 | the code change. |
| 32 | |
| 33 | Fixing a bug |
| 34 | ------------ |
| 35 | When fixing a bug, add a line in the 'FIXED BUGS' section of |
| 36 | the NEWS file. Keep the list of bugs sorted by bugzilla entry number. |
| 37 | |
| 38 | Once you have commit the change, update the bug status in bugzilla, |
| 39 | adding in the comment the revision number of the commit fixing the bug. |
| 40 | |
| 41 | If a bug is not entered in bugzilla (not encouraged), use "n-i-bz" |
| 42 | and add the bug line at the end of the bug list. |
| 43 | |
| 44 | The file docs/internals/X_Y_BUGSTATUS.txt (where X_Y is the last |
| 45 | major release e.g. 3_9) contains information/statuses for some bugs. |
| 46 | If a bug is fixed, remove the (possible) bug info from this file. |
| 47 | |
| 48 | Implementing a change |
| 49 | --------------------- |
| 50 | When implementing a functional or 'user impacting' technical change, |
| 51 | add a short description of the change in the relevant sub-section |
| 52 | (e.g. TOOL CHANGES, PLATFORM CHANGES, ...). |
| 53 | |
| 54 | |
| 55 | Some special cases: |
| 56 | ------------------- |
| 57 | Some bugs or changes only touch the VEX SVN repository, so it is not |
| 58 | possible to commit the NEWS change together with the code changes. |
| 59 | In such a case, first commit the VEX change. Then just after, commit |
| 60 | the NEWS change. In the bugzilla status, reference (at least) the Valgrind |
| 61 | revision number. |
| 62 | |
| 63 | Some changes or bug fixes are very big and might be implemented over |
| 64 | a significant period. In such a case, update the NEWS as part of the |
| 65 | final commit. |
| 66 | If relevant, you might already update the NEWS file as part of |
| 67 | earlier commits, using the word 'PARTIAL' to indicate that the change or |
| 68 | bug fix is not complete yet. |
| 69 | |
| 70 | Some bugs are reported more than once in bugzilla. |
| 71 | Also document in NEWS that such duplicated bugs have been fixed, using a line |
| 72 | such as: |
| 73 | 308333 == 307106 |
| 74 | to indicate that the bug 308333 is a duplicate of 307106, and was thus |
| 75 | fixed in the commit that fixed 307106. |
| 76 | Change also the status of the duplicated bug in bugzilla, |
| 77 | indicating in the comment the commit revision that fixed the 'master bug'. |
| 78 | |
| 79 | |
| 80 | |
| 81 | Minor/correction release: |
| 82 | ========================= |
| 83 | Describe here how to do changes and bug fixed in a minor (correction) release |
| 84 | and how/when to merge the branch to the trunk. |
| 85 | |
| 86 | Proposal to be discussed: |
| 87 | When a bug is fixed on the branch, the NEWS file is updated on the branch |
| 88 | (i.e. a 3.9.1 section is created if needed). |
| 89 | |
| 90 | When often to merge the branch to trunk ? |
| 91 | after each fix ? |
| 92 | just after the correction release is produced ? |
| 93 | |
| 94 | How is the branch merged to the trunk ? |