[grsec] Kernel version tracking policy?

[Mike Perry]

Is there any strategy behind the current efforts to support particular
kernel versions? I would think that most grsecurity users would want
both security and stability on their production systems. It would seem
to me that most of them would prefer to have the project's limited
resources devoted to targeting the most stable minor versions of the
vanilla kernel rather than the bleeding edge.

For example, right now 2.6.22 has just been released, but bugfixes are
still coming in to 2.6.20 (for which .15 was just released a few days
ago).  Instead of wasting effort on the faster moving bleeding edge of
2.6.22 (or even 2.6.21), why not focus your efforts on making releases
for the very last bugfix release of a particular minor version? 

For example, targeting the development in www.grsecurity.com/~spender
on 2.6.20.latest so that you can release a stable version for
2.6.20.last and have it be usable with confidence for people for a
long time. It would seem that this would make for both less work and
ultimately more stable releases. Maybe this is the plan now with
2.6.21, but it seems like it hasn't been the plan with prior releases.

Anyways, I'm really happy with grsecurity otherwise. Please keep up
the good work!

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20070713/b111e9f7/attachment.pgp