From: Ingo Molnar <mingo@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
Date: Thu, 7 Nov 2013 10:01:00 +0100 [thread overview]
Message-ID: <20131107090100.GA403@gmail.com> (raw)
In-Reply-To: <20131107044052.GA11459@kroah.com>
* Greg KH <gregkh@linuxfoundation.org> wrote:
> > Thirdly, _users_ interested in stability can already go to the -stable
> > kernel, will will suck up 1 cycle worth of bugfixes out of the main
> > flow of changes. So users already have a stability choice of v-latest
> > and 'v-latest - 1' - plus the 'long term' stable kernels as well.
>
> I think (but I'm probably biased here), that the -stable releases are
> doing this pretty well. [...]
I do think it's pretty healthy. (I just have no idea how you manage the
firehose of patches! :-)
The biggest weak spot I see is the lack of unbiased kernel stability
metrics. bugzillas are self-selecting and suffer from the squeakiest whell
problem. Distros are conservative and under-staffed, so there's
significant lag there.
What would help a lot would be the revival of kerneloops.org.
Would people object to a mainline kernel opt-in kernel crash reporting
feature that would send a single UDP packet to a special port on
kernel.org on a kernel crash, sending a crash signature, a backtrace, a
kernel version string or so, a /dev/random generated system UUID, etc.?
A _lot_ of useful information can be squeezed into a 1.4k packet, and the
format would obviously be human readable but space-optimized.
The upstream kernel crash reporting feature is off by default but distros
could turn it on and would allow users to opt-in via a nice GUI question
on install or first-bootup. (It would also be a fundamentally distro
neutral reporting facility, with immediate, very quick feedback to kernel
developers.)
[ This crash reporting facility would utilize the netconsole
infrastructure to be able to send the crash-report packet from deep
inside just about any kernel context, and and would thus work better
than current oops gathering methods that all rely on user-space still
functioning when the crash happens. Users could query the crashes
reported for their UUIDs on kernel.org and could provide further
feedback if they want to. ]
> > Maybe ask first-hop maintainers to be extra super diligent about new
> > features in v4.0 by imposing an internal merge window deadline 2 weeks
> > before the real merge window [a fair chunk of patches hit maintainer
> > trees in the last 2 weeks of the development window, and those cause
> > much of the regressions], maybe even reject a few pulls during the
> > merge window that blatantly violate these pre-freeze rules, but don't
> > hold up the low-latency flow of steady improvements - much of which is
> > driver work, platform enablement work, small improvements, etc., which
> > isn't really a big source of real regressions for the existing
> > installed base.
>
> A 2 week merge window deadline would help out a lot with a number of
> some of the bugs we get during the -rc cycle, but there's always going
> to be issues found with wider testing, so I'm not quite sure that will
> help out all that much in the end.
I think we already had such a change in the recent past: Linus started
enforcing "no development during the merge window!" in ernest.
That step, combined with linux-next testing, made the merge window a _lot_
less painful over the last 1-2 years, eliminating much of the risk that
comes with pushing well intentioned but barely tested bits upstream.
So you are probably right that extending that by 1-2 weeks would probably
bring diminishing returns, because the "no development during the merge
window" policy already eliminates the worst offenders.
Thanks,
Ingo
next prev parent reply other threads:[~2013-11-07 9:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 0:10 Linux 3.12 released .. and no merge window yet .. and 4.0 plans? Linus Torvalds
2013-11-04 3:11 ` Tony Luck
2013-11-04 6:25 ` Ingo Molnar
2013-11-04 19:08 ` Josh Boyer
2013-11-04 19:53 ` Geert Uytterhoeven
2013-11-07 4:40 ` Greg KH
2013-11-07 9:01 ` Ingo Molnar [this message]
2013-11-04 17:00 ` Alexander Holler
2013-11-04 19:49 ` Geert Uytterhoeven
2013-11-04 20:16 ` Alexander Holler
2013-11-04 23:02 ` Alexander Holler
2013-11-06 13:42 ` Keith Curtis
2013-11-07 10:17 ` Alexander Holler
2013-11-15 1:11 ` Keith Curtis
2013-11-04 20:05 ` Olof Johansson
2013-11-04 20:12 ` Hans de Bruin
2013-11-04 21:46 ` Linux 3.12 released " Jan Engelhardt
2013-11-05 5:06 ` Aldo Iljazi
2013-11-05 5:08 ` Alexander Holler
2013-11-04 21:57 ` Linux 3.12 released .. and no merge window yet " One Thousand Gnomes
2013-11-10 4:13 ` Alexandre Oliva
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=20131107090100.GA403@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).