docs/BugLifeCycle.rst

   1 ===================
   2 LLVM Bug Life Cycle
   3 ===================
   4
   5 .. contents::
   6    :local:
   7
   8
   9
  10 Introduction - Achieving consistency in how we deal with bug reports
  11 ====================================================================
  12
  13 We aim to achieve a basic level of consistency in how reported bugs evolve from
  14 being reported, to being worked on, and finally getting closed out. The
  15 consistency helps reporters, developers and others to gain a better
  16 understanding of what a particular bug state actually means and what to expect
  17 might happen next.
  18
  19 At the same time, we aim to not over-specify the life cycle of bugs in the
  20 `the LLVM Bug Tracking System <https://bugs.llvm.org/enter_bug.cgi>`_, as the
  21 overall goal is to make it easier to work with and understand the bug reports.
  22
  23 The main parts of the life cycle documented here are:
  24
  25 #. `Reporting`_
  26 #. `Triaging`_
  27 #. `Actively working on fixing`_
  28 #. `Closing`_
  29
  30 Furthermore, some of the metadata in the bug tracker, such as who to notify on
  31 newly reported bugs or what the breakdown into products & components is we use,
  32 needs to be maintained. See the following for details:
  33
  34 #. `Maintenance of Bug products/component metadata`_
  35 #. `Maintenance of cc-by-default settings`_
  36
  37
  38 .. _Reporting:
  39
  40 Reporting bugs
  41 ==============
  42
  43 See :doc:`HowToSubmitABug` on further details on how to submit good bug reports.
  44
  45 Make sure that you have one or more people on cc on the bug report that you
  46 think will react to it. We aim to automatically add specific people on cc for
  47 most products/components, but may not always succeed in doing so.
  48
  49 If you know the area of LLVM code the root cause of the bug is in, good
  50 candidates to add as cc may be the same people you'd ask for a code review in
  51 that area. See :ref:`finding-potential-reviewers` for more details.
  52
  53
  54 .. _Triaging:
  55
  56 Triaging bugs
  57 =============
  58
  59 Bugs with status NEW indicate that they still need to be triaged.
  60 When triage is complete, the status of the bug is moved to CONFIRMED.
  61
  62 The goal of triaging a bug is to make sure a newly reported bug ends up in a
  63 good, actionable, state. Try to answer the following questions while triaging.
  64
  65 * Is the reported behavior actually wrong?
  66
  67   * E.g. does a miscompile example depend on undefined behavior?
  68
  69 * Can you easily reproduce the bug?
  70
  71   * If not, are there reasonable excuses why it cannot easily be reproduced?
  72
  73 * Is it related to an already reported bug?
  74
  75   * Use the "See also"/"depends on"/"blocks" fields if so.
  76   * Close it as a duplicate if so, pointing to the issue it duplicates.
  77
  78 * Are the following fields filled in correctly?
  79
  80   * Product
  81   * Component
  82   * Title
  83
  84 * CC others not already cc’ed that you happen to know would be good to pull in.
  85 * Add the "beginner" keyword if you think this would be a good bug to be fixed
  86   by someone new to LLVM.
  87
  88 .. _Actively working on fixing:
  89
  90 Actively working on fixing bugs
  91 ===============================
  92
  93 Please remember to assign the bug to yourself if you're actively working on
  94 fixing it and to unassign it when you're no longer actively working on it.  You
  95 unassign a bug by setting the Assignee field to "unassignedbugs@nondot.org".
  96
  97 .. _Closing:
  98
  99 Resolving/Closing bugs
 100 ======================
 101
 102 For simplicity, we only have 1 status for all resolved or closed bugs:
 103 RESOLVED.
 104
 105 Resolving bugs is good! Make sure to properly record the reason for resolving.
 106 Examples of reasons for resolving are:
 107
 108 * Revision NNNNNN fixed the bug.
 109 * The bug cannot be reproduced with revision NNNNNN.
 110 * The circumstances for the bug don't apply anymore.
 111 * There is a sound reason for not fixing it (WONTFIX).
 112 * There is a specific and plausible reason to think that a given bug is
 113   otherwise inapplicable or obsolete.
 114
 115   * One example is an old open bug that doesn't contain enough information to
 116     clearly understand the problem being reported (e.g. not reproducible). It is
 117     fine to resolve such a bug e.g. with resolution WORKSFORME and leaving a
 118     comment to encourage the reporter to reopen the bug with more information
 119     if it's still reproducable on their end.
 120
 121 If a bug is resolved, please fill in the revision number it was fixed in in the
 122 "Fixed by Commit(s)" field.
 123
 124
 125 .. _Maintenance of Bug products/component metadata:
 126
 127 Maintenance of products/components metadata
 128 ===========================================
 129
 130 Please raise a bug against "Bugzilla Admin"/"Products" to request any changes
 131 to be made to the breakdown of products & components modeled in Bugzilla.
 132
 133
 134 .. _Maintenance of cc-by-default settings:
 135
 136 Maintenance of cc-by-default settings
 137 =====================================
 138
 139 Please raise a bug against "Bugzilla Admin"/"Products" to request any changes
 140 to be made to the cc-by-default settings for specific components.