README_DEVELOPERS_processes

   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 * Various guidelines/recommended usage for valgrind SVN
  16   See docs/internals/svn-HOWTO.txt
  17
  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 ?