All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	Thorsten Leemhuis <linux@leemhuis.info>
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:30:33 -0700	[thread overview]
Message-ID: <72f1c67bc8ad21bb1e5a7d77b88e2c3e50065e3b.camel@HansenPartnership.com> (raw)
In-Reply-To: <20210323122025.77888b49@gandalf.local.home>

On Tue, 2021-03-23 at 12:20 -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 like the "linux-regressions" mailing list idea.

Can't we use the fancy features of public inbox to get the best of both
worlds?  Have the bug list (or even a collection of lists) but make the
linux-regressions one a virtual list keying off an imap flag which a
group of people control.  That way anything that is flagged as a
regression appears in that public inbox.  I assume the search can be
quite wide so we could flag a regression on any list indexed by lore?

James



WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	Thorsten Leemhuis <linux@leemhuis.info>
Cc: 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:30:33 -0700	[thread overview]
Message-ID: <72f1c67bc8ad21bb1e5a7d77b88e2c3e50065e3b.camel@HansenPartnership.com> (raw)
In-Reply-To: <20210323122025.77888b49@gandalf.local.home>

On Tue, 2021-03-23 at 12:20 -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 like the "linux-regressions" mailing list idea.

Can't we use the fancy features of public inbox to get the best of both
worlds?  Have the bug list (or even a collection of lists) but make the
linux-regressions one a virtual list keying off an imap flag which a
group of people control.  That way anything that is flagged as a
regression appears in that public inbox.  I assume the search can be
quite wide so we could flag a regression on any list indexed by lore?

James


_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

  reply	other threads:[~2021-03-23 16:31 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       ` James Bottomley [this message]
2021-03-23 16:30         ` [Ksummit-discuss] " 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=72f1c67bc8ad21bb1e5a7d77b88e2c3e50065e3b.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --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.