linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Olof Johansson <olof@lixom.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
Date: Mon, 4 Nov 2013 12:05:26 -0800	[thread overview]
Message-ID: <CAOesGMiDwGpmPErH-=fFqoT=2Xg8pQ12V-QGVK+e8S-dyUHkYg@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFwLkvSkparyvekdmMyvr6Srw1KkzTBp=_w0oQRWnPpJug@mail.gmail.com>

On Sun, Nov 3, 2013 at 4:10 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

> The reason I mention it is because I've been mulling over something
> Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked
> at the Q&A session whether we could do a release with just stability
> and bug-fixes, and I pooh-poohed it because I didn't see most of us
> having the attention span required for that
> (cough*cough*moronic*woodland creature*cough*cough).
>
> 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?

Ingo has some very good points. I think this might be worth doing in
some form or other, but if it's worth a full release cycle is less
certain to me:

Essentially we already do this for every release, where the last
couple of weeks are strictly bugfixes only. While it's not what you're
proposing, the end result sounds to me more like a "forced" extension
of the -rc cycle by several weeks to let more of those fixes come in.

If you're doing a 3.20/4.0 that is bugfixes only, then why release
3.19 at all? If the only difference between the two is said fixes,
we'd be better off just holding on until the latter is released. Which
again comes back to in practice extending the release by several more
weeks of late -rcs.

The only benefit I can think of to make a 3.19 release is to pick up
more users, if some of them avoid -rcs but do use full releases
shortly after they are tagged. I don't know how common that is though.


-Olof

  parent reply	other threads:[~2013-11-04 20:05 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
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 [this message]
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='CAOesGMiDwGpmPErH-=fFqoT=2Xg8pQ12V-QGVK+e8S-dyUHkYg@mail.gmail.com' \
    --to=olof@lixom.net \
    --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).