On Tue, May 02, 2006 at 06:22:49PM -0600, Archaic wrote:
> On Wed, May 03, 2006 at 01:07:49AM +0100, Ken Moffat wrote:
> > 
> > At the moment, we seem happy to let people stick with the kernel they
> > built when they built LFS.
> 
> I don't understand. We don't control what a user does. We give a build
> recipe, throw in some educational material, give guidelines on how to
> maintain the system. What exactly are you asking that we do?
> 
 I guess I'm suggesting we should encourage people to upgrade!  In
particular, people continue to build the released version of the
book months, or years, afterwards.

> 2.6.16 is most likely the kernel that will be used in lfs-6.2 due mostly
> to timing issues. We can't wait for 2.6.17 to settle down, else a book
> would never get released. If a 2.6.16.x release comes out during the
> testing phase, we could look at it, test it a bit, perhaps discuss
> on-list, but I'm not prepared to make the blanket statement that any
> point release from the 2.6.16 branch is a suitable drop-in without
> testing.

 My argument for -stable kernels is that they are intrinsically
better (because they fix identified bugs), and that until the book
is released we should pick up any new versions [ for 2.6.16 in this
case ] without waiting for an editor to build with them.

 Some of the bugs are probably trivial - most LFS users won't have
been exposed to the nfs data corruption in early 2.6.16 [ fixed in
2.6.16.3 or earlier ], and compile failures on other architectures
should not concern us here, but any suggestion that the testing
resources available to us prove a particular kernel version is
"stable" seems optimistic to me.

 But I agree totally that we shouldn't wait for 2.6.17 - it has been
long enough since the last release, and anyway by then we can look
forward to what will be in 2.6.18.

Ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to