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