* Greg KH <gre...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
