Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?

[Ingo Molnar]

* Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/