You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This guide focuses on the `#regzbot` commands reporters and developers can use
16
+
to add or update tracked regressions.
17
+
18
+
6
19
## Why and how to make regzbot track a Linux kernel regression
7
20
8
21
When reporting a Linux kernel regression it is in your interest to make [regzbot](https://gitlab.com/knurd42/regzbot/) aware of the issue, as that ensures the report won't accidentally fall though the cracks; it also makes sure leading developers see the issue via the tracked regression website [or the weekly reports, which are not sent yet, but soon will be].
@@ -26,6 +39,18 @@ Regzbot is designed to normally not create any additional chores for Linux kerne
26
39
But sometimes you might want to do more with regzbot, like specifying a culprit exactly after a bisection or marking a regression as resolved. The text below explains how to do these and other things; the instructions there also will tell you how to use regzbot to track regressions for your own code or the subsystem you maintain, as that will make sure none fall through the cracks unnoticed.
27
40
28
41
42
+
## How to help keep tracking accurate
43
+
44
+
If a tracked issue turns out not to be a regression, if discussion moved
45
+
elsewhere, or if important details such as the title or introduced range are
46
+
wrong, please reply publicly and include the appropriate `#regzbot` command.
47
+
That keeps the public record clear and helps regzbot show useful status.
48
+
49
+
Developers do not need to CC individual regression trackers on every follow-up.
50
+
Keep `regressions@lists.linux.dev` in the loop and use `Link:` or `Closes:`
51
+
tags that point to the report when posting fixes.
52
+
53
+
29
54
## More regzbot features relevant for both reporters and developers
0 commit comments