Index: llvm/docs/BugLifeCycle.rst =================================================================== --- llvm/docs/BugLifeCycle.rst +++ llvm/docs/BugLifeCycle.rst @@ -17,8 +17,9 @@ 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 `_, as the -overall goal is to make it easier to work with and understand the bug reports. +`the LLVM Bug Tracking System `_, +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: @@ -27,12 +28,10 @@ #. `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: +Furthermore, some of the metadata in the bug tracker, such as what labels we +use needs to be maintained. See the following for details: -#. `Maintenance of Bug products/component metadata`_ -#. `Maintenance of cc-by-default settings`_ +#. `Maintenance of metadata`_ .. _Reporting: @@ -42,22 +41,19 @@ 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. - +You can apply labels to the bug to provide extra information to make the bug +easier to discover, such as a label for the part of the project the bug +pertains to. Please also add a label specifying whether the issue is a ``bug`` +or an ``enhancement``. .. _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. +Bugs with a ``new issue`` label indicate that the issue stills need to be +triaged. When triage is complete, the ``new issue`` label should be replaced by +a ``confirmed`` label, unless the issue is being closed. 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. @@ -72,17 +68,16 @@ * 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. + * Close it as a duplicate by adding the label ``duplicate`` if so, with a + comment pointing to the issue it duplicates. * Are the following fields filled in correctly? - * Product - * Component * Title + * Description + * Labels -* 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 +* Add the ``beginner`` label if you think this would be a good bug to be fixed by someone new to LLVM. .. _Actively working on fixing: @@ -92,49 +87,39 @@ 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". +unassign a bug by removing the person from the the ``Assignees`` field. .. _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 sound reason for not fixing it (add the ``wontfix`` label). * 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 + fine to resolve such a bug e.g. with the ``worksforme`` label 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. +If a bug is resolved, please add the revision number it was fixed in as a +comment when closing the issue. -.. _Maintenance of cc-by-default settings: +.. _Maintenance of metadata: -Maintenance of cc-by-default settings -===================================== +Maintenance of metadata +======================= -Please raise a bug against "Bugzilla Admin"/"Products" to request any changes -to be made to the cc-by-default settings for specific components. +Please add the ``infrastructure`` label to request any changes to be made to +the labels used by the issue tracker instead of creating your own label. This +increases consistency when triaging and helps reduce the proliferation of +labels.