Folks,
Lately on this list I have been hearing a lot of discussion about putting
out point releases for security and bug fixes to the stable series of
kernels. There has even been a single release (2.6.8.1) that actually
followed through with this.
What has not been clear to me from the threads is how far back people are
planning on supporting with these point releases? A lot of people seem to
be very interested in being able to run a kernel for extended lengths of
time, but most of the discussion on point releases has been about getting
a 2.6.X.1 while 2.6.X+1 is still in it's pre stages. What about the
people running 2.6.X-1? Can they expect to get a point release for
security updates?
I've been thinking about this, and it seems to me that there is going to
have to be a choice between either supporting just the current stable
release, or supporting the last X releases. The first option is going to
leave a lot of people unhappy as major changes get put into releases, and
the other option is going to be painful to support.
Rather than actually putting out point releases for the previously
released kernels, why not just create a centralized repository for the
security patches? In a lot of cases security patches can be applied as is
to a number of different kernel revisions. For the ones that cannot,
variances of the patches could be posted along with it clearly marked as
to which patches apply to which kernels.
Thoughts?
--
Greg Boyce
On Mer, 2005-01-12 at 19:45, Gregory Boyce wrote:
> be very interested in being able to run a kernel for extended lengths of
> time, but most of the discussion on point releases has been about getting
> a 2.6.X.1 while 2.6.X+1 is still in it's pre stages. What about the
> people running 2.6.X-1? Can they expect to get a point release for
> security updates?
For -ac I'll support just the current release unless there are real
stability problems or a hole occurs just as Linus puts out a new release
and there isn't enough test data to see what needs fixing in it in which
case I'll fix both.
Alan
Gregory Boyce wrote
> Rather than actually putting out point releases for the previously
> released kernels, why not just create a centralized repository for the
> security patches? In a lot of cases security patches can be applied as is
> to a number of different kernel revisions. For the ones that cannot,
> variances of the patches could be posted along with it clearly marked as
> to which patches apply to which kernels.
>
> Thoughts?
I guess the new -as tree is more or less achieving what you want. If
Andres gets enough support from other people, it might be possible to
maintain even more than one or two former releases...
[x] Voting for the -as tree to become an official tree on kernel.org :-)
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Gwe, 2005-01-14 at 08:01, Frank Steiner wrote:
> I guess the new -as tree is more or less achieving what you want. If
> Andres gets enough support from other people, it might be possible to
> maintain even more than one or two former releases...
The problem is deciding what goes into such a tree. Do you go security
fixes only which nobody afaik is doing now, do you mix them with key
fixes and if so how far do you add fixes - thats a real PITA because you
can get odd clear fixes for minor problems (eg NFS df) that have never
been tested hard standalone. You can also get dependancies on
non-security fixes for security - -ac for example included my IDE work
to deal with the various IDE exploits/races. Though only minor security
wise there isn't a trivial fix for these with the broken locking in
Linus IDE and its going to take time for Bartlomiej to be happy with my
locking changes.
Alan