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

Ingo Molnar
2013-11-04T06:25:45Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> So I may be pessimistic, but I'd expect many developers would go "Let's
> hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after
> all instead. Or just take that release off.
>
> But I do wonder.. Maybe it would be possible, and I'm just unfairly
> projecting my own inner squirrel onto other kernel developers. If we
> have enough heads-up that people *know* that for one release (and
> companies/managers know that too) the only patches that get accepted are
> the kind that fix bugs, maybe people really would have sufficient
> attention span that it could work.
>
> And the reason I mention "4.0" is that it would be a lovely time to do
> that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're
> doing a release with *just* fixes, and then that becomes 4.0".
>
> Comments?

I think the biggest problem wouldn't even be the enforcement of
bugfixes-only during that 2.5 months period, or kernel developers
surviving such a long streak of boredom, but v3.19 would also probably be
a super-stressful release to maintainers, as everyone would try to cram
their feature in there. And if anything important misses that window then
it's a +5 months wait...

The other problem is that kernel developers who do development typically
fix their own bugs within a week or two. It's not developers that
typically determine the stability of a subsystem but _maintainers_, and
the primary method of stabilization is, beyond being careful when merging
a patch, is to remember/monitor breakages and not merge new feature
patches from a developer until fixable bugs are fixed by the developer.

Bugs that go on longer are usually the bugs developers cannot reproduce,
the ones where the timing and progress depends on other, external people.
For example the NUMA fixes in v3.12 took a couple of full cycles to pin
down fully. I think waiting another 2-3 months will mostly bring idle time
and diminishing returns of the long, exponentially decaying tail of
bugfixes, IMHO.

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.

So IMO the main steering parameter of our kernel stabilization process is
the maintainer directly above a developer, the first-hop maintainer. For
90-95% of the commits you are the second hop maintainer or higher. So
whether in 4.0 you are going to take non-fixes will not directly affect
the stabilization process and flow that is already in place, assuming that
our current stabilization process is more or less healthy. It will (or
should) essentially track what our current -stable process is.

But we already have that process in place and it's working well IMO - the
problem isn't really effort or meta-maintanence issues but lack of good
stability metrics due to lack of kerneloops.org feedback, etc.

So ... unless you think our current stabilization flow is unhealthy and/or
you'd like to perform a natural experiment to measure it, why not just do
what worked so well for v3.0 and afterwards? Keep the existing process in
place, don't upset it just due to a (comparably) silly number tweak.

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.

Thanks,

Ingo