From: Tarkan Erimer <tarkan@netone.net.tr>
To: Mike Snitzer <snitzer@gmail.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Arjan van de Ven <arjan@infradead.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Suggestion About Kernel Releases
Date: Wed, 21 May 2008 18:15:30 +0300 [thread overview]
Message-ID: <48343C92.4090403@netone.net.tr> (raw)
In-Reply-To: <170fa0d20805210732s24f2c188i75ab2ab2dab5aeb5@mail.gmail.com>
Mike Snitzer wrote:
> I think you're missing Arjan and Pekka's point: your proposal doesn't
> _really_ offer any change to the current procedure. It might make you
> feel more warm and fuzzy but in practice:
> 1) Linus would still release a kernel (be it to -testX or "final")
> when he and others feel it is time
> 2) The stable team will track fixes and release stable kernels as needed
>
> The only thing that is different in your approach is the "final"
>
Yes, that's what I'm talking about. The change will be the "testX"
thing. And as you already stated it will help more stable releases.
> release would theoretically be more well tested. Unfortunately that
> is not a valid assumption because the wider Linux audience likely
> won't embrace the latest kernel until it is "final" anyway. This
> delayed uptake can/will result in early stable fixes.
>
>
Of course as didn't embrace like the "rc" releases. I don't think that
it will cause early stable fixes. Contrarily, it will produce more
tested/stable releases. You may think it as a kind of "rc" series.
> Again, no real change... we know that the "final" release that Linus
> makes _could_ have some minor oversight that will be fixed fairly
> quickly by the stable team.
>
> Mike
>
It is. As I described above : the "testX" series will change the things
as producing more tested /stable releases. BTW, it should be much better
to release less, trouble free kernels instead of releasing fast but
fixing soon. Also, it will take the load of deep kernel testing. Linus
should only do the applying the patches for the next kernel release via
"rc" releases. Then when Linus decided all the patches, for the next
kernel, applied he will pass it to the "testX" series maintainer as
Chris did for 2.6.x.y.
next prev parent reply other threads:[~2008-05-21 15:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-21 13:08 Suggestion About Kernel Releases Tarkan Erimer
2008-05-21 13:38 ` Arjan van de Ven
2008-05-21 13:48 ` Pekka Enberg
2008-05-21 14:00 ` Tarkan Erimer
2008-05-21 14:32 ` Mike Snitzer
2008-05-21 15:15 ` Tarkan Erimer [this message]
2008-05-21 15:26 ` Pekka Enberg
2008-05-24 3:11 ` Enrico Weigelt
2008-05-21 13:59 ` Tarkan Erimer
2008-05-21 14:28 ` Arjan van de Ven
2008-05-21 14:50 ` Tarkan Erimer
2008-05-21 15:12 ` Arjan van de Ven
2008-05-21 17:31 ` Chris Wright
2008-05-22 6:46 ` Tarkan Erimer
2008-05-21 19:55 ` Rik van Riel
2008-05-21 14:37 ` Oliver Pinter
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=48343C92.4090403@netone.net.tr \
--to=tarkan@netone.net.tr \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=snitzer@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.