Source code
Revision control
Copy as Markdown
Other Tools
How to Mark Regressions
=======================
Regressions
-----------
For regression bugs in Mozilla-Central, our policy is to tag the bug as
a regression, identify the commits which caused the regression, then
mark the bugs associated with those commits as causing the regression.
What is a regression?
---------------------
A regression is a bug (in our scheme a ``defect``) introduced by a
happening*
Marking a Regression Bug
------------------------
These things are true about regressions:
- **Bug Type** is ``defect``
- **Keywords** include ``regression``
- **Status_FirefoxNN** is ``affected`` for each version (in current
nightly, beta, and release) of Firefox in which the bug was found
- The bug’s description covers previously working behavior which is no
longer working
Until the change set which caused the regression has been found through
bisection tool, the bug should also have the ``regressionwindow-wanted``
keyword.
Once the change set which caused the regression has been identified,
remove the ``regressionwindow-wanted`` keyword and set the **Regressed
By** field to the id of the bug associated with the change set.
Setting the **Regressed By** field will update the **Regresses** field
in the other bug.
Set a needinfo for the author of the regressing patch asking them to fix
or revert the regression.
Previous Method
---------------
Previously we over-loaded the **Blocks** and **Blocked By** fields to
track the regression, setting **Blocks** to the id of the bug associated
with the change set causing the regression, and using the
``regression``, ``regressionwindow-wanted`` keywords and the status
flags as described above.
This made it difficult to understand what was a dependency and what was
a regression when looking at dependency trees in Bugzilla.
FAQs
----
*To be written*