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