At last, I'm *really* subscribed from this address, so I'll have
another go at trying to send this :)
Now that we have maintenance of the stable kernel, I think we
should point people to the latest incremental release of the same
kernel version. So, if we release a book with 2.6.16.12 and
subsequently 2.6.11.{13,14,15} are released, I'd hate to think that
people would religiously follow the book and not use the later
versions.
Mentioning stable releases has a number of implications:
(i.) The editor's guide says we should build with the new version
before putting it in the book. I humbly submit that we should make
an exception for stable kernels and put them in as soon as they
appear - the changes are tiny, to deal with known issues, and
sometimes they are security fixes. Personally, I don't build every
new version of a stable kernel because most of the time I'm running
development kernels.
To be clear, I'm not saying 2.6.17 should go in as soon as it
appears, only that while we are on 2.6.xx.y we should move the book
to 2.6.xx.y+1 as soon as that is released (with the presumption that
we won't get as far behind kernel releases as we were with the udev
problem).
(ii.) Because the changes are tiny, I assume SBU and space
measurements can be carried forward - I think the figures for
2.6.16.5 were mine, in which case they are accurate for that version
on my machine with my .config but may have only a glancing relevance
to your figures.
(iii.) The stable patches are created against the base version, so
if you patch from 2.6.16.5 to 2.6.16.12 you need to have both
patch-2.6.16.5.bz2 and patch-2.6.16.12.bz2, and to reverse the first
one. This still catches people out, so I think it is worth putting
in the book.
Personally, I run 'head Makefile' to confirm I've patched
correctly, and also "find -name '*.rej'" - I submit there is a small
educational gain from mentioning this, and that it will be good to
encourage people to NOT always download a full tarball when they are
trying out a new kernel, if only to reduce bandwidth.
(iv.) I was tempted to say that we shouldn't encourage people to say
"the book has 2.6.16.12, but 2.6.18 is out, so I'll use that without
investigating if anything else has to be upgraded.", but looking at
the mails on support I think we have the opposite problem - people
stick with the kernel in the book and do not monitor
vulnerabilities. So, although it isn't strictly related to the
stable kernel issue, I would like to also propose that at the end of
the book we add some text encouraging people to (a) monitor what is
happening in the kernel re vulnerabilities and issues, and (b) try
out test (-rc) kernels [ because they do need testing ] if they are
prepared to do the necessary background reading to follow what is
going on, and prepared to handle reporting bugs on lkml.
But, I'm well aware that I've been monitoring kernel development
for longer than I've been using lfs, and that although to me it
would be obviously correct to upgrade to a new stable release if I'm
not already using a -rc kernel that has the fixes, other people may
think differently. So, what do you think ?
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
