[lkml]   [2003]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Some thoughts about stable kernel development
Hi Krzysztof,

Something like this has already been proposed a few times in the past (even
recent past), and I'm also all for a real permanently stable release which
only fixes bugs and vulnerabilities of the previous release. But there were
some massive objections, amongst others (IIRC) :

- maintaining two trees is always more work than only one tree for the
same person, whatever the changes. This is obviously true, otherwise
none of us would ask for someone else to maintain the stable tree :-)
I believe this reason was given by both Alan and Marcelo at different

- I think it was Linus who said that clueless people will only use distro's
kernels, therefore are not affected by how the kernel is developped. And
for other people like us, the "stable" kernel will never contain enough
features and we will have to patch anyway.

- someone else (alan ?) said that even most obvious fixes can break some
setups, so there are not many "obviously riskless" patches around, and
if there's a really critical one which needs to go mainstream very quickly,
then the maintainer can always release a new version in a hurry and delay
-preX pending features for the next release.

I too would love to see frequent releases of bug fixes only, but I can admit
that it would not be fair to ask a handful of people to do more work just to
serve a few hundreds of lazy or busy people around. And BTW, there are now
people trying to maintain parallel bugfixes-only branches. Take a look at
James Bourne's site :

As long as individual patches are easily available, it's not too hard for
us to integrate them into our kernels.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:0.085 / U:5.492 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site