All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Thorsten Leemhuis <linux@leemhuis.info>,
	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 14:07:27 -0400	[thread overview]
Message-ID: <YFouX8vspDCFcBXT@mit.edu> (raw)
In-Reply-To: <20210323122025.77888b49@gandalf.local.home>

On Tue, Mar 23, 2021 at 12:20:25PM -0400, Steven Rostedt wrote:
> On Mon, 22 Mar 2021 20:25:15 +0100
> Thorsten Leemhuis <linux@leemhuis.info> 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...
> 
> I think the bulk of user issues are going to be regressions. Although you
> may be in a better position to know for sure, but at least for me, wearing
> my "user" hat, the thing that gets me the most is upgrading to a new kernel
> and suddenly something that use to work no longer does. And that is the
> definition of a regression. My test boxes still run old distros (one is
> running fedora 13). These are the boxes that catch the most issues, and if
> they do, they are pretty much guaranteed to be a regression.

I think it depends on the user and the subsystem.  You're a
sophisticated user, but I've fielded a goodly number of ext4 "bug
reports" which were coming from a Ubuntu 16.04 kernel, or a user who
is seeing a block device issue (either a driver bug or a hardware
failure), or in some cases both.

A lot of these "bug reports" would be headed off at the pass if we
advertised:

https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

much more heavily; assuming we can get the users to actually read it,
first.

						- Ted
_______________________________________________
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: "Theodore Ts'o" <tytso@mit.edu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Thorsten Leemhuis <linux@leemhuis.info>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	workflows@vger.kernel.org,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: Re: RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions
Date: Tue, 23 Mar 2021 14:07:27 -0400	[thread overview]
Message-ID: <YFouX8vspDCFcBXT@mit.edu> (raw)
In-Reply-To: <20210323122025.77888b49@gandalf.local.home>

On Tue, Mar 23, 2021 at 12:20:25PM -0400, Steven Rostedt wrote:
> On Mon, 22 Mar 2021 20:25:15 +0100
> Thorsten Leemhuis <linux@leemhuis.info> 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...
> 
> I think the bulk of user issues are going to be regressions. Although you
> may be in a better position to know for sure, but at least for me, wearing
> my "user" hat, the thing that gets me the most is upgrading to a new kernel
> and suddenly something that use to work no longer does. And that is the
> definition of a regression. My test boxes still run old distros (one is
> running fedora 13). These are the boxes that catch the most issues, and if
> they do, they are pretty much guaranteed to be a regression.

I think it depends on the user and the subsystem.  You're a
sophisticated user, but I've fielded a goodly number of ext4 "bug
reports" which were coming from a Ubuntu 16.04 kernel, or a user who
is seeing a block device issue (either a driver bug or a hardware
failure), or in some cases both.

A lot of these "bug reports" would be headed off at the pass if we
advertised:

https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

much more heavily; assuming we can get the users to actually read it,
first.

						- Ted

  parent reply	other threads:[~2021-03-23 18:08 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
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 [this message]
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=YFouX8vspDCFcBXT@mit.edu \
    --to=tytso@mit.edu \
    --cc=gregkh@linuxfoundation.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=rostedt@goodmis.org \
    --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.