141 lines
4.6 KiB
ReStructuredText
141 lines
4.6 KiB
ReStructuredText
|
===================
|
|||
|
|
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 reproducible 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.
|