From: Jiri Kosina <jikos@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Sasha Levin <Alexander.Levin@microsoft.com>,
Pavel Machek <pavel@ucw.cz>, Petr Mladek <pmladek@suse.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Cong Wang <xiyou.wangcong@gmail.com>,
Dave Hansen <dave.hansen@intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
Peter Zijlstra <peterz@infradead.org>, Jan Kara <jack@suse.cz>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Byungchul Park <byungchul.park@lge.com>,
Tejun Heo <tj@kernel.org>, Greg KH <gregkh@linuxfoundation.org>
Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Date: Mon, 16 Apr 2018 22:33:16 +0200 (CEST) [thread overview]
Message-ID: <alpine.LRH.2.00.1804162221320.26111@gjva.wvxbf.pm> (raw)
In-Reply-To: <CA+55aFxiUhaFVBDhrTGJmgKZid2nO0efh6Mng1NQJ0JK4EHqMg@mail.gmail.com>
On Mon, 16 Apr 2018, Linus Torvalds wrote:
> The ones who should matter most for that discussion is the distros,
> since they are the actual users of stable (as well as the people doing
> the work, of course - ie Sasha and Greg and the rest of the stable
> gang).
>
> And I suspect that they actually do want all the noise, and all the
> stuff that isn't "critical". That's often the _easy_ choice. It's the
> stuff that I suspect the stable maintainers go "this I don't even have
> to think about", because it's a new driver ID or something.
So I am a maintainer of SUSE enterprise kernel, and I can tell you I
personally really don't want all the noise, simply because
(a) noone asked us to distribute it (if they did, we would do so)
(b) the risk of regressions
We've always been very cautious about what is coming from stable, and
actually filtering out patches we actively don't want for one reason or
another.
And yes, there is also a history of regressions caused by stable updates
that were painful for us ... I brought this up a multiple times at
ksummit-discuss@ over past years.
So with the upcoming release, we've actually abandonded stable and are
relying more on auto-processing the Fixes: tag.
That is not perfect in both ways (it doesn't cover everything, and we can
miss complex semantical dependencies between patches even though they
"apply"), but we didn't base our decision this time on aligning our
schedule with stable, and so far we don't seem to be suffering. And we
have much better overview / control over what is landing in our enterprise
tree (of course this all is shepherded by machinery around processing
Fixes: tag, which then though has to be *actively* acted upon, depending
on a case-by-case human assessment of how critical it actually is).
> Because the bulk of stable tends to be driver updates, afaik. Which
> distros very much tend to want.
For "community" distros (like Fedora, openSUSE), perhaps, yeah.
For "enterprise" kernels, quite frankly, we much rather get the driver
updates/backports from the respective HW vedndors we're cooperating with,
as they have actually tested and verified the backport on the metal.
> The critical stuff is hopefully a tiny tiny percentage.
But quite frankly, that's the only thing we as distro *really* want -- to
save our users from hitting the critical issues with all the consequences
(data loss, unbootable systems, etc). All the rest we can easily handle on
a reactive basis, which heavily depends on the userbase spectrum (and
that's probably completely different for each -stable tree consumer
anyway).
This is a POV of me as an distro kernel maintainer, but mileage of others
definitely can / will vary of course.
Thanks,
--
Jiri Kosina
SUSE Labs
next prev parent reply other threads:[~2018-04-16 20:34 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180409001936.162706-1-alexander.levin@microsoft.com>
2018-04-09 0:19 ` Sasha Levin
2018-04-09 8:22 ` Petr Mladek
2018-04-15 14:42 ` Sasha Levin
2018-04-16 13:30 ` Steven Rostedt
2018-04-16 15:18 ` Linus Torvalds
2018-04-16 15:30 ` Pavel Machek
2018-04-16 15:50 ` Sasha Levin
2018-04-16 16:06 ` Pavel Machek
2018-04-16 16:14 ` Sasha Levin
2018-04-16 16:22 ` Steven Rostedt
2018-04-16 16:31 ` Sasha Levin
2018-04-16 16:47 ` Steven Rostedt
2018-04-16 16:53 ` Sasha Levin
2018-04-16 17:00 ` Pavel Machek
2018-04-17 10:46 ` Greg KH
2018-04-17 12:24 ` Petr Mladek
2018-04-17 12:49 ` Michal Hocko
2018-04-17 13:39 ` Sasha Levin
2018-04-17 14:22 ` Michal Hocko
2018-04-17 14:36 ` Sasha Levin
2018-04-17 18:10 ` Michal Hocko
2018-04-17 13:45 ` Sasha Levin
2018-04-18 8:33 ` Petr Mladek
2018-04-16 16:28 ` Pavel Machek
2018-04-16 16:39 ` Sasha Levin
2018-04-16 16:42 ` Pavel Machek
2018-04-16 16:45 ` Sasha Levin
2018-04-16 16:54 ` Pavel Machek
2018-04-17 10:50 ` Greg KH
2018-04-16 17:05 ` Pavel Machek
2018-04-16 17:16 ` Sasha Levin
2018-04-16 17:44 ` Steven Rostedt
2018-04-16 18:17 ` Sasha Levin
2018-04-16 18:35 ` Steven Rostedt
2018-04-16 20:17 ` Jiri Kosina
2018-04-16 20:36 ` Sasha Levin
2018-04-16 20:43 ` Jiri Kosina
2018-04-16 21:18 ` Sasha Levin
2018-04-16 21:28 ` Jiri Kosina
2018-04-17 10:39 ` Greg KH
2018-04-17 11:07 ` Michal Hocko
2018-04-17 14:04 ` Sasha Levin
2018-04-17 14:15 ` Steven Rostedt
2018-04-17 14:36 ` Greg KH
2018-04-17 14:36 ` Michal Hocko
2018-04-17 14:55 ` Sasha Levin
2018-04-17 15:52 ` Jiri Kosina
2018-04-17 16:06 ` Sasha Levin
2018-05-03 10:04 ` Pavel Machek
2018-05-03 13:02 ` Sasha Levin
2018-04-17 16:25 ` Mike Galbraith
2018-04-17 11:21 ` Jiri Kosina
2018-05-03 9:47 ` Pavel Machek
2018-05-03 13:06 ` Sasha Levin
2018-04-16 16:20 ` Steven Rostedt
2018-04-16 16:28 ` Sasha Levin
2018-04-16 16:39 ` Pavel Machek
2018-04-16 16:43 ` Sasha Levin
2018-04-16 16:53 ` Steven Rostedt
2018-04-16 16:58 ` Pavel Machek
2018-04-16 17:09 ` Sasha Levin
2018-04-16 17:33 ` Steven Rostedt
2018-04-16 17:42 ` Sasha Levin
2018-04-16 18:26 ` Steven Rostedt
2018-04-16 18:30 ` Linus Torvalds
2018-04-16 18:41 ` Steven Rostedt
2018-04-16 18:52 ` Linus Torvalds
2018-04-16 19:00 ` Linus Torvalds
2018-04-16 19:30 ` Steven Rostedt
2018-04-16 19:19 ` Linus Torvalds
2018-04-16 19:24 ` Steven Rostedt
2018-04-16 19:28 ` Linus Torvalds
2018-04-16 19:31 ` Linus Torvalds
2018-04-16 19:58 ` Steven Rostedt
2018-04-16 19:38 ` Steven Rostedt
2018-04-16 19:55 ` Linus Torvalds
2018-04-16 20:02 ` Steven Rostedt
2018-04-16 20:17 ` Linus Torvalds
2018-04-16 20:33 ` Jiri Kosina [this message]
2018-04-16 21:27 ` Steven Rostedt
2018-04-16 18:35 ` Sasha Levin
2018-04-16 18:57 ` Steven Rostedt
2018-04-16 15:36 ` Steven Rostedt
2018-04-16 16:02 ` Sasha Levin
2018-04-16 16:10 ` Pavel Machek
2018-04-16 16:12 ` Steven Rostedt
2018-04-16 16:19 ` Sasha Levin
2018-04-16 16:30 ` Steven Rostedt
2018-04-16 16:37 ` Sasha Levin
2018-04-16 17:06 ` Pavel Machek
2018-04-16 17:23 ` Sasha Levin
2018-04-17 11:41 ` Jan Kara
2018-04-17 13:31 ` Sasha Levin
2018-04-17 15:55 ` Jan Kara
2018-04-17 16:19 ` Sasha Levin
2018-04-17 17:57 ` Jan Kara
2018-04-17 18:28 ` Sasha Levin
2018-05-03 9:36 ` Pavel Machek
2018-05-03 13:28 ` Sasha Levin
2018-05-03 9:32 ` Pavel Machek
2018-05-03 13:30 ` Sasha Levin
2018-04-19 11:41 ` Thomas Backlund
2018-04-19 13:59 ` Greg KH
2018-04-19 14:05 ` Jan Kara
2018-04-19 14:22 ` Greg KH
2018-04-19 15:16 ` Thomas Backlund
2018-04-19 15:57 ` Greg KH
2018-04-19 16:25 ` Thomas Backlund
2018-04-19 16:41 ` Greg KH
2018-04-19 15:04 ` Thomas Backlund
2018-04-19 15:09 ` Sasha Levin
2018-04-19 16:20 ` Thomas Backlund
2018-04-16 15:39 ` 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=alpine.LRH.2.00.1804162221320.26111@gjva.wvxbf.pm \
--to=jikos@kernel.org \
--cc=Alexander.Levin@microsoft.com \
--cc=akpm@linux-foundation.org \
--cc=byungchul.park@lge.com \
--cc=dave.hansen@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=pavel@ucw.cz \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=xiyou.wangcong@gmail.com \
/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