Hi! A mailing list for regressions was finally created as
[email protected] (we dropped the linux- prefix as the term is already
in the domain name). Hence, add it to MAINTAINERS, as that where people will
look it up. I was a bit unsure how to actually do that, see the note in the
first patch of the series for details.
The second patch makes reporting-issues.rst mention the new list, so people CC
it. At the same time it also tells them to adds a special line to help with
manual or automatic tracking. This is not done yet, but I will work on this over
the next few months, so it seemed wise to add it right from the start. See the
patch for details and the comment in it for some things where some input from
others might be helpful.
@Jonathan: this hopefully is the last round of patches for reporting-issues.rst
for this cycle. Please let me known if you think the addition to the MAINTAINERS
file should better go through a different maintainer.
Ciao, Thorsten
Thorsten Leemhuis (2):
MAINTAINERS: add regressions mailing list
docs: reporting-issues: make everyone CC the regressions list
.../admin-guide/reporting-issues.rst | 64 +++++++++++++------
MAINTAINERS | 4 ++
2 files changed, 48 insertions(+), 20 deletions(-)
base-commit: a4f413348f268c4313f58ca383173ee5986d968a
--
2.30.2
Add the newly created regression mailing list finally created after it
already had been agreed on during the maintainers summit 2017 (see
https://lwn.net/Articles/738216/ ). The topic was recently discussed
again, where an idea to create a broader list for all issues was
discussed, but Linus preferred a more targeted list:
https://lkml.kernel.org/r/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/
Hence, the creation for that list was asked for and granted:
https://bugzilla.kernel.org/show_bug.cgi?id=212557
In the end it became [email protected] instead of
[email protected] as 'Linux' is redundant in the latter
case.
Signed-off-by: Thorsten Leemhuis <[email protected]>
---
I was a bit unsure how to add that list to MAINTAINERS. I considered
adding a 'M:' with my name and email address there as well, but getting
CCed on a lot of regression reports might be a bit much. I also left a
'S: supported' out, as that doesn't make much sense in this case afaics;
and I checked, there are other entries that don't have those two (but
it's rare).
Ciao, Thorsten
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 03b2096a5f8f..dd5743d1f743 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15212,6 +15212,10 @@ F: Documentation/devicetree/bindings/regmap/
F: drivers/base/regmap/
F: include/linux/regmap.h
+REGRESSIONS
+L: [email protected]
+K: regression
+
REISERFS FILE SYSTEM
L: [email protected]
S: Supported
--
2.30.2
Make people CC the recently created mailing list dedicated to Linux
kernel regressions when reporting one. Some paragraphs had to be
reshuffled and slightly rewritten during the process, as the text
otherwise would have gotten unnecessarily hard to follow.
The new text also makes reporters include a line useful for automatic
regression tracking solution which does not exist yet, but is planned.
The term "#regzb" (short for regression bot) is inspired by the "#syz"
which can be used to communicate with syszbot (see
https://github.com/google/syzkaller/blob/master/docs/syzbot.md).
Signed-off-by: Thorsten Leemhuis <[email protected]>
---
Lo! Now that we have a mailing list for regressions I was inclined to
remove the "Make the report's subject start with '[REGRESSION]'" part
from the text. But in the end I left it, to make it obvious on other
lists that the mail is about a regression. Nevertheless, I'm still
wondering if it should be toned down a bit, as it might be enough if the
subject starts with "regression:" or contains the word somewhere.
That automatic tracking solution hinted at in the commit message is
something I plan to work on in the next months. It won't be another
bugzilla-like tracker, more a simple database that works in the
background like syzbot. I'm not attached to the "#regzb" term, so please
speak up if you can think of something better that also works when
searching the internet.
Ciao, Thorsten
---
.../admin-guide/reporting-issues.rst | 64 +++++++++++++------
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
index fd407c6951ea..45065c501beb 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -23,7 +23,8 @@ longterm series? One still supported? Then search the `LKML
<https://lore.kernel.org/stable/>`_ archives for matching reports to join. If
you don't find any, install `the latest release from that series
<https://kernel.org/>`_. If it still shows the issue, report it to the stable
-mailing list ([email protected]).
+mailing list ([email protected]) and CC the regressions list
+([email protected]).
In all other cases try your best guess which kernel part might be causing the
issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
@@ -44,10 +45,11 @@ ensure it's vanilla (IOW: not patched and not using add-on modules). Also make
sure it's built and running in a healthy environment and not already tainted
before the issue occurs.
-While writing your report, include all information relevant to the issue, like
-the kernel and the distro used. In case of a regression try to include the
-commit-id of the change causing it, which a bisection can find. If you're facing
-multiple issues with the Linux kernel at once, report each separately.
+If you are facing multiple issues with the Linux kernel at once, report each
+separately. While writing your report, include all information relevant to the
+issue, like the kernel and the distro used. In case of a regression, CC the
+regressions mailing list ([email protected]) to your report; also try
+to include the commit-id of the change causing it, which a bisection can find.
Once the report is out, answer any questions that come up and help where you
can. That includes keeping the ball rolling by occasionally retesting with newer
@@ -192,12 +194,14 @@ report them:
kernel. Ensure this kernel is not tainted and still shows the problem, as
the issue might have already been fixed there. If you first noticed the
problem with a vendor kernel, check a vanilla build of the last version
- known to work performs fine as well.*
+ known to work performs fine as well.
* Send a short problem report to the Linux stable mailing list
- ([email protected]). Roughly describe the issue and ideally explain
- how to reproduce it. Mention the first version that shows the problem and
- the last version that's working fine. Then wait for further instructions.*
+ ([email protected]) and CC the Linux regressions mailing list
+ ([email protected]). Roughly describe the issue and ideally
+ explain how to reproduce it. Mention the commit or version that introduced
+ the regression as outlined in 'Special handling for high priority issues'.
+ Then wait for further instructions.
The reference section below explains each of these steps in more detail.
@@ -1236,14 +1240,32 @@ Reports for high priority issues need special handling.
**Severe issues**: make sure the subject or ticket title as well as the first
paragraph makes the severeness obvious.
-**Regressions**: If the issue is a regression add [REGRESSION] to the mail's
-subject or the title in the bug-tracker. If you did not perform a bisection
-mention at least the latest mainline version you tested that worked fine (say
-5.7) and the oldest where the issue occurs (say 5.8). If you did a successful
-bisection mention the commit id and subject of the change that causes the
-regression. Also make sure to add the author of that change to your report; if
-you need to file your bug in a bug-tracker forward the report to him in a
-private mail and mention where your filed it.
+**Regressions**: Make the report's subject start with '[REGRESSION]'.
+
+In case you performed a successful bisection, use the title of the change that
+introduced the regression as the second part of your subject. Make the report
+also mention the commit id of the culprit. For tracking purposes, add a line
+like the following that contains both pieces of information, but with the
+commit id shortened to 12 characters::
+
+ #regzb introduced: 94a632d91ad1 ("usc: xhbi-foo: check bar_params earlier")
+
+In case of an unsuccessful bisection, make your report mention the latest tested
+version that's working fine (say 5.7) and the oldest where the issue occurs (say
+5.8-rc1). For tracking purposes add a line expressing it like this::
+
+ #regzb introduced: v5.7..v5.8-rc1
+
+When sending the report by mail, CC the Linux regressions mailing list
+([email protected]). In case the report needs to be filed to some web
+tracker, proceed to do so; once filed, forward the report by mail to the
+regressions list. Make sure to inline the forwarded report, hence do not attach
+it. Also add a short note at the top where you mention the URL to the ticket and
+repeat the line starting with '#regzb'.
+
+When mailing or forwarding the report, in case of a successful bisection add the
+author of the culprit to the recipients; also CC everyone in the signed-off-by
+chain, which you find at the end of its commit message.
**Security issues**: for these issues your will have to evaluate if a
short-term risk to other users would arise if details were publicly disclosed.
@@ -1523,9 +1545,11 @@ Report the regression
~~~~~~~~~~~~~~~~~~~~~
*Send a short problem report to the Linux stable mailing list
- ([email protected]). Roughly describe the issue and ideally explain
- how to reproduce it. Mention the first version that shows the problem and
- the last version that's working fine. Then wait for further instructions.*
+ ([email protected]) and CC the Linux regressions mailing list
+ ([email protected]). Roughly describe the issue and ideally
+ explain how to reproduce it. Mention the commit or version that introduced
+ the regression as outlined in 'Special handling for high priority issues'.
+ Then wait for further instructions.*
When reporting a regression that happens within a stable or longterm kernel
line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
--
2.30.2
On Wed, Apr 07, 2021 at 11:21:55AM +0200, Thorsten Leemhuis wrote:
> Add the newly created regression mailing list finally created after it
> already had been agreed on during the maintainers summit 2017 (see
> https://lwn.net/Articles/738216/ ). The topic was recently discussed
> again, where an idea to create a broader list for all issues was
> discussed, but Linus preferred a more targeted list:
> https://lkml.kernel.org/r/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/
>
> Hence, the creation for that list was asked for and granted:
> https://bugzilla.kernel.org/show_bug.cgi?id=212557
>
> In the end it became [email protected] instead of
> [email protected] as 'Linux' is redundant in the latter
> case.
>
> Signed-off-by: Thorsten Leemhuis <[email protected]>
> ---
> I was a bit unsure how to add that list to MAINTAINERS. I considered
> adding a 'M:' with my name and email address there as well, but getting
> CCed on a lot of regression reports might be a bit much. I also left a
> 'S: supported' out, as that doesn't make much sense in this case afaics;
> and I checked, there are other entries that don't have those two (but
> it's rare).
Put your name there, you are the "maintainer of regressions!" :)
Seriously, it's good to do that, maintainers entries that just have no
one "responsible" always seem to end up being a black hole.
>
> Ciao, Thorsten
> ---
> MAINTAINERS | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 03b2096a5f8f..dd5743d1f743 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15212,6 +15212,10 @@ F: Documentation/devicetree/bindings/regmap/
> F: drivers/base/regmap/
> F: include/linux/regmap.h
>
> +REGRESSIONS
> +L: [email protected]
> +K: regression
A bit more information here perhaps? This will not really help anyone
out to know what to do.
thanks,
greg k-h
On Wed, Apr 07, 2021 at 11:21:56AM +0200, Thorsten Leemhuis wrote:
> Make people CC the recently created mailing list dedicated to Linux
> kernel regressions when reporting one. Some paragraphs had to be
> reshuffled and slightly rewritten during the process, as the text
> otherwise would have gotten unnecessarily hard to follow.
>
> The new text also makes reporters include a line useful for automatic
> regression tracking solution which does not exist yet, but is planned.
> The term "#regzb" (short for regression bot) is inspired by the "#syz"
> which can be used to communicate with syszbot (see
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md).
While I understand the wish to automate things like this, the #syz
marking will actually cause something to go off and do some work, and is
only relevant for a very small number of developers, all of whom know to
look up the instructions before doing so. But the #regzb marking will
be requested to be added by random users who never have submitted a
problem report before, OR from long-time kernel developers who are lucky
to ever remember to read the documentation as they "know" how to do
this.
So this increased workload by people on the two ends of experience is
going to be rough, I predict a very low rate of adoption :(
What is the tag going to be good for? The reports will need to be
handled by a person anyway and classified and tracked out-of-band from
the list somehow. Will a tag do all that much here?
thanks,
greg k-h
On 07.04.21 11:56, Greg KH wrote:
> On Wed, Apr 07, 2021 at 11:21:55AM +0200, Thorsten Leemhuis wrote:
>> Add the newly created regression mailing list finally created after it
>> already had been agreed on during the maintainers summit 2017 (see
>> https://lwn.net/Articles/738216/ ). The topic was recently discussed
>> again, where an idea to create a broader list for all issues was
>> discussed, but Linus preferred a more targeted list:
>> https://lkml.kernel.org/r/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/
>>
>> Hence, the creation for that list was asked for and granted:
>> https://bugzilla.kernel.org/show_bug.cgi?id=212557
>>
>> In the end it became [email protected] instead of
>> [email protected] as 'Linux' is redundant in the latter
>> case.
>>
>> Signed-off-by: Thorsten Leemhuis <[email protected]>
>> ---
>> I was a bit unsure how to add that list to MAINTAINERS. I considered
>> adding a 'M:' with my name and email address there as well, but getting
>> CCed on a lot of regression reports might be a bit much. I also left a
>> 'S: supported' out, as that doesn't make much sense in this case afaics;
>> and I checked, there are other entries that don't have those two (but
>> it's rare).
>
> Put your name there, you are the "maintainer of regressions!" :)
Okay, will do. :-D
/me wonders why he suddenly feels like entering a self-made trap ;-)
> [...]
>> +REGRESSIONS
>> +L: [email protected]
>> +K: regression
>
> A bit more information here perhaps? This will not really help anyone
> out to know what to do.
Did you mean a different headline for the entry? Or would you suggest
to use a webpage (W:) for that or a Subsystem Profile document (P:)
here? Using either of the two latter was the plan, but for now I'm a bit
unsure what to write there except maybe "Thorsten is working on a
semi-automatic solution for tracking Linux kernel regressions. Details
will follow. For now report regressions as outlined in
reporting-issues.rst; but in case you have any problem or think there is
a regressions not handled appropriately by the maintainers, get him
involved, he'll try to help".
Or did you have something totally different in mind?
Ciao, Thorsten
On 07.04.21 12:00, Greg KH wrote:
> On Wed, Apr 07, 2021 at 11:21:56AM +0200, Thorsten Leemhuis wrote:
>> Make people CC the recently created mailing list dedicated to Linux
>> kernel regressions when reporting one. Some paragraphs had to be
>> reshuffled and slightly rewritten during the process, as the text
>> otherwise would have gotten unnecessarily hard to follow.
>>
>> The new text also makes reporters include a line useful for automatic
>> regression tracking solution which does not exist yet, but is planned.
>> The term "#regzb" (short for regression bot) is inspired by the "#syz"
>> which can be used to communicate with syszbot (see
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md).
>
> While I understand the wish to automate things like this, the #syz
> marking will actually cause something to go off and do some work, and is
> only relevant for a very small number of developers, all of whom know to
> look up the instructions before doing so. But the #regzb marking will
> be requested to be added by random users who never have submitted a
> problem report before, OR from long-time kernel developers who are lucky
> to ever remember to read the documentation as they "know" how to do
> this.
>
> So this increased workload by people on the two ends of experience is
> going to be rough, I predict a very low rate of adoption :(
Yup, I'm aware of that. And also well aware that I will need to keep an
eye on things and jump in and reply with mails to add such tags every
time they are missing.
But I think that direction it the best shot, as tying putting all the
burden on one person (me) is likely to fail, as our history with
regression tracking showed. And I think such tags with some bot in the
background
(as outlined roughly in
https://linux-regtracking.leemhuis.info/post/hello-world/ ) have at
least the best chance, as things are not out-of-band like tracking them
in bugzilla would be – or do you think that would be a better approach
together with its email-interface?
> What is the tag going to be good for? The reports will need to be
> handled by a person anyway and classified and tracked out-of-band from
> the list somehow. Will a tag do all that much here?
I think is has, as then a good regression report will make the
still-to-be-written regression-bot create and entry that links to the
report and send a reply with a unique ID; then that ID needs to end up
in the commit that fixes the regression later (similar to how the IDs
for issues found by syzbot are mentioned there, which afaics works quite
well for people) and the regression-bot can close the entry automatically.
At least in this ideal scenario the regression tracker (me) wouldn't
need to do a single thing.
Obviously that ideal scenario will be rare, especially in the beginning.
But with some hand-holding from my side (by mailing tags) I hope it will
work at least sometimes (and over time more often).
But I'm open for other approaches, as I didn't start to work on the bot
yet(¹), so it's easy to go into a different direction if someone comes
up with one that looks more promising.
Ciao, Thorsten
(¹) still unsure if I should take Go code from syzbot as a base or
better go with python, as that's what the kernel.org admins iirc prefer
(or am I wrong there? I wanted to ask Konstantin about this soon anyway)
On Wed, Apr 07, 2021 at 12:51:43PM +0200, Thorsten Leemhuis wrote:
> On 07.04.21 11:56, Greg KH wrote:
> > On Wed, Apr 07, 2021 at 11:21:55AM +0200, Thorsten Leemhuis wrote:
> >> Add the newly created regression mailing list finally created after it
> >> already had been agreed on during the maintainers summit 2017 (see
> >> https://lwn.net/Articles/738216/ ). The topic was recently discussed
> >> again, where an idea to create a broader list for all issues was
> >> discussed, but Linus preferred a more targeted list:
> >> https://lkml.kernel.org/r/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/
> >>
> >> Hence, the creation for that list was asked for and granted:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=212557
> >>
> >> In the end it became [email protected] instead of
> >> [email protected] as 'Linux' is redundant in the latter
> >> case.
> >>
> >> Signed-off-by: Thorsten Leemhuis <[email protected]>
> >> ---
> >> I was a bit unsure how to add that list to MAINTAINERS. I considered
> >> adding a 'M:' with my name and email address there as well, but getting
> >> CCed on a lot of regression reports might be a bit much. I also left a
> >> 'S: supported' out, as that doesn't make much sense in this case afaics;
> >> and I checked, there are other entries that don't have those two (but
> >> it's rare).
> >
> > Put your name there, you are the "maintainer of regressions!" :)
>
> Okay, will do. :-D
>
> /me wonders why he suddenly feels like entering a self-made trap ;-)
>
> > [...]
> >> +REGRESSIONS
> >> +L: [email protected]
> >> +K: regression
> >
> > A bit more information here perhaps? This will not really help anyone
> > out to know what to do.
>
> Did you mean a different headline for the entry? Or would you suggest
> to use a webpage (W:) for that or a Subsystem Profile document (P:)
> here? Using either of the two latter was the plan, but for now I'm a bit
> unsure what to write there except maybe "Thorsten is working on a
> semi-automatic solution for tracking Linux kernel regressions. Details
> will follow. For now report regressions as outlined in
> reporting-issues.rst; but in case you have any problem or think there is
> a regressions not handled appropriately by the maintainers, get him
> involved, he'll try to help".
>
> Or did you have something totally different in mind?
Well, "K: regression" is not a regex, so that's not going to
really help much.
How about something simple like:
KERNEL REGRESSIONS:
M: Thorsten Leemhuis <[email protected]>
L: [email protected]
S: Supported
That looks a bit more like other entries, has a name and a list and a
state of your status for this work.
Would that work?
thanks,
greg k-h
On Wed, Apr 07, 2021 at 01:21:28PM +0200, Thorsten Leemhuis wrote:
>
> On 07.04.21 12:00, Greg KH wrote:
> > On Wed, Apr 07, 2021 at 11:21:56AM +0200, Thorsten Leemhuis wrote:
> >> Make people CC the recently created mailing list dedicated to Linux
> >> kernel regressions when reporting one. Some paragraphs had to be
> >> reshuffled and slightly rewritten during the process, as the text
> >> otherwise would have gotten unnecessarily hard to follow.
> >>
> >> The new text also makes reporters include a line useful for automatic
> >> regression tracking solution which does not exist yet, but is planned.
> >> The term "#regzb" (short for regression bot) is inspired by the "#syz"
> >> which can be used to communicate with syszbot (see
> >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md).
> >
> > While I understand the wish to automate things like this, the #syz
> > marking will actually cause something to go off and do some work, and is
> > only relevant for a very small number of developers, all of whom know to
> > look up the instructions before doing so. But the #regzb marking will
> > be requested to be added by random users who never have submitted a
> > problem report before, OR from long-time kernel developers who are lucky
> > to ever remember to read the documentation as they "know" how to do
> > this.
> >
> > So this increased workload by people on the two ends of experience is
> > going to be rough, I predict a very low rate of adoption :(
>
> Yup, I'm aware of that. And also well aware that I will need to keep an
> eye on things and jump in and reply with mails to add such tags every
> time they are missing.
> But I think that direction it the best shot, as tying putting all the
> burden on one person (me) is likely to fail, as our history with
> regression tracking showed. And I think such tags with some bot in the
> background
> (as outlined roughly in
> https://linux-regtracking.leemhuis.info/post/hello-world/ ) have at
> least the best chance, as things are not out-of-band like tracking them
> in bugzilla would be – or do you think that would be a better approach
> together with its email-interface?
Ok, we can try it, I'm not going to say it's not going to work, just
that it's going to be a marketing effort to tell people how to do this
:)
> > What is the tag going to be good for? The reports will need to be
> > handled by a person anyway and classified and tracked out-of-band from
> > the list somehow. Will a tag do all that much here?
>
> I think is has, as then a good regression report will make the
> still-to-be-written regression-bot create and entry that links to the
> report and send a reply with a unique ID; then that ID needs to end up
> in the commit that fixes the regression later (similar to how the IDs
> for issues found by syzbot are mentioned there, which afaics works quite
> well for people) and the regression-bot can close the entry automatically.
Ah, ok, that makes more sense, nevermind, no objection from me, sorry
for the noise.
thanks,
greg k-h
On 07.04.21 16:56, Greg KH wrote:
> On Wed, Apr 07, 2021 at 12:51:43PM +0200, Thorsten Leemhuis wrote:
>> On 07.04.21 11:56, Greg KH wrote:
>>> On Wed, Apr 07, 2021 at 11:21:55AM +0200, Thorsten Leemhuis wrote:
>>>> Add the newly created regression mailing list finally created after it
> [...]
>>> [...]
>>>> +REGRESSIONS
>>>> +L: [email protected]
>>>> +K: regression
>>>
>>> A bit more information here perhaps? This will not really help anyone
>>> out to know what to do.
>> [...]
>> Or did you have something totally different in mind?
>
> Well, "K: regression" is not a regex,
FWIW, there are a few other entries with a K: like that, for example:
K: riscv
K: regulator_get_optional
And I checked with get_maintainer.pl that the "K: regression" worked
when letting it work on a patch. But that it is a unusual thing to do I
guess, so in the end...
> so that's not going to really help much.
...you are right here afaics.
> How about something simple like:
> KERNEL REGRESSIONS:
> M: Thorsten Leemhuis <[email protected]>
> L: [email protected]
> S: Supported
>
> That looks a bit more like other entries, has a name and a list and a
> state of your status for this work.
>
> Would that work?
Yup, thx for the example, much appreciated.
Ciao, Thorsten
Thorsten Leemhuis <[email protected]> writes:
> +In case you performed a successful bisection, use the title of the change that
> +introduced the regression as the second part of your subject. Make the report
> +also mention the commit id of the culprit. For tracking purposes, add a line
> +like the following that contains both pieces of information, but with the
> +commit id shortened to 12 characters::
> +
> + #regzb introduced: 94a632d91ad1 ("usc: xhbi-foo: check bar_params earlier")
> +
> +In case of an unsuccessful bisection, make your report mention the latest tested
> +version that's working fine (say 5.7) and the oldest where the issue occurs (say
> +5.8-rc1). For tracking purposes add a line expressing it like this::
> +
> + #regzb introduced: v5.7..v5.8-rc1
I kind of share Greg's concern that people aren't going to want to do
this; it could even be seen as an impediment to reporting problems in
general. If you *really* want random users to input this sort of
information, you may well end up creating some sort of web page to step
them through it.
Also, though, as I understand it the system that will interpret these
lines does not yet exist. Experience tells me that, as this system
comes into existence, you will have a good chance of deciding that you
want the syntax to look different anyway. So I would personally hold
off on telling people to include directives like this until you have
something that works with them.
But that's just me... if this is the way it's going to work then the
docs should of course reflect that.
Thanks,
jon
On 08.04.21 19:31, Jonathan Corbet wrote:
> Thorsten Leemhuis <[email protected]> writes:
>
>> +In case you performed a successful bisection, use the title of the change that
>> +introduced the regression as the second part of your subject. Make the report
>> +also mention the commit id of the culprit. For tracking purposes, add a line
>> +like the following that contains both pieces of information, but with the
>> +commit id shortened to 12 characters::
>> +
>> + #regzb introduced: 94a632d91ad1 ("usc: xhbi-foo: check bar_params earlier")
>> +
>> +In case of an unsuccessful bisection, make your report mention the latest tested
>> +version that's working fine (say 5.7) and the oldest where the issue occurs (say
>> +5.8-rc1). For tracking purposes add a line expressing it like this::
>> +
>> + #regzb introduced: v5.7..v5.8-rc1
>
> I kind of share Greg's concern that people aren't going to want to do
> this; [...]
Yeah, I might have done a little too far and should have written it a
bit more relaxed (like "if you want to help, add a tag like this...").
Looking back at it I got a bit bold and went farther then initially
planned due to the ```Make it clear that the list is only for
regressions that people can describe some way, rather than some general
"I have issues with xyz".``` from Linus here:
https://lore.kernel.org/ksummit/CAHk-=wgiYqqLzsb9-UpfH+=ktk7ra-2fOsdc_ZJ7WF47wS73CA@mail.gmail.com/
> [...]
> Also, though, as I understand it the system that will interpret these
> lines does not yet exist. Experience tells me that, as this system
> comes into existence, you will have a good chance of deciding that you
> want the syntax to look different anyway. So I would personally hold
> off on telling people to include directives like this until you have
> something that works with them.
>
> But that's just me... if this is the way it's going to work then the
> docs should of course reflect that.
Yeah, but let's wait how things evolve before adding this then. :-D
FWIW, just sent v2 with the problematic bits dropped and the MAINTAINERS
entry Greg outlined.
Ciao, Thorsten