From: Greg KH <gregkh@linuxfoundation.org>
To: Jiri Kosina <jikos@kernel.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time
Date: Wed, 5 Sep 2018 10:56:42 +0200 [thread overview]
Message-ID: <20180905085642.GA29931@kroah.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1809051029400.15880@cbobk.fhfr.pm>
On Wed, Sep 05, 2018 at 10:32:45AM +0200, Jiri Kosina wrote:
> But yeah, it's weak and doesn't solve the primary thing, which is just the
> size of stable itself.
I've held off on responding so far, but I think this is the big point of
"fear" that many people seem to have with the stable updates over the
past years.
Yes, the "size" is bigger than before, but that is because of the
following things:
- our development process is going faster (9 patches an hour)
than it used to a few years ago.
- We have finally woken some subsystem maintainers up into
actually properly tagging patches for stable. We used to have
a horrid rate of this happening, and it is getting better.
However, we still have whole major subsystems that _never_ tag
anything, which is a problem, so things will get larger.
- I have more time to work on this than when I used to work for
a distro.
- The "Fixes:" tag has helped out a lot in finding patches that
people forgot to tag with stable@ lines.
- We have more people using and caring about stable kernels, so
they submit more patches for them, allowing them to replace
their internal trees
- Sasha's work in finding the patches that maintainers/developer
fail to tag is paying off really well, which also increases
the size.
- fuzzing tools are finding loads of stuff that have always been
there. syzbot is wonderful in this, and still has many
hundreds of open bugs left to be fixed. When they are fixed,
those patches will be backported. This means we are getting
better at finding and fixing things, not that the bugs were
not ever there in the first place.
So yes, things are "bigger" than before, but still, overall, we are only
accepting a small percentage of patches that hit Linus's tree (12
patches a day for stable vs. 216 a day for Linus).
Are you also worried that Linus's tree is getting "bigger"? :)
So we are larger than before, but this is a good thing, because we are
actually catching more problems than we were before. Which means your
older kernels had more bugs...
Anyway, just a comment in that you should not "fear" the increased size,
it is to be expected as more people pay more attention to Linux,
combined with the fact that we are still growing. If the stable patches
were shrinking, then I would get worried as that would imply that people
don't care anymore.
thanks,
greg k-h
next prev parent reply other threads:[~2018-09-05 8:56 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-04 20:58 Laura Abbott
2018-09-04 21:12 ` Jiri Kosina
2018-09-05 14:31 ` Greg KH
2018-09-04 21:22 ` Justin Forbes
2018-09-05 14:42 ` Greg KH
2018-09-05 15:10 ` Mark Brown
2018-09-05 15:10 ` Sasha Levin
2018-09-05 16:19 ` Guenter Roeck
2018-09-05 18:31 ` Laura Abbott
2018-09-05 21:23 ` Justin Forbes
2018-09-06 2:17 ` Eduardo Valentin
2018-09-04 21:33 ` Sasha Levin
2018-09-04 21:55 ` Guenter Roeck
2018-09-04 22:03 ` Laura Abbott
2018-09-04 23:14 ` Sasha Levin
2018-09-04 23:43 ` Guenter Roeck
2018-09-05 1:17 ` Laura Abbott
2018-09-06 3:56 ` Benjamin Gilbert
2018-09-04 21:58 ` Laura Abbott
2018-09-05 4:53 ` Sasha Levin
2018-09-05 6:48 ` Jiri Kosina
2018-09-05 8:16 ` Jan Kara
2018-09-05 8:32 ` Jiri Kosina
2018-09-05 8:56 ` Greg KH [this message]
2018-09-05 9:13 ` Geert Uytterhoeven
2018-09-05 9:33 ` Greg KH
2018-09-05 10:11 ` Mark Brown
2018-09-05 14:44 ` Steven Rostedt
2018-09-05 9:58 ` James Bottomley
2018-09-05 10:47 ` Mark Brown
2018-09-05 12:24 ` James Bottomley
2018-09-05 12:53 ` Jiri Kosina
2018-09-05 13:05 ` Greg KH
2018-09-05 13:15 ` Jiri Kosina
2018-09-05 14:00 ` Greg KH
2018-09-05 14:06 ` Sasha Levin
2018-09-05 21:02 ` Jiri Kosina
2018-09-05 16:39 ` James Bottomley
2018-09-05 17:06 ` Dmitry Torokhov
2018-09-05 17:33 ` Steven Rostedt
2018-09-05 13:03 ` Takashi Iwai
2018-09-05 13:27 ` Daniel Vetter
2018-09-05 14:05 ` Greg KH
2018-09-05 15:54 ` Daniel Vetter
2018-09-05 16:19 ` Sasha Levin
2018-09-05 16:26 ` Daniel Vetter
2018-09-05 19:09 ` Sasha Levin
2018-09-05 20:18 ` Sasha Levin
2018-09-05 20:33 ` Daniel Vetter
2018-09-05 14:20 ` Sasha Levin
2018-09-05 14:30 ` Takashi Iwai
2018-09-05 14:41 ` Sasha Levin
2018-09-05 14:46 ` Takashi Iwai
2018-09-05 14:54 ` Sasha Levin
2018-09-05 15:12 ` Takashi Iwai
2018-09-05 15:19 ` Thomas Gleixner
2018-09-05 15:29 ` Sasha Levin
2018-09-05 13:16 ` Mark Brown
2018-09-05 14:27 ` Sasha Levin
2018-09-05 14:50 ` Mark Brown
2018-09-05 15:00 ` Sasha Levin
2018-09-05 10:28 ` Thomas Gleixner
2018-09-05 11:20 ` Jiri Kosina
2018-09-05 14:41 ` Thomas Gleixner
2018-09-05 15:18 ` Steven Rostedt
2018-09-06 8:48 ` Thomas Gleixner
2018-09-06 12:47 ` Thomas Gleixner
2018-09-04 21:49 ` Guenter Roeck
2018-09-04 22:06 ` Laura Abbott
2018-09-04 23:35 ` Guenter Roeck
2018-09-05 1:45 ` Laura Abbott
2018-09-05 2:54 ` Guenter Roeck
2018-09-05 8:31 ` Jan Kara
2018-09-05 3:44 ` Eduardo Valentin
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=20180905085642.GA29931@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jikos@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