From: Sasha Levin <sashal@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] stable kernel process automation and improvement
Date: Fri, 5 Jul 2019 16:12:31 -0400 [thread overview]
Message-ID: <20190705201231.GI10104@sasha-vm> (raw)
In-Reply-To: <20190705164142.GC20625@sirena.org.uk>
On Fri, Jul 05, 2019 at 05:41:42PM +0100, Mark Brown wrote:
>On Tue, Jul 02, 2019 at 09:35:57PM -0400, Sasha Levin wrote:
>
>> - Concerns about how well -stable kernels are tested.
>> - "Fixes for fixes" end up being missed.
>> - Saner AUTOSEL process.
>
>I'm a bit worried about these, especially pushed together - one
>of the things the AUTOSEL stuff does quite often is pull in
>driver changes and our coverage of drivers is especially weak.
Our driver coverage is indeed weak, but I don't think that the solution
is to leave drivers/ alone. On the contrary, I think that making
drivers/ move quickly together with the rest of the kernel will
encourage vendors to up their testing game.
This came up in the last MS, and the agreement there was that we expect
stable kernel users to test their workloads before throwing it into
production.
If we were to start avoiding driver updates, it would act as an
incentive for people not to upgrade their kernel.
Right now I'm working with a certain hardware vendor who does a crappy
job at tagging fixes for stable, and it's horribly painful. I end up
spending time triaging a bug, reporting it to the vendor, only to be
told "oh grab this fix from upstream".
This user experience is just bad, and I can't imagine how difficult it
is for users who are less familiar with the kerenl.
--
Thanks,
Sasha
next prev parent reply other threads:[~2019-07-05 20:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 1:35 Sasha Levin
2019-07-03 14:57 ` Laura Abbott
2019-07-05 13:54 ` Michael Ellerman
2019-07-05 14:13 ` Takashi Iwai
2019-07-05 16:17 ` Greg KH
2019-07-05 16:52 ` Sasha Levin
2019-07-05 16:41 ` Mark Brown
2019-07-05 20:12 ` Sasha Levin [this message]
2019-07-06 0:32 ` Mark Brown
2019-07-08 11:02 ` Sasha Levin
2019-07-08 11:35 ` Jiri Kosina
2019-07-08 12:34 ` Greg KH
2019-07-08 17:56 ` Sasha Levin
2019-07-08 12:37 ` Mark Brown
2019-07-08 14:05 ` Guenter Roeck
2019-07-08 14:33 ` Takashi Iwai
2019-07-08 15:10 ` Greg KH
2019-07-08 15:18 ` Takashi Iwai
2019-07-08 18:08 ` Sasha Levin
2019-07-08 21:31 ` Jiri Kosina
2019-07-09 15:44 ` Rafael J. Wysocki
2019-07-09 21:05 ` Takashi Iwai
2019-07-09 15:21 ` Laura Abbott
2019-07-08 14:50 ` Mark Brown
2019-07-08 15:06 ` Greg KH
2019-07-08 15:27 ` Mark Brown
2019-07-08 18:01 ` Sasha Levin
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=20190705201231.GI10104@sasha-vm \
--to=sashal@kernel.org \
--cc=broonie@kernel.org \
--cc=ksummit-discuss@lists.linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox