[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061108230530.GA25927@rhlx01.hs-esslingen.de>
Date: Thu, 9 Nov 2006 00:05:30 +0100
From: Andreas Mohr <andi@...x01.fht-esslingen.de>
To: Jesper Juhl <jesper.juhl@...il.com>
Cc: Arjan van de Ven <arjan@...radead.org>,
Linus Torvalds <torvalds@...l.org>,
Andrew Morton <akpm@...l.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Adrian Bunk <bunk@...sta.de>
Subject: Re: A proposal; making 2.6.20 a bugfix only version.
Hi,
On Wed, Nov 08, 2006 at 11:40:27PM +0100, Jesper Juhl wrote:
> Let me make one very clear statement first: -stabel is a GREAT think
> and it is working VERY well.
> That being said, many of the fixes I see going into -stable are
> regression fixes. Maybe not the majority, but still, regression fixes
> going into -stable tells me that the kernel should have seen more
> testing/bugfixing before being declared a stable release.
Nice theory, but of course I'm pretty sure that it wouldn't work
(as has been said numerous time before by other people).
You cannot do endless testing/bugfixing, it's a psychological issue.
If you do that, then you end up with -preXX (or worse, -preXXX)
version numbers, which would cause too many people to wait and wait
and wait with upgrading until "that next stable" kernel version
finally becomes available.
IOW, your tester base erodes, awfully, and development progress stalls.
You *have* to release a new ""stable"" version rather fast (the .0 one)
so that people will have that "new shiny version, get it while it's hot!"
feeling and will realize rather quickly that that new version
is all crap again after all and report their unhappiness.
That will lead to lots of -stable bug fixes which will then result in
a very stable actual version once you reach x.y.z.15 or so.
Capito? :)
(well, that's at least how I'm seeing it; correct me if I'm wrong)
Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists