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 19:51:05 +0100 [thread overview] Message-ID: <5a26cdba-eff9-8a5c-fda1-3f8d14b49868@leemhuis.info> (raw) In-Reply-To: <YFovanxCgq1lF4Ah@mit.edu> On 23.03.21 19:11, Theodore Ts'o wrote: > On Tue, Mar 23, 2021 at 09:57:57AM +0100, Thorsten Leemhuis wrote: >> 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... > I'll admit that I had missed your initial submission, No wonder with all the lists and mails. :-D That's actually why I wanted to point to the text on ksummit-list once in the near future after two remaining issues with the text were solved (see below), but before removing the "WIP" box at the top and deleting reporting-bugs.rst. > but having > looked at it, while I could imagine some nits where it could be > improved, Yeah, for sure, with such a text that will always be the case. And I really would like if a few more people take a closer look and provide feedback, that really helps to get such a text in shape. I have stared so much at the text in recent months, that makes it quite easy to miss typos and errors in the logical flow that a fresh pair of eyes will immediately spot... > in my opinion, it's strictly better than the older > reporting-bugs doc. Great, thx. >> 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. > Is there anyone following this thread who believes that there is > anything we should change *before* oficially blessing > reporting-issues.rst? Given that Konstantin has already linked to > reporting-issues from the front page of kernel.bugzilla.org, I think > we we should just go ahead and officially bless it and be done with > it. :-) FWIW, here is my current todo list from the top of my head: * get this patchset reviewed and applied: https://lore.kernel.org/linux-doc/cover.1616181657.git.linux@leemhuis.info/ * *afterwards* make sure Greg and/or Sasha (now CCed) check the text from their point of view (above patchset changes quite a few things in that area, that's why it needs to be applied first) * get feedback reg. the two FIXME boxes remaining afterwards. One is about bugzilla (```The old text took a totally different approach to bugzilla.kernel.org...```), the other about CCing LKML (```Above section tells users to always CC LKML […] Should we create mailing list like linux-issues@vger.kernel.org```). But I guess the approach taken should be fine for most people, so we could simply remove them. We can still change things later anyway, I just put those boxes there to highlight these differences to the old approach. * remove the note at the top (```This document is being prepared to replace 'Reporting bugs...``` and delete reporting-bugs.rst > Once it is blessed, I'd also suggest putting a link to > https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html > as an "other resources" at https://www.kernel.org. +1 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>, Sasha Levin <sashal@kernel.org> Subject: Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions Date: Tue, 23 Mar 2021 19:51:05 +0100 [thread overview] Message-ID: <5a26cdba-eff9-8a5c-fda1-3f8d14b49868@leemhuis.info> (raw) In-Reply-To: <YFovanxCgq1lF4Ah@mit.edu> On 23.03.21 19:11, Theodore Ts'o wrote: > On Tue, Mar 23, 2021 at 09:57:57AM +0100, Thorsten Leemhuis wrote: >> 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... > I'll admit that I had missed your initial submission, No wonder with all the lists and mails. :-D That's actually why I wanted to point to the text on ksummit-list once in the near future after two remaining issues with the text were solved (see below), but before removing the "WIP" box at the top and deleting reporting-bugs.rst. > but having > looked at it, while I could imagine some nits where it could be > improved, Yeah, for sure, with such a text that will always be the case. And I really would like if a few more people take a closer look and provide feedback, that really helps to get such a text in shape. I have stared so much at the text in recent months, that makes it quite easy to miss typos and errors in the logical flow that a fresh pair of eyes will immediately spot... > in my opinion, it's strictly better than the older > reporting-bugs doc. Great, thx. >> 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. > Is there anyone following this thread who believes that there is > anything we should change *before* oficially blessing > reporting-issues.rst? Given that Konstantin has already linked to > reporting-issues from the front page of kernel.bugzilla.org, I think > we we should just go ahead and officially bless it and be done with > it. :-) FWIW, here is my current todo list from the top of my head: * get this patchset reviewed and applied: https://lore.kernel.org/linux-doc/cover.1616181657.git.linux@leemhuis.info/ * *afterwards* make sure Greg and/or Sasha (now CCed) check the text from their point of view (above patchset changes quite a few things in that area, that's why it needs to be applied first) * get feedback reg. the two FIXME boxes remaining afterwards. One is about bugzilla (```The old text took a totally different approach to bugzilla.kernel.org...```), the other about CCing LKML (```Above section tells users to always CC LKML […] Should we create mailing list like linux-issues@vger.kernel.org```). But I guess the approach taken should be fine for most people, so we could simply remove them. We can still change things later anyway, I just put those boxes there to highlight these differences to the old approach. * remove the note at the top (```This document is being prepared to replace 'Reporting bugs...``` and delete reporting-bugs.rst > Once it is blessed, I'd also suggest putting a link to > https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html > as an "other resources" at https://www.kernel.org. +1 Ciao, Thorsten
next prev parent reply other threads:[~2021-03-23 18:51 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 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 [this message] 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=5a26cdba-eff9-8a5c-fda1-3f8d14b49868@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.