gecko-dev/docs/bug-mgmt/processes/regressions.rst

65 строки
2.1 KiB
ReStructuredText
Исходник Ответственный История

Этот файл содержит невидимые символы Юникода!

Этот файл содержит невидимые символы Юникода, которые могут быть отображены не так, как показано ниже. Если это намеренно, можете спокойно проигнорировать это предупреждение. Используйте кнопку Экранировать, чтобы показать скрытые символы.

Этот файл содержит неоднозначные символы Юникода, которые могут быть перепутаны с другими в текущей локали. Если это намеренно, можете спокойно проигнорировать это предупреждение. Используйте кнопку Экранировать, чтобы подсветить эти символы.

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
`changeset <https://en.wikipedia.org/wiki/Changeset>`__.
- Bug 101 *fixes* Bug 100 with Change Set A
- Bug 102 *reported which describes previously correct behavior now not
happening*
- Bug 102 *investigated and found to be introduced by Change Set A*
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 bugs description covers previously working behavior which is no
longer working [ed. I need a better phrase for this]
Until the change set which caused the regression has been found through
`mozregression <https://mozilla.github.io/mozregression/>`__ or another
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*