$ sphinx.addnodesdocument)}( rawsource children](translations
LanguagesNode)}(hhh](h pending_xref)}(hhh]docutils.nodesTextChinese (Simplified)}parenthsba
attributes}(ids]classes]names]dupnames]backrefs] refdomainstdreftypedoc reftarget0/translations/zh_CN/process/handling-regressionsmodnameN classnameNrefexplicitutagnamehhhubh)}(hhh]hChinese (Traditional)}hh2sbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/zh_TW/process/handling-regressionsmodnameN classnameNrefexplicituh1hhhubh)}(hhh]hItalian}hhFsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/it_IT/process/handling-regressionsmodnameN classnameNrefexplicituh1hhhubh)}(hhh]hJapanese}hhZsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/ja_JP/process/handling-regressionsmodnameN classnameNrefexplicituh1hhhubh)}(hhh]hKorean}hhnsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/ko_KR/process/handling-regressionsmodnameN classnameNrefexplicituh1hhhubh)}(hhh]hPortuguese (Brazilian)}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/pt_BR/process/handling-regressionsmodnameN classnameNrefexplicituh1hhhubh)}(hhh]hSpanish}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/sp_SP/process/handling-regressionsmodnameN classnameNrefexplicituh1hhhubeh}(h]h ]h"]h$]h&]current_languageEnglishuh1h
hh _documenthsourceNlineNubhcomment)}(h0SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)h]h0SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)}hhsbah}(h]h ]h"]h$]h&] xml:spacepreserveuh1hhhhhhJ/var/lib/git/docbuild/linux/Documentation/process/handling-regressions.rsthKubh)}(hFSee the bottom of this file for additional redistribution information.h]hFSee the bottom of this file for additional redistribution information.}hhsbah}(h]h ]h"]h$]h&]hhuh1hhhhhhhhKubhsection)}(hhh](htitle)}(hHandling regressionsh]hHandling regressions}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhhhhhKubh paragraph)}(hXV *We don't cause regressions* -- this document describes what this "first rule of
Linux kernel development" means in practice for developers. It complements
Documentation/admin-guide/reporting-regressions.rst, which covers the topic from a
user's point of view; if you never read that text, go and at least skim over it
before continuing here.h](hemphasis)}(h*We don't cause regressions*h]hWe don’t cause regressions}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhubhX@ -- this document describes what this “first rule of
Linux kernel development” means in practice for developers. It complements
Documentation/admin-guide/reporting-regressions.rst, which covers the topic from a
user’s point of view; if you never read that text, go and at least skim over it
before continuing here.}(hhhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hhh](h)}(h$The important bits (aka "The TL;DR")h]h(The important bits (aka “The TL;DR”)}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhKubhenumerated_list)}(hhh](h list_item)}(hX Ensure subscribers of the `regression mailing list `_
(regressions@lists.linux.dev) quickly become aware of any new regression
report:
* When receiving a mailed report that did not CC the list, bring it into the
loop by immediately sending at least a brief "Reply-all" with the list
CCed.
* Forward or bounce any reports submitted in bug trackers to the list.
h](h)}(hEnsure subscribers of the `regression mailing list `_
(regressions@lists.linux.dev) quickly become aware of any new regression
report:h](hEnsure subscribers of the }(hj' hhhNhNubh reference)}(hA`regression mailing list `_h]hregression mailing list}(hj1 hhhNhNubah}(h]h ]h"]h$]h&]nameregression mailing listrefuri$https://lore.kernel.org/regressions/uh1j/ hj' ubhtarget)}(h' h]h}(h]regression-mailing-listah ]h"]regression mailing listah$]h&]refurijB uh1jC
referencedKhj' ubh
(}(hj' hhhNhNubj0 )}(hregressions@lists.linux.devh]hregressions@lists.linux.dev}(hjW hhhNhNubah}(h]h ]h"]h$]h&]refuri"mailto:regressions@lists.linux.devuh1j/ hj' ubh4) quickly become aware of any new regression
report:}(hj' hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhj# ubhblock_quote)}(h* When receiving a mailed report that did not CC the list, bring it into the
loop by immediately sending at least a brief "Reply-all" with the list
CCed.
* Forward or bounce any reports submitted in bug trackers to the list.
h]hbullet_list)}(hhh](j" )}(hWhen receiving a mailed report that did not CC the list, bring it into the
loop by immediately sending at least a brief "Reply-all" with the list
CCed.
h]h)}(hWhen receiving a mailed report that did not CC the list, bring it into the
loop by immediately sending at least a brief "Reply-all" with the list
CCed.h]hWhen receiving a mailed report that did not CC the list, bring it into the
loop by immediately sending at least a brief “Reply-all” with the list
CCed.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj| ubah}(h]h ]h"]h$]h&]uh1j! hjy ubj" )}(hEForward or bounce any reports submitted in bug trackers to the list.
h]h)}(hDForward or bounce any reports submitted in bug trackers to the list.h]hDForward or bounce any reports submitted in bug trackers to the list.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hjy ubeh}(h]h ]h"]h$]h&]bullet*uh1jw hhhKhjs ubah}(h]h ]h"]h$]h&]uh1jq hhhKhj# ubeh}(h]h ]h"]h$]h&]uh1j! hj hhhhhNubj" )}(hX Make the Linux kernel regression tracking bot "regzbot" track the issue (this
is optional, but recommended):
* For mailed reports, check if the reporter included a line like ``#regzbot
introduced: v5.13..v5.14-rc1``. If not, send a reply (with the regressions
list in CC) containing a paragraph like the following, which tells regzbot
when the issue started to happen::
#regzbot ^introduced: 1f2e3d4c5b6a
* When forwarding reports from a bug tracker to the regressions list (see
above), include a paragraph like the following::
#regzbot introduced: v5.13..v5.14-rc1
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
h](h)}(hlMake the Linux kernel regression tracking bot "regzbot" track the issue (this
is optional, but recommended):h]hpMake the Linux kernel regression tracking bot “regzbot” track the issue (this
is optional, but recommended):}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubjr )}(hXc * For mailed reports, check if the reporter included a line like ``#regzbot
introduced: v5.13..v5.14-rc1``. If not, send a reply (with the regressions
list in CC) containing a paragraph like the following, which tells regzbot
when the issue started to happen::
#regzbot ^introduced: 1f2e3d4c5b6a
* When forwarding reports from a bug tracker to the regressions list (see
above), include a paragraph like the following::
#regzbot introduced: v5.13..v5.14-rc1
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
h]jx )}(hhh](j" )}(hX( For mailed reports, check if the reporter included a line like ``#regzbot
introduced: v5.13..v5.14-rc1``. If not, send a reply (with the regressions
list in CC) containing a paragraph like the following, which tells regzbot
when the issue started to happen::
#regzbot ^introduced: 1f2e3d4c5b6a
h](h)}(hX For mailed reports, check if the reporter included a line like ``#regzbot
introduced: v5.13..v5.14-rc1``. If not, send a reply (with the regressions
list in CC) containing a paragraph like the following, which tells regzbot
when the issue started to happen::h](h?For mailed reports, check if the reporter included a line like }(hj hhhNhNubhliteral)}(h)``#regzbot
introduced: v5.13..v5.14-rc1``h]h%#regzbot
introduced: v5.13..v5.14-rc1}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubh. If not, send a reply (with the regressions
list in CC) containing a paragraph like the following, which tells regzbot
when the issue started to happen:}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhj ubh
literal_block)}(h"#regzbot ^introduced: 1f2e3d4c5b6ah]h"#regzbot ^introduced: 1f2e3d4c5b6a}hj sbah}(h]h ]h"]h$]h&]hhuh1j hhhK"hj ubeh}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hX& When forwarding reports from a bug tracker to the regressions list (see
above), include a paragraph like the following::
#regzbot introduced: v5.13..v5.14-rc1
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
h](h)}(hxWhen forwarding reports from a bug tracker to the regressions list (see
above), include a paragraph like the following::h]hwWhen forwarding reports from a bug tracker to the regressions list (see
above), include a paragraph like the following:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK$hj ubj )}(h#regzbot introduced: v5.13..v5.14-rc1
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789h]h#regzbot introduced: v5.13..v5.14-rc1
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789}hj' sbah}(h]h ]h"]h$]h&]hhuh1j hhhK'hj ubeh}(h]h ]h"]h$]h&]uh1j! hj ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKhj ubah}(h]h ]h"]h$]h&]uh1jq hhhKhj ubeh}(h]h ]h"]h$]h&]uh1j! hj hhhhhNubj" )}(hX When submitting fixes for regressions, add "Closes:" tags to the patch
description pointing to all places where the issue was reported, as
mandated by Documentation/process/submitting-patches.rst and
:ref:`Documentation/process/5.Posting.rst `. If you are
only fixing part of the issue that caused the regression, you may use
"Link:" tags instead. regzbot currently makes no distinction between the
two.
h]h)}(hX When submitting fixes for regressions, add "Closes:" tags to the patch
description pointing to all places where the issue was reported, as
mandated by Documentation/process/submitting-patches.rst and
:ref:`Documentation/process/5.Posting.rst `. If you are
only fixing part of the issue that caused the regression, you may use
"Link:" tags instead. regzbot currently makes no distinction between the
two.h](hWhen submitting fixes for regressions, add “Closes:” tags to the patch
description pointing to all places where the issue was reported, as
mandated by Documentation/process/submitting-patches.rst and
}(hjQ hhhNhNubh)}(h@:ref:`Documentation/process/5.Posting.rst `h]hinline)}(hj[ h]h#Documentation/process/5.Posting.rst}(hj_ hhhNhNubah}(h]h ](xrefstdstd-refeh"]h$]h&]uh1j] hjY ubah}(h]h ]h"]h$]h&]refdocprocess/handling-regressions refdomainjj reftyperefrefexplicitrefwarn reftargetdevelopment_postinguh1hhhhK+hjQ ubh. If you are
only fixing part of the issue that caused the regression, you may use
“Link:” tags instead. regzbot currently makes no distinction between the
two.}(hjQ hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhK+hjM ubah}(h]h ]h"]h$]h&]uh1j! hj hhhhhNubj" )}(hTry to fix regressions quickly once the culprit has been identified; fixes
for most regressions should be merged within two weeks, but some need to be
resolved within two or three days.
h]h)}(hTry to fix regressions quickly once the culprit has been identified; fixes
for most regressions should be merged within two weeks, but some need to be
resolved within two or three days.h]hTry to fix regressions quickly once the culprit has been identified; fixes
for most regressions should be merged within two weeks, but some need to be
resolved within two or three days.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK3hj ubah}(h]h ]h"]h$]h&]uh1j! hj hhhhhNubeh}(h]h ]h"]h$]h&]enumtypearabicprefixhsuffix.uh1j hj hhhhhKubeh}(h] the-important-bits-aka-the-tl-drah ]h"]$the important bits (aka "the tl;dr")ah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(hCAll the details on Linux kernel regressions relevant for developersh]hCAll the details on Linux kernel regressions relevant for developers}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhK9ubh)}(hhh](h)}(h#The important basics in more detailh]h#The important basics in more detail}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhK=ubh)}(hhh](h)}(h,What to do when receiving regression reportsh]h,What to do when receiving regression reports}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhKAubh)}(hEnsure the Linux kernel's regression tracker and others subscribers of the
`regression mailing list `_
(regressions@lists.linux.dev) become aware of any newly reported regression:h](hMEnsure the Linux kernel’s regression tracker and others subscribers of the
}(hj hhhNhNubj0 )}(hA`regression mailing list `_h]hregression mailing list}(hj hhhNhNubah}(h]h ]h"]h$]h&]nameregression mailing listjA $https://lore.kernel.org/regressions/uh1j/ hj ubjD )}(h' h]h}(h]id1ah ]h"]h$]regression mailing listah&]refurij uh1jC jR Khj ubh
(}(hj hhhNhNubj0 )}(hregressions@lists.linux.devh]hregressions@lists.linux.dev}(hj hhhNhNubah}(h]h ]h"]h$]h&]refuri"mailto:regressions@lists.linux.devuh1j/ hj ubh0) become aware of any newly reported regression:}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKChj hhubjr )}(hX * When you receive a report by mail that did not CC the list, immediately bring
it into the loop by sending at least a brief "Reply-all" with the list CCed;
try to ensure it gets CCed again in case you reply to a reply that omitted
the list.
* If a report submitted in a bug tracker hits your Inbox, forward or bounce it
to the list. Consider checking the list archives beforehand, if the reporter
already forwarded the report as instructed by
Documentation/admin-guide/reporting-issues.rst.
h]jx )}(hhh](j" )}(hWhen you receive a report by mail that did not CC the list, immediately bring
it into the loop by sending at least a brief "Reply-all" with the list CCed;
try to ensure it gets CCed again in case you reply to a reply that omitted
the list.
h]h)}(hWhen you receive a report by mail that did not CC the list, immediately bring
it into the loop by sending at least a brief "Reply-all" with the list CCed;
try to ensure it gets CCed again in case you reply to a reply that omitted
the list.h]hWhen you receive a report by mail that did not CC the list, immediately bring
it into the loop by sending at least a brief “Reply-all” with the list CCed;
try to ensure it gets CCed again in case you reply to a reply that omitted
the list.}(hj; hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKGhj7 ubah}(h]h ]h"]h$]h&]uh1j! hj4 ubj" )}(hIf a report submitted in a bug tracker hits your Inbox, forward or bounce it
to the list. Consider checking the list archives beforehand, if the reporter
already forwarded the report as instructed by
Documentation/admin-guide/reporting-issues.rst.
h]h)}(hIf a report submitted in a bug tracker hits your Inbox, forward or bounce it
to the list. Consider checking the list archives beforehand, if the reporter
already forwarded the report as instructed by
Documentation/admin-guide/reporting-issues.rst.h]hIf a report submitted in a bug tracker hits your Inbox, forward or bounce it
to the list. Consider checking the list archives beforehand, if the reporter
already forwarded the report as instructed by
Documentation/admin-guide/reporting-issues.rst.}(hjS hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKLhjO ubah}(h]h ]h"]h$]h&]uh1j! hj4 ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKGhj0 ubah}(h]h ]h"]h$]h&]uh1jq hhhKGhj hhubh)}(h{When doing either, consider making the Linux kernel regression tracking bot
"regzbot" immediately start tracking the issue:h]hWhen doing either, consider making the Linux kernel regression tracking bot
“regzbot” immediately start tracking the issue:}(hjs hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKQhj hhubjr )}(hX * For mailed reports, check if the reporter included a "regzbot command" like
``#regzbot introduced: 1f2e3d4c5b6a``. If not, send a reply (with the
regressions list in CC) with a paragraph like the following:::
#regzbot ^introduced: v5.13..v5.14-rc1
This tells regzbot the version range in which the issue started to happen;
you can specify a range using commit-ids as well or state a single commit-id
in case the reporter bisected the culprit.
Note the caret (^) before the "introduced": it tells regzbot to treat the
parent mail (the one you reply to) as the initial report for the regression
you want to see tracked; that's important, as regzbot will later look out
for patches with "Closes:" tags pointing to the report in the archives on
lore.kernel.org.
* When forwarding a regression reported to a bug tracker, include a paragraph
with these regzbot commands::
#regzbot introduced: 1f2e3d4c5b6a
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
Regzbot will then automatically associate patches with the report that
contain "Closes:" tags pointing to your mail or the mentioned ticket.
h]jx )}(hhh](j" )}(hX For mailed reports, check if the reporter included a "regzbot command" like
``#regzbot introduced: 1f2e3d4c5b6a``. If not, send a reply (with the
regressions list in CC) with a paragraph like the following:::
#regzbot ^introduced: v5.13..v5.14-rc1
This tells regzbot the version range in which the issue started to happen;
you can specify a range using commit-ids as well or state a single commit-id
in case the reporter bisected the culprit.
Note the caret (^) before the "introduced": it tells regzbot to treat the
parent mail (the one you reply to) as the initial report for the regression
you want to see tracked; that's important, as regzbot will later look out
for patches with "Closes:" tags pointing to the report in the archives on
lore.kernel.org.
h](h)}(hFor mailed reports, check if the reporter included a "regzbot command" like
``#regzbot introduced: 1f2e3d4c5b6a``. If not, send a reply (with the
regressions list in CC) with a paragraph like the following:::h](hPFor mailed reports, check if the reporter included a “regzbot command” like
}(hj hhhNhNubj )}(h%``#regzbot introduced: 1f2e3d4c5b6a``h]h!#regzbot introduced: 1f2e3d4c5b6a}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubh^. If not, send a reply (with the
regressions list in CC) with a paragraph like the following::}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKThj ubj )}(hregzbot ^introduced: v5.13..v5.14-rc1h]hregzbot ^introduced: v5.13..v5.14-rc1}hj sbah}(h]h ]h"]h$]h&]hhuh1j hhhKXhj ubh)}(hThis tells regzbot the version range in which the issue started to happen;
you can specify a range using commit-ids as well or state a single commit-id
in case the reporter bisected the culprit.h]hThis tells regzbot the version range in which the issue started to happen;
you can specify a range using commit-ids as well or state a single commit-id
in case the reporter bisected the culprit.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKZhj ubh)}(hX: Note the caret (^) before the "introduced": it tells regzbot to treat the
parent mail (the one you reply to) as the initial report for the regression
you want to see tracked; that's important, as regzbot will later look out
for patches with "Closes:" tags pointing to the report in the archives on
lore.kernel.org.h]hXD Note the caret (^) before the “introduced”: it tells regzbot to treat the
parent mail (the one you reply to) as the initial report for the regression
you want to see tracked; that’s important, as regzbot will later look out
for patches with “Closes:” tags pointing to the report in the archives on
lore.kernel.org.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK^hj ubeh}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hX When forwarding a regression reported to a bug tracker, include a paragraph
with these regzbot commands::
#regzbot introduced: 1f2e3d4c5b6a
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
Regzbot will then automatically associate patches with the report that
contain "Closes:" tags pointing to your mail or the mentioned ticket.
h](h)}(hiWhen forwarding a regression reported to a bug tracker, include a paragraph
with these regzbot commands::h]hhWhen forwarding a regression reported to a bug tracker, include a paragraph
with these regzbot commands:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKdhj ubj )}(h#regzbot introduced: 1f2e3d4c5b6a
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789h]h#regzbot introduced: 1f2e3d4c5b6a
#regzbot from: Some N. Ice Human
#regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789}hj sbah}(h]h ]h"]h$]h&]hhuh1j hhhKghj ubh)}(hRegzbot will then automatically associate patches with the report that
contain "Closes:" tags pointing to your mail or the mentioned ticket.h]hRegzbot will then automatically associate patches with the report that
contain “Closes:” tags pointing to your mail or the mentioned ticket.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKkhj ubeh}(h]h ]h"]h$]h&]uh1j! hj ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKThj ubah}(h]h ]h"]h$]h&]uh1jq hhhKThj hhubeh}(h],what-to-do-when-receiving-regression-reportsah ]h"],what to do when receiving regression reportsah$]h&]uh1hhj hhhhhKAubh)}(hhh](h)}(h(What's important when fixing regressionsh]h*What’s important when fixing regressions}(hj' hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj$ hhhhhKoubh)}(hX& You don't need to do anything special when submitting fixes for regression, just
remember to do what Documentation/process/submitting-patches.rst,
:ref:`Documentation/process/5.Posting.rst `, and
Documentation/process/stable-kernel-rules.rst already explain in more detail:h](hYou don’t need to do anything special when submitting fixes for regression, just
remember to do what Documentation/process/submitting-patches.rst,
}(hj5 hhhNhNubh)}(h@:ref:`Documentation/process/5.Posting.rst `h]j^ )}(hj? h]h#Documentation/process/5.Posting.rst}(hjA hhhNhNubah}(h]h ](ji stdstd-refeh"]h$]h&]uh1j] hj= ubah}(h]h ]h"]h$]h&]refdocjv refdomainjK reftyperefrefexplicitrefwarnj| development_postinguh1hhhhKqhj5 ubhS, and
Documentation/process/stable-kernel-rules.rst already explain in more detail:}(hj5 hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKqhj$ hhubjr )}(hX * Point to all places where the issue was reported using "Closes:" tags::
Closes: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
If you are only fixing part of the issue, you may use "Link:" instead as
described in the first document mentioned above. regzbot currently treats
both of these equivalently and considers the linked reports as resolved.
* Add a "Fixes:" tag to specify the commit causing the regression.
* If the culprit was merged in an earlier development cycle, explicitly mark
the fix for backporting using the ``Cc: stable@vger.kernel.org`` tag.
h]jx )}(hhh](j" )}(hX Point to all places where the issue was reported using "Closes:" tags::
Closes: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
If you are only fixing part of the issue, you may use "Link:" instead as
described in the first document mentioned above. regzbot currently treats
both of these equivalently and considers the linked reports as resolved.
h](h)}(hGPoint to all places where the issue was reported using "Closes:" tags::h]hJPoint to all places where the issue was reported using “Closes:” tags:}(hjr hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKvhjn ubj )}(hCloses: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890h]hCloses: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890}hj sbah}(h]h ]h"]h$]h&]hhuh1j hhhKxhjn ubh)}(hIf you are only fixing part of the issue, you may use "Link:" instead as
described in the first document mentioned above. regzbot currently treats
both of these equivalently and considers the linked reports as resolved.h]hIf you are only fixing part of the issue, you may use “Link:” instead as
described in the first document mentioned above. regzbot currently treats
both of these equivalently and considers the linked reports as resolved.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK{hjn ubeh}(h]h ]h"]h$]h&]uh1j! hjk ubj" )}(hAAdd a "Fixes:" tag to specify the commit causing the regression.
h]h)}(h@Add a "Fixes:" tag to specify the commit causing the regression.h]hDAdd a “Fixes:” tag to specify the commit causing the regression.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hjk ubj" )}(hIf the culprit was merged in an earlier development cycle, explicitly mark
the fix for backporting using the ``Cc: stable@vger.kernel.org`` tag.
h]h)}(hIf the culprit was merged in an earlier development cycle, explicitly mark
the fix for backporting using the ``Cc: stable@vger.kernel.org`` tag.h](hmIf the culprit was merged in an earlier development cycle, explicitly mark
the fix for backporting using the }(hj hhhNhNubj )}(h``Cc: stable@vger.kernel.org``h]hCc: stable@vger.kernel.org}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubh tag.}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hjk ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKvhjg ubah}(h]h ]h"]h$]h&]uh1jq hhhKvhj$ hhubh)}(hX All this is expected from you and important when it comes to regression, as
these tags are of great value for everyone (you included) that might be looking
into the issue weeks, months, or years later. These tags are also crucial for
tools and scripts used by other kernel developers or Linux distributions; one of
these tools is regzbot, which heavily relies on the "Closes:" tags to associate
reports for regression with changes resolving them.h]hX All this is expected from you and important when it comes to regression, as
these tags are of great value for everyone (you included) that might be looking
into the issue weeks, months, or years later. These tags are also crucial for
tools and scripts used by other kernel developers or Linux distributions; one of
these tools is regzbot, which heavily relies on the “Closes:” tags to associate
reports for regression with changes resolving them.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj$ hhubeh}(h](what-s-important-when-fixing-regressionsah ]h"](what's important when fixing regressionsah$]h&]uh1hhj hhhhhKoubh)}(hhh](h)}(h6Expectations and best practices for fixing regressionsh]h6Expectations and best practices for fixing regressions}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhKubh)}(hAs a Linux kernel developer, you are expected to give your best to prevent
situations where a regression caused by a recent change of yours leaves users
only these options:h]hAs a Linux kernel developer, you are expected to give your best to prevent
situations where a regression caused by a recent change of yours leaves users
only these options:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubjr )}(hX * Run a kernel with a regression that impacts usage.
* Switch to an older or newer kernel series.
* Continue running an outdated and thus potentially insecure kernel for more
than three weeks after the regression's culprit was identified. Ideally it
should be less than two. And it ought to be just a few days, if the issue is
severe or affects many users -- either in general or in prevalent
environments.
h]jx )}(hhh](j" )}(h3Run a kernel with a regression that impacts usage.
h]h)}(h2Run a kernel with a regression that impacts usage.h]h2Run a kernel with a regression that impacts usage.}(hj0 hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj, ubah}(h]h ]h"]h$]h&]uh1j! hj) ubj" )}(h+Switch to an older or newer kernel series.
h]h)}(h*Switch to an older or newer kernel series.h]h*Switch to an older or newer kernel series.}(hjH hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjD ubah}(h]h ]h"]h$]h&]uh1j! hj) ubj" )}(hX3 Continue running an outdated and thus potentially insecure kernel for more
than three weeks after the regression's culprit was identified. Ideally it
should be less than two. And it ought to be just a few days, if the issue is
severe or affects many users -- either in general or in prevalent
environments.
h]h)}(hX2 Continue running an outdated and thus potentially insecure kernel for more
than three weeks after the regression's culprit was identified. Ideally it
should be less than two. And it ought to be just a few days, if the issue is
severe or affects many users -- either in general or in prevalent
environments.h]hX4 Continue running an outdated and thus potentially insecure kernel for more
than three weeks after the regression’s culprit was identified. Ideally it
should be less than two. And it ought to be just a few days, if the issue is
severe or affects many users -- either in general or in prevalent
environments.}(hj` hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj\ ubah}(h]h ]h"]h$]h&]uh1j! hj) ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKhj% ubah}(h]h ]h"]h$]h&]uh1jq hhhKhj hhubh)}(hhHow to realize that in practice depends on various factors. Use the following
rules of thumb as a guide.h]hhHow to realize that in practice depends on various factors. Use the following
rules of thumb as a guide.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubh)}(hIn general:h]hIn general:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubjr )}(hX * Prioritize work on regressions over all other Linux kernel work, unless the
latter concerns a severe issue (e.g. acute security vulnerability, data loss,
bricked hardware, ...).
* Expedite fixing mainline regressions that recently made it into a proper
mainline, stable, or longterm release (either directly or via backport).
* Do not consider regressions from the current cycle as something that can wait
till the end of the cycle, as the issue might discourage or prevent users and
CI systems from testing mainline now or generally.
* Work with the required care to avoid additional or bigger damage, even if
resolving an issue then might take longer than outlined below.
h]jx )}(hhh](j" )}(hPrioritize work on regressions over all other Linux kernel work, unless the
latter concerns a severe issue (e.g. acute security vulnerability, data loss,
bricked hardware, ...).
h]h)}(hPrioritize work on regressions over all other Linux kernel work, unless the
latter concerns a severe issue (e.g. acute security vulnerability, data loss,
bricked hardware, ...).h]hPrioritize work on regressions over all other Linux kernel work, unless the
latter concerns a severe issue (e.g. acute security vulnerability, data loss,
bricked hardware, ...).}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hExpedite fixing mainline regressions that recently made it into a proper
mainline, stable, or longterm release (either directly or via backport).
h]h)}(hExpedite fixing mainline regressions that recently made it into a proper
mainline, stable, or longterm release (either directly or via backport).h]hExpedite fixing mainline regressions that recently made it into a proper
mainline, stable, or longterm release (either directly or via backport).}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hDo not consider regressions from the current cycle as something that can wait
till the end of the cycle, as the issue might discourage or prevent users and
CI systems from testing mainline now or generally.
h]h)}(hDo not consider regressions from the current cycle as something that can wait
till the end of the cycle, as the issue might discourage or prevent users and
CI systems from testing mainline now or generally.h]hDo not consider regressions from the current cycle as something that can wait
till the end of the cycle, as the issue might discourage or prevent users and
CI systems from testing mainline now or generally.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hWork with the required care to avoid additional or bigger damage, even if
resolving an issue then might take longer than outlined below.
h]h)}(hWork with the required care to avoid additional or bigger damage, even if
resolving an issue then might take longer than outlined below.h]hWork with the required care to avoid additional or bigger damage, even if
resolving an issue then might take longer than outlined below.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKhj ubah}(h]h ]h"]h$]h&]uh1jq hhhKhj hhubh)}(h4On timing once the culprit of a regression is known:h]h4On timing once the culprit of a regression is known:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubjr )}(hX * Aim to mainline a fix within two or three days, if the issue is severe or
bothering many users -- either in general or in prevalent conditions like a
particular hardware environment, distribution, or stable/longterm series.
* Aim to mainline a fix by Sunday after the next, if the culprit made it
into a recent mainline, stable, or longterm release (either directly or via
backport); if the culprit became known early during a week and is simple to
resolve, try to mainline the fix within the same week.
* For other regressions, aim to mainline fixes before the hindmost Sunday
within the next three weeks. One or two Sundays later are acceptable, if the
regression is something people can live with easily for a while -- like a
mild performance regression.
* It's strongly discouraged to delay mainlining regression fixes till the next
merge window, except when the fix is extraordinarily risky or when the
culprit was mainlined more than a year ago.
h]jx )}(hhh](j" )}(hAim to mainline a fix within two or three days, if the issue is severe or
bothering many users -- either in general or in prevalent conditions like a
particular hardware environment, distribution, or stable/longterm series.
h]h)}(hAim to mainline a fix within two or three days, if the issue is severe or
bothering many users -- either in general or in prevalent conditions like a
particular hardware environment, distribution, or stable/longterm series.h]hAim to mainline a fix within two or three days, if the issue is severe or
bothering many users -- either in general or in prevalent conditions like a
particular hardware environment, distribution, or stable/longterm series.}(hj( hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj$ ubah}(h]h ]h"]h$]h&]uh1j! hj! ubj" )}(hX Aim to mainline a fix by Sunday after the next, if the culprit made it
into a recent mainline, stable, or longterm release (either directly or via
backport); if the culprit became known early during a week and is simple to
resolve, try to mainline the fix within the same week.
h]h)}(hX Aim to mainline a fix by Sunday after the next, if the culprit made it
into a recent mainline, stable, or longterm release (either directly or via
backport); if the culprit became known early during a week and is simple to
resolve, try to mainline the fix within the same week.h]hX Aim to mainline a fix by Sunday after the next, if the culprit made it
into a recent mainline, stable, or longterm release (either directly or via
backport); if the culprit became known early during a week and is simple to
resolve, try to mainline the fix within the same week.}(hj@ hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj< ubah}(h]h ]h"]h$]h&]uh1j! hj! ubj" )}(hFor other regressions, aim to mainline fixes before the hindmost Sunday
within the next three weeks. One or two Sundays later are acceptable, if the
regression is something people can live with easily for a while -- like a
mild performance regression.
h]h)}(hFor other regressions, aim to mainline fixes before the hindmost Sunday
within the next three weeks. One or two Sundays later are acceptable, if the
regression is something people can live with easily for a while -- like a
mild performance regression.h]hFor other regressions, aim to mainline fixes before the hindmost Sunday
within the next three weeks. One or two Sundays later are acceptable, if the
regression is something people can live with easily for a while -- like a
mild performance regression.}(hjX hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjT ubah}(h]h ]h"]h$]h&]uh1j! hj! ubj" )}(hIt's strongly discouraged to delay mainlining regression fixes till the next
merge window, except when the fix is extraordinarily risky or when the
culprit was mainlined more than a year ago.
h]h)}(hIt's strongly discouraged to delay mainlining regression fixes till the next
merge window, except when the fix is extraordinarily risky or when the
culprit was mainlined more than a year ago.h]hIt’s strongly discouraged to delay mainlining regression fixes till the next
merge window, except when the fix is extraordinarily risky or when the
culprit was mainlined more than a year ago.}(hjp hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjl ubah}(h]h ]h"]h$]h&]uh1j! hj! ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKhj ubah}(h]h ]h"]h$]h&]uh1jq hhhKhj hhubh)}(h
On procedure:h]h
On procedure:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubjr )}(hX * Always consider reverting the culprit, as it's often the quickest and least
dangerous way to fix a regression. Don't worry about mainlining a fixed
variant later: that should be straight-forward, as most of the code went
through review once already.
* Try to resolve any regressions introduced in mainline during the past
twelve months before the current development cycle ends: Linus wants such
regressions to be handled like those from the current cycle, unless fixing
bears unusual risks.
* Consider CCing Linus on discussions or patch review, if a regression seems
tangly. Do the same in precarious or urgent cases -- especially if the
subsystem maintainer might be unavailable. Also CC the stable team, when you
know such a regression made it into a mainline, stable, or longterm release.
* For urgent regressions, consider asking Linus to pick up the fix straight
from the mailing list: he is totally fine with that for uncontroversial
fixes. Ideally though such requests should happen in accordance with the
subsystem maintainers or come directly from them.
* In case you are unsure if a fix is worth the risk applying just days before
a new mainline release, send Linus a mail with the usual lists and people in
CC; in it, summarize the situation while asking him to consider picking up
the fix straight from the list. He then himself can make the call and when
needed even postpone the release. Such requests again should ideally happen
in accordance with the subsystem maintainers or come directly from them.
h]jx )}(hhh](j" )}(hAlways consider reverting the culprit, as it's often the quickest and least
dangerous way to fix a regression. Don't worry about mainlining a fixed
variant later: that should be straight-forward, as most of the code went
through review once already.
h]h)}(hAlways consider reverting the culprit, as it's often the quickest and least
dangerous way to fix a regression. Don't worry about mainlining a fixed
variant later: that should be straight-forward, as most of the code went
through review once already.h]hAlways consider reverting the culprit, as it’s often the quickest and least
dangerous way to fix a regression. Don’t worry about mainlining a fixed
variant later: that should be straight-forward, as most of the code went
through review once already.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hTry to resolve any regressions introduced in mainline during the past
twelve months before the current development cycle ends: Linus wants such
regressions to be handled like those from the current cycle, unless fixing
bears unusual risks.
h]h)}(hTry to resolve any regressions introduced in mainline during the past
twelve months before the current development cycle ends: Linus wants such
regressions to be handled like those from the current cycle, unless fixing
bears unusual risks.h]hTry to resolve any regressions introduced in mainline during the past
twelve months before the current development cycle ends: Linus wants such
regressions to be handled like those from the current cycle, unless fixing
bears unusual risks.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hX, Consider CCing Linus on discussions or patch review, if a regression seems
tangly. Do the same in precarious or urgent cases -- especially if the
subsystem maintainer might be unavailable. Also CC the stable team, when you
know such a regression made it into a mainline, stable, or longterm release.
h]h)}(hX+ Consider CCing Linus on discussions or patch review, if a regression seems
tangly. Do the same in precarious or urgent cases -- especially if the
subsystem maintainer might be unavailable. Also CC the stable team, when you
know such a regression made it into a mainline, stable, or longterm release.h]hX+ Consider CCing Linus on discussions or patch review, if a regression seems
tangly. Do the same in precarious or urgent cases -- especially if the
subsystem maintainer might be unavailable. Also CC the stable team, when you
know such a regression made it into a mainline, stable, or longterm release.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hX
For urgent regressions, consider asking Linus to pick up the fix straight
from the mailing list: he is totally fine with that for uncontroversial
fixes. Ideally though such requests should happen in accordance with the
subsystem maintainers or come directly from them.
h]h)}(hX For urgent regressions, consider asking Linus to pick up the fix straight
from the mailing list: he is totally fine with that for uncontroversial
fixes. Ideally though such requests should happen in accordance with the
subsystem maintainers or come directly from them.h]hX For urgent regressions, consider asking Linus to pick up the fix straight
from the mailing list: he is totally fine with that for uncontroversial
fixes. Ideally though such requests should happen in accordance with the
subsystem maintainers or come directly from them.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hX In case you are unsure if a fix is worth the risk applying just days before
a new mainline release, send Linus a mail with the usual lists and people in
CC; in it, summarize the situation while asking him to consider picking up
the fix straight from the list. He then himself can make the call and when
needed even postpone the release. Such requests again should ideally happen
in accordance with the subsystem maintainers or come directly from them.
h]h)}(hX In case you are unsure if a fix is worth the risk applying just days before
a new mainline release, send Linus a mail with the usual lists and people in
CC; in it, summarize the situation while asking him to consider picking up
the fix straight from the list. He then himself can make the call and when
needed even postpone the release. Such requests again should ideally happen
in accordance with the subsystem maintainers or come directly from them.h]hX In case you are unsure if a fix is worth the risk applying just days before
a new mainline release, send Linus a mail with the usual lists and people in
CC; in it, summarize the situation while asking him to consider picking up
the fix straight from the list. He then himself can make the call and when
needed even postpone the release. Such requests again should ideally happen
in accordance with the subsystem maintainers or come directly from them.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKhj ubah}(h]h ]h"]h$]h&]uh1jq hhhKhj hhubh)}(h&Regarding stable and longterm kernels:h]h&Regarding stable and longterm kernels:}(hj) hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubjr )}(hXf * You are free to leave regressions to the stable team, if they at no point in
time occurred with mainline or were fixed there already.
* If a regression made it into a proper mainline release during the past
twelve months, ensure to tag the fix with "Cc: stable@vger.kernel.org", as a
"Fixes:" tag alone does not guarantee a backport. Please add the same tag,
in case you know the culprit was backported to stable or longterm kernels.
* When receiving reports about regressions in recent stable or longterm kernel
series, please evaluate at least briefly if the issue might happen in current
mainline as well -- and if that seems likely, take hold of the report. If in
doubt, ask the reporter to check mainline.
* Whenever you want to swiftly resolve a regression that recently also made it
into a proper mainline, stable, or longterm release, fix it quickly in
mainline; when appropriate thus involve Linus to fast-track the fix (see
above). That's because the stable team normally does neither revert nor fix
any changes that cause the same problems in mainline.
* In case of urgent regression fixes you might want to ensure prompt
backporting by dropping the stable team a note once the fix was mainlined;
this is especially advisable during merge windows and shortly thereafter, as
the fix otherwise might land at the end of a huge patch queue.
h]jx )}(hhh](j" )}(hYou are free to leave regressions to the stable team, if they at no point in
time occurred with mainline or were fixed there already.
h]h)}(hYou are free to leave regressions to the stable team, if they at no point in
time occurred with mainline or were fixed there already.h]hYou are free to leave regressions to the stable team, if they at no point in
time occurred with mainline or were fixed there already.}(hjB hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj> ubah}(h]h ]h"]h$]h&]uh1j! hj; ubj" )}(hX* If a regression made it into a proper mainline release during the past
twelve months, ensure to tag the fix with "Cc: stable@vger.kernel.org", as a
"Fixes:" tag alone does not guarantee a backport. Please add the same tag,
in case you know the culprit was backported to stable or longterm kernels.
h]h)}(hX) If a regression made it into a proper mainline release during the past
twelve months, ensure to tag the fix with "Cc: stable@vger.kernel.org", as a
"Fixes:" tag alone does not guarantee a backport. Please add the same tag,
in case you know the culprit was backported to stable or longterm kernels.h](hxIf a regression made it into a proper mainline release during the past
twelve months, ensure to tag the fix with “Cc: }(hjZ hhhNhNubj0 )}(hstable@vger.kernel.orgh]hstable@vger.kernel.org}(hjb hhhNhNubah}(h]h ]h"]h$]h&]refurimailto:stable@vger.kernel.orguh1j/ hjZ ubh”, as a
“Fixes:” tag alone does not guarantee a backport. Please add the same tag,
in case you know the culprit was backported to stable or longterm kernels.}(hjZ hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjV ubah}(h]h ]h"]h$]h&]uh1j! hj; ubj" )}(hX When receiving reports about regressions in recent stable or longterm kernel
series, please evaluate at least briefly if the issue might happen in current
mainline as well -- and if that seems likely, take hold of the report. If in
doubt, ask the reporter to check mainline.
h]h)}(hX When receiving reports about regressions in recent stable or longterm kernel
series, please evaluate at least briefly if the issue might happen in current
mainline as well -- and if that seems likely, take hold of the report. If in
doubt, ask the reporter to check mainline.h]hX When receiving reports about regressions in recent stable or longterm kernel
series, please evaluate at least briefly if the issue might happen in current
mainline as well -- and if that seems likely, take hold of the report. If in
doubt, ask the reporter to check mainline.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj; ubj" )}(hX_ Whenever you want to swiftly resolve a regression that recently also made it
into a proper mainline, stable, or longterm release, fix it quickly in
mainline; when appropriate thus involve Linus to fast-track the fix (see
above). That's because the stable team normally does neither revert nor fix
any changes that cause the same problems in mainline.
h]h)}(hX^ Whenever you want to swiftly resolve a regression that recently also made it
into a proper mainline, stable, or longterm release, fix it quickly in
mainline; when appropriate thus involve Linus to fast-track the fix (see
above). That's because the stable team normally does neither revert nor fix
any changes that cause the same problems in mainline.h]hX` Whenever you want to swiftly resolve a regression that recently also made it
into a proper mainline, stable, or longterm release, fix it quickly in
mainline; when appropriate thus involve Linus to fast-track the fix (see
above). That’s because the stable team normally does neither revert nor fix
any changes that cause the same problems in mainline.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj; ubj" )}(hX In case of urgent regression fixes you might want to ensure prompt
backporting by dropping the stable team a note once the fix was mainlined;
this is especially advisable during merge windows and shortly thereafter, as
the fix otherwise might land at the end of a huge patch queue.
h]h)}(hX In case of urgent regression fixes you might want to ensure prompt
backporting by dropping the stable team a note once the fix was mainlined;
this is especially advisable during merge windows and shortly thereafter, as
the fix otherwise might land at the end of a huge patch queue.h]hX In case of urgent regression fixes you might want to ensure prompt
backporting by dropping the stable team a note once the fix was mainlined;
this is especially advisable during merge windows and shortly thereafter, as
the fix otherwise might land at the end of a huge patch queue.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj; ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKhj7 ubah}(h]h ]h"]h$]h&]uh1jq hhhKhj hhubh)}(hOn patch flow:h]hOn patch flow:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj hhubjr )}(hXD * Developers, when trying to reach the time periods mentioned above, remember
to account for the time it takes to get fixes tested, reviewed, and merged by
Linus, ideally with them being in linux-next at least briefly. Hence, if a
fix is urgent, make it obvious to ensure others handle it appropriately.
* Reviewers, you are kindly asked to assist developers in reaching the time
periods mentioned above by reviewing regression fixes in a timely manner.
* Subsystem maintainers, you likewise are encouraged to expedite the handling
of regression fixes. Thus evaluate if skipping linux-next is an option for
the particular fix. Also consider sending git pull requests more often than
usual when needed. And try to avoid holding onto regression fixes over
weekends -- especially when the fix is marked for backporting.
h]jx )}(hhh](j" )}(hX. Developers, when trying to reach the time periods mentioned above, remember
to account for the time it takes to get fixes tested, reviewed, and merged by
Linus, ideally with them being in linux-next at least briefly. Hence, if a
fix is urgent, make it obvious to ensure others handle it appropriately.
h]h)}(hX- Developers, when trying to reach the time periods mentioned above, remember
to account for the time it takes to get fixes tested, reviewed, and merged by
Linus, ideally with them being in linux-next at least briefly. Hence, if a
fix is urgent, make it obvious to ensure others handle it appropriately.h]hX- Developers, when trying to reach the time periods mentioned above, remember
to account for the time it takes to get fixes tested, reviewed, and merged by
Linus, ideally with them being in linux-next at least briefly. Hence, if a
fix is urgent, make it obvious to ensure others handle it appropriately.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hReviewers, you are kindly asked to assist developers in reaching the time
periods mentioned above by reviewing regression fixes in a timely manner.
h]h)}(hReviewers, you are kindly asked to assist developers in reaching the time
periods mentioned above by reviewing regression fixes in a timely manner.h]hReviewers, you are kindly asked to assist developers in reaching the time
periods mentioned above by reviewing regression fixes in a timely manner.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubj" )}(hXj Subsystem maintainers, you likewise are encouraged to expedite the handling
of regression fixes. Thus evaluate if skipping linux-next is an option for
the particular fix. Also consider sending git pull requests more often than
usual when needed. And try to avoid holding onto regression fixes over
weekends -- especially when the fix is marked for backporting.
h]h)}(hXh Subsystem maintainers, you likewise are encouraged to expedite the handling
of regression fixes. Thus evaluate if skipping linux-next is an option for
the particular fix. Also consider sending git pull requests more often than
usual when needed. And try to avoid holding onto regression fixes over
weekends -- especially when the fix is marked for backporting.h]hXh Subsystem maintainers, you likewise are encouraged to expedite the handling
of regression fixes. Thus evaluate if skipping linux-next is an option for
the particular fix. Also consider sending git pull requests more often than
usual when needed. And try to avoid holding onto regression fixes over
weekends -- especially when the fix is marked for backporting.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj ubah}(h]h ]h"]h$]h&]uh1j! hj ubeh}(h]h ]h"]h$]h&]j j uh1jw hhhKhj ubah}(h]h ]h"]h$]h&]uh1jq hhhKhj hhubeh}(h]6expectations-and-best-practices-for-fixing-regressionsah ]h"]6expectations and best practices for fixing regressionsah$]h&]uh1hhj hhhhhKubeh}(h]#the-important-basics-in-more-detailah ]h"]#the important basics in more detailah$]h&]uh1hhj hhhhhK=ubh)}(hhh](h)}(h@More aspects regarding regressions developers should be aware ofh]h@More aspects regarding regressions developers should be aware of}(hjR hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjO hhhhhMubh)}(hhh](h)}(h