All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.