From: Thorsten Leemhuis <linux@leemhuis.info> To: Theodore Ts'o <tytso@mit.edu> Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>, Greg KH <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, workflows@vger.kernel.org, Konstantin Ryabitsev <konstantin@linuxfoundation.org> Subject: Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions Date: Tue, 23 Mar 2021 09:57:57 +0100 [thread overview] Message-ID: <54aeb1f7-ffc7-74e1-a731-8970d44ff852@leemhuis.info> (raw) In-Reply-To: <YFkSqIN90S4a3HiF@mit.edu> On 22.03.21 22:56, Theodore Ts'o wrote: > On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote: >> I agree to the last point and yeah, maybe regressions are the more >> important problem we should work on – at least from the perspective of >> kernel development. But from the users perspective (and >> reporting-issues.rst is written for that perspective) it feel a bit >> unsatisfying to not have a solution to query for existing report, >> regressions or not. Hmmmm... > First of all, thanks for working on reporting-issues.rst. Thx, very glad to hear that. I didn't get much feedback on it, which made me wonder if anybody besides docs folks actually looked at it... > If we can > actually get users to *read* it, I think it's going to save kernel > developers a huge amount of time and frustration. And users hopefully as well. But yes, making them read it is the problem. :-/ > I wonder if it might be useful to have a form which users could be > encouraged to fill out so that (a) the information is available in a > structured format so it's easier for developers to find the relevant > information, (b) so it is easier for programs to parse, for easier > reporting or indexing, and (c) as a nudge so that users remember to > report critical bits of information such as the hardware > configuration, the exact kernel version, which distribution userspace > was in use, etc. > > There could also be something in the text form which would make it > easier for lore.kernel.org searches to identify bug reports. (e.g., > "LINUX KERNEL BUG REPORTER TEMPLATE") Hmmm, yeah, I like that idea. I'll keep it in mind for later: I would prefer to get reporting-issues.rst officially blessed and reporting-bugs.rst gone before working on further enhancements. Maybe the best idea would be to have a script and/or webpage that helps people creating the proper text form (which they then could simply copy-and-paste into their mailer). I had such a script/webpage in mind already to help with one of the IMHO biggest pain points when it comes to reporting issues: finding where the report needs to go, as decoding MAINTAINERS requires that you have a at least a vague idea which component might be causing the issue – which afaics is hard even for people that known a thing or two about the kernel. :-/ Ciao, Thorsten _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
WARNING: multiple messages have this Message-ID (diff)
From: Thorsten Leemhuis <linux@leemhuis.info> To: Theodore Ts'o <tytso@mit.edu> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Greg KH <gregkh@linuxfoundation.org>, workflows@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, ksummit <ksummit-discuss@lists.linuxfoundation.org> Subject: Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions Date: Tue, 23 Mar 2021 09:57:57 +0100 [thread overview] Message-ID: <54aeb1f7-ffc7-74e1-a731-8970d44ff852@leemhuis.info> (raw) In-Reply-To: <YFkSqIN90S4a3HiF@mit.edu> On 22.03.21 22:56, Theodore Ts'o wrote: > On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote: >> I agree to the last point and yeah, maybe regressions are the more >> important problem we should work on – at least from the perspective of >> kernel development. But from the users perspective (and >> reporting-issues.rst is written for that perspective) it feel a bit >> unsatisfying to not have a solution to query for existing report, >> regressions or not. Hmmmm... > First of all, thanks for working on reporting-issues.rst. Thx, very glad to hear that. I didn't get much feedback on it, which made me wonder if anybody besides docs folks actually looked at it... > If we can > actually get users to *read* it, I think it's going to save kernel > developers a huge amount of time and frustration. And users hopefully as well. But yes, making them read it is the problem. :-/ > I wonder if it might be useful to have a form which users could be > encouraged to fill out so that (a) the information is available in a > structured format so it's easier for developers to find the relevant > information, (b) so it is easier for programs to parse, for easier > reporting or indexing, and (c) as a nudge so that users remember to > report critical bits of information such as the hardware > configuration, the exact kernel version, which distribution userspace > was in use, etc. > > There could also be something in the text form which would make it > easier for lore.kernel.org searches to identify bug reports. (e.g., > "LINUX KERNEL BUG REPORTER TEMPLATE") Hmmm, yeah, I like that idea. I'll keep it in mind for later: I would prefer to get reporting-issues.rst officially blessed and reporting-bugs.rst gone before working on further enhancements. Maybe the best idea would be to have a script and/or webpage that helps people creating the proper text form (which they then could simply copy-and-paste into their mailer). I had such a script/webpage in mind already to help with one of the IMHO biggest pain points when it comes to reporting issues: finding where the report needs to go, as decoding MAINTAINERS requires that you have a at least a vague idea which component might be causing the issue – which afaics is hard even for people that known a thing or two about the kernel. :-/ Ciao, Thorsten
next prev parent reply other threads:[~2021-03-23 8:58 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-22 15:18 RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions Thorsten Leemhuis 2021-03-22 15:18 ` [Ksummit-discuss] " Thorsten Leemhuis 2021-03-22 16:55 ` Lukas Bulwahn 2021-03-22 16:55 ` Lukas Bulwahn 2021-03-22 19:49 ` Thorsten Leemhuis 2021-03-22 19:49 ` Thorsten Leemhuis 2021-03-22 17:16 ` Konstantin Ryabitsev 2021-03-22 17:16 ` [Ksummit-discuss] " Konstantin Ryabitsev 2021-03-22 17:57 ` James Bottomley 2021-03-22 17:57 ` James Bottomley 2021-03-22 18:34 ` Eric Wong 2021-03-22 18:34 ` [Ksummit-discuss] " Eric Wong 2021-03-22 18:55 ` Thorsten Leemhuis 2021-03-22 18:55 ` [Ksummit-discuss] " Thorsten Leemhuis 2021-03-22 19:20 ` Konstantin Ryabitsev 2021-03-22 19:20 ` [Ksummit-discuss] " Konstantin Ryabitsev 2021-03-22 18:32 ` Linus Torvalds 2021-03-22 18:32 ` Linus Torvalds 2021-03-22 19:25 ` Thorsten Leemhuis 2021-03-22 19:25 ` [Ksummit-discuss] " Thorsten Leemhuis 2021-03-22 21:56 ` Theodore Ts'o 2021-03-22 21:56 ` Theodore Ts'o 2021-03-23 8:57 ` Thorsten Leemhuis [this message] 2021-03-23 8:57 ` Thorsten Leemhuis 2021-03-23 15:01 ` Konstantin Ryabitsev 2021-03-23 15:01 ` Konstantin Ryabitsev 2021-03-23 19:09 ` Thorsten Leemhuis 2021-03-23 19:09 ` Thorsten Leemhuis 2021-03-23 18:11 ` Theodore Ts'o 2021-03-23 18:11 ` Theodore Ts'o 2021-03-23 18:51 ` Thorsten Leemhuis 2021-03-23 18:51 ` Thorsten Leemhuis 2021-03-23 14:57 ` Luis Chamberlain 2021-03-23 14:57 ` Luis Chamberlain 2021-03-23 16:20 ` Steven Rostedt 2021-03-23 16:20 ` Steven Rostedt 2021-03-23 16:30 ` [Ksummit-discuss] " James Bottomley 2021-03-23 16:30 ` James Bottomley 2021-03-23 21:43 ` Konstantin Ryabitsev 2021-03-23 21:43 ` Konstantin Ryabitsev 2021-03-23 23:11 ` Eric Wong 2021-03-23 23:11 ` Eric Wong 2021-03-23 18:07 ` Theodore Ts'o 2021-03-23 18:07 ` Theodore Ts'o
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=54aeb1f7-ffc7-74e1-a731-8970d44ff852@leemhuis.info \ --to=linux@leemhuis.info \ --cc=gregkh@linuxfoundation.org \ --cc=konstantin@linuxfoundation.org \ --cc=ksummit-discuss@lists.linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=tytso@mit.edu \ --cc=workflows@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.