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

[Josh Boyer]

On Mon, Nov 4, 2013 at 1:25 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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...

I'd agree with that, but it wouldn't be limited to just the final
non-bugfix release.  It would be a year-long "shove as much as we can
in" push, and I'd be fearful of doing any distro kernel based on any
one of those releases.  Clearly the subsystem maintainers would still
be fighting the good fight, but I'm concerned they'd be overwhelmed
and/or burnt out by the time 4.0 came around.

> 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.

Right.

josh
--
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/