A users thoughts on the new dev. model

A users thoughts on the new dev. model

[Evan Hisey]

To the Dev list:
    First, thanks for all the work on the kernel. I try to keep up with 
the list via both KernelTrap and  Kerneltraffic. Today I just saw the 
discussion on the new development model.  As an end use of the vanilla 
tree, I would like to point out that a large number of people and 
projects rely on the vanilla kernel to be the stable tree do to the 
overly varied and random patching nature of vendor supplied kernels 
making them hard to call reliable. In the case of my preferred distro 
Slackware,  the distro itself expects the vanilla tree to be stable and 
reliable enough to not need any patches.  I believe this is the case for 
a large number off distro' s and end users. Thank you for your time. 
Please send any flames,comments, or complaints via CC, as I am not 
sucribed to the list.
       Evan Hisey

Re: A users thoughts on the new dev. model

[Bill Davidsen]

Evan Hisey wrote:
> To the Dev list:
>    First, thanks for all the work on the kernel. I try to keep up with 
> the list via both KernelTrap and  Kerneltraffic. Today I just saw the 
> discussion on the new development model.  As an end use of the vanilla 
> tree, I would like to point out that a large number of people and 
> projects rely on the vanilla kernel to be the stable tree do to the 
> overly varied and random patching nature of vendor supplied kernels 
> making them hard to call reliable. In the case of my preferred distro 
> Slackware,  the distro itself expects the vanilla tree to be stable and 
> reliable enough to not need any patches.  I believe this is the case for 
> a large number off distro' s and end users. Thank you for your time. 
> Please send any flames,comments, or complaints via CC, as I am not 
> sucribed to the list.

I confess I feel that this new model is a return to the bad old days 
when the stable tree wasn't. Sounds as if Andrew is bored with the idea 
of letting 2.7 be the development tree and just being the gatekeeper of 
STABLE new features for 2.6. Perhaps 2.7 should be opened and Andrew 
will have a place to play, and features can drift to 2.6 more slowly.

I agree that vendor kernels often have unexpected behaviour, 
"improvements" on the API, etc. They sometimes protect the user from 
himself, so that code which works fine on a vendor kernel fails 
miserably on a mainline kernel.

I'm sure developers will do whatever they please, but I think a 
development kernel would be nice about now, so people could try new 
things without restriction, and people who like to use a stable kernel 
could have one.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: A users thoughts on the new dev. model

[H. Peter Anvin]

Followup to:  <cdpee5$otu$1@gatekeeper.tmr.com>
By author:    Bill Davidsen <davidsen@tmr.com>
In newsgroup: linux.dev.kernel
> 
> I confess I feel that this new model is a return to the bad old days 
> when the stable tree wasn't. Sounds as if Andrew is bored with the idea 
> of letting 2.7 be the development tree and just being the gatekeeper of 
> STABLE new features for 2.6. Perhaps 2.7 should be opened and Andrew 
> will have a place to play, and features can drift to 2.6 more slowly.
> 

I think the discussion we had at the kernel summit has been somewhat
misrepresented by LWN et al.  What we discussed was really more of a
"soft fork", with the -mm tree serving the purpose of 2.7, rather than
a hard fork with a separate maintainer and putting ourselves in
back/forward-porting hell all over again.

Note that Andrew's -mm tree *specificially* has infrastructure to keep
changes apart and thus backporting to 2.6 mainstream of patches which
have proven themselves becomes trivial.

Thus:

	- Andrew will put experimental patches into -mm;
	- Andrew will continue to forward-port 2.6 mainstream fixes to
	  -mm;
	- Patches which have proven themselves stable and useful get
	  backported to 2.6;
	- If the delta between 2.6 and -mm becomes too great we'll
	  consider a hard fork AT THAT TIME, i.e. fork lazily instead
	  of the past model of forking eagerly.

Why the change?  Because the model already has proven itself, and
shown itself to be more functional than what we've had in the past.
2.6 is probably the most stable mainline tree we've had since 1.2 or
so, and yet Linus and Andrew process *lots* of changes.  The -mm tree
has become a very effective filter for what should go into mainline,
whereas the odd-number forks generally *haven't* been, because
backporting to mainline has usually been an afterthought.

I for one welcome our new -mm overlords.

	-hpa

Re: A users thoughts on the new dev. model

[szonyi calin]

--- "H. Peter Anvin" <hpa@zytor.com> a écrit : > Followup to: 
<cdpee5$otu$1@gatekeeper.tmr.com>
> By author:    Bill Davidsen <davidsen@tmr.com>
> In newsgroup: linux.dev.kernel
> 
> Thus:
> 
> 	- Andrew will put experimental patches into -mm;
> 	- Andrew will continue to forward-port 2.6 mainstream fixes
> to
> 	  -mm;
> 	- Patches which have proven themselves stable and useful get
> 	  backported to 2.6;
> 	- If the delta between 2.6 and -mm becomes too great we'll
> 	  consider a hard fork AT THAT TIME, i.e. fork lazily instead
> 	  of the past model of forking eagerly.
> 
> Why the change?  Because the model already has proven itself,
> and
> shown itself to be more functional than what we've had in the
> past.
> 2.6 is probably the most stable mainline tree we've had since
> 1.2 or
> so, and yet Linus and Andrew process *lots* of changes.  The
> -mm tree
> has become a very effective filter for what should go into
> mainline,
> whereas the odd-number forks generally *haven't* been, because
> backporting to mainline has usually been an afterthought.
> 
> I for one welcome our new -mm overlords.
> 
> 	-hpa

Thank you for clarifying this.
So linux 2.6 from kernel.org stay stable.
And 2.6x-mm is like a 2.7 development tree (thought not that 
experimental ;-) )


>From the LWM story i understood that linux will be like windows:
lots of "features" but no stability, except if you use a
 distribution kernel. And that seriously made me think about
 using another free *nix for a stable system.  

Calin

=====
--
A mouse is a device used to point at 
the xterm you want to type in.
Kim Alm on a.s.r.


	

	
		
Vous manquez d’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

Re: A users thoughts on the new dev. model

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

This is malarkey, 99.9% pure FUD.  I personally use just about every 
kernel revision there is that is "newest", i.e. I use 2.4.x until 2.5 
appears then I switch to 2.5.x.  I may skip a few versions here and 
there due to frequent releases or a known brown bag release.  However by 
far and large even the development or "unstable" line of releases as 
some people have a bad habit of calling them, are far more reliable than 
Windows.

I use odd.x releases even on my servers.  Every once in a while there's 
a significant bug in code that I'll have an issue with that can't be 
worked around.  So I avoid that version.

In short, your statement is pure bullsh*t, because there is very little 
code put out that is actually a messy or unstable release.  Most bugs 
are quickly fixed, worked around, or avoided for that person because 
that feature isn't really such a necessity.  Linux (*nix) gives you a 
LOT of ways to get a particular task done but people have this penchant 
for finding a way that is broken and hyping/harping it up to make a big 
issue out of it instead of just reporting the bug and getting the job 
done in a different fashion.

"Oh my gawd it's a bug, let me piss on everyone's doorstep and make 
caustic remarks on LKML about horribly broken code.  Never mind you that 
I can probably get it done another way."

Give the developers a little credit, we all make mistakes; they happen 
to fix theirs pretty fast and they're downright honest about fessing up 
to them.

David

>>From the LWM story i understood that linux will be like windows:
>lots of "features" but no stability, except if you use a
> distribution kernel. And that seriously made me think about
> using another free *nix for a stable system.  
>

[-- Attachment #2: david+challenge-response.vcf --]
[-- Type: text/x-vcard, Size: 183 bytes --]

begin:vcard
fn:David Ford
n:Ford;David
email;internet:david@blue-labs.org
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: A users thoughts on the new dev. model

[Xiong Jiang]

Forgive me if I missed any points earlier in the list since I am not a
frequent reader here.

As a dumb end user I DO need people to tell me which .x version in
2.6.x series is STABLE.

I understand it is important to get new features in as
soon as possible, but it is same important that we end users could
sleep well with the version running on our systems.

If every 2.6.x version is so solid then I wouldn't say anything, but I
am afraid it is not true. I think it still very important to
distinguish between _bug_fix_ release and _feature_devel_ release,
being it
2.6.x vs 2.7.x, or
2.6.x.1 vs 2.6.x+1, or
2.6.x vs 2.6.x+1-pre/-rc/-mm

I am optimistic that this issue could be settled down fairly easily by
such an open development process.

Sincerely,

A dumb end user

On Fri, 23 Jul 2004 12:39:37 -0400, David Ford
<david+challenge-response@blue-labs.org> wrote:
> This is malarkey, 99.9% pure FUD.  I personally use just about every
> kernel revision there is that is "newest", i.e. I use 2.4.x until 2.5
> appears then I switch to 2.5.x.  I may skip a few versions here and
> there due to frequent releases or a known brown bag release.  However by
> far and large even the development or "unstable" line of releases as
> some people have a bad habit of calling them, are far more reliable than
> Windows.
> 
> I use odd.x releases even on my servers.  Every once in a while there's
> a significant bug in code that I'll have an issue with that can't be
> worked around.  So I avoid that version.
> 
> In short, your statement is pure bullsh*t, because there is very little
> code put out that is actually a messy or unstable release.  Most bugs
> are quickly fixed, worked around, or avoided for that person because
> that feature isn't really such a necessity.  Linux (*nix) gives you a
> LOT of ways to get a particular task done but people have this penchant
> for finding a way that is broken and hyping/harping it up to make a big
> issue out of it instead of just reporting the bug and getting the job
> done in a different fashion.
> 
> "Oh my gawd it's a bug, let me piss on everyone's doorstep and make
> caustic remarks on LKML about horribly broken code.  Never mind you that
> I can probably get it done another way."
> 
> Give the developers a little credit, we all make mistakes; they happen
> to fix theirs pretty fast and they're downright honest about fessing up
> to them.
> 
> David
> 
> 
> 
> >>From the LWM story i understood that linux will be like windows:
> >lots of "features" but no stability, except if you use a
> > distribution kernel. And that seriously made me think about
> > using another free *nix for a stable system.
> >
> 
> 
>

Re: A users thoughts on the new dev. model

[Tim Wright]

As a dumb end user, what reason would you have for wishing to grab a
kernel.org kernel? A true "dumb end user" cares about the applications
they intend to run and doesn't give a hoot about the kernel. Provided
that the kernel supports the applications they wish to use, and it's
stable, it should not be relevant. There are people out there using
Linux 2.0.X, 2.2.X, 2.4.X etc. etc. and who are perfectly happy because
it does what they need it to do. If you care about the latest 2.6.X
kernel version, you're *not* "a dumb end user" :-)

Anyway, as hpa kindly pointed out, the 2.6.X kernels are still intended
to be stable. The proving ground will be in the -mm series. So carry on
using 2.6.X and be happy. It's been a great deal more stable than 2.4.X
was for a long time at least for me.

Regards,

Tim

On Fri, 2004-07-23 at 12:06, Xiong Jiang wrote:
> Forgive me if I missed any points earlier in the list since I am not a
> frequent reader here.
> 
> As a dumb end user I DO need people to tell me which .x version in
> 2.6.x series is STABLE.
> 
> I understand it is important to get new features in as
> soon as possible, but it is same important that we end users could
> sleep well with the version running on our systems.
> 
> If every 2.6.x version is so solid then I wouldn't say anything, but I
> am afraid it is not true. I think it still very important to
> distinguish between _bug_fix_ release and _feature_devel_ release,
> being it
> 2.6.x vs 2.7.x, or
> 2.6.x.1 vs 2.6.x+1, or
> 2.6.x vs 2.6.x+1-pre/-rc/-mm
> 
> I am optimistic that this issue could be settled down fairly easily by
> such an open development process.
> 
> Sincerely,
> 
> A dumb end user
> 
> On Fri, 23 Jul 2004 12:39:37 -0400, David Ford
> <david+challenge-response@blue-labs.org> wrote:
> > This is malarkey, 99.9% pure FUD.  I personally use just about every
> > kernel revision there is that is "newest", i.e. I use 2.4.x until 2.5
> > appears then I switch to 2.5.x.  I may skip a few versions here and
> > there due to frequent releases or a known brown bag release.  However by
> > far and large even the development or "unstable" line of releases as
> > some people have a bad habit of calling them, are far more reliable than
> > Windows.
> > 
> > I use odd.x releases even on my servers.  Every once in a while there's
> > a significant bug in code that I'll have an issue with that can't be
> > worked around.  So I avoid that version.
> > 
> > In short, your statement is pure bullsh*t, because there is very little
> > code put out that is actually a messy or unstable release.  Most bugs
> > are quickly fixed, worked around, or avoided for that person because
> > that feature isn't really such a necessity.  Linux (*nix) gives you a
> > LOT of ways to get a particular task done but people have this penchant
> > for finding a way that is broken and hyping/harping it up to make a big
> > issue out of it instead of just reporting the bug and getting the job
> > done in a different fashion.
> > 
> > "Oh my gawd it's a bug, let me piss on everyone's doorstep and make
> > caustic remarks on LKML about horribly broken code.  Never mind you that
> > I can probably get it done another way."
> > 
> > Give the developers a little credit, we all make mistakes; they happen
> > to fix theirs pretty fast and they're downright honest about fessing up
> > to them.
> > 
> > David
> > 
> > 
> > 
> > >>From the LWM story i understood that linux will be like windows:
> > >lots of "features" but no stability, except if you use a
> > > distribution kernel. And that seriously made me think about
> > > using another free *nix for a stable system.
> > >
> > 
> > 
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Tim Wright <timw@splhi.com>
Splhi

Re: A users thoughts on the new dev. model

[Adrian Bunk]

On Fri, Jul 23, 2004 at 01:58:27PM +0000, H. Peter Anvin wrote:
> Followup to:  <cdpee5$otu$1@gatekeeper.tmr.com>
> By author:    Bill Davidsen <davidsen@tmr.com>
> In newsgroup: linux.dev.kernel
> > 
> > I confess I feel that this new model is a return to the bad old days 
> > when the stable tree wasn't. Sounds as if Andrew is bored with the idea 
> > of letting 2.7 be the development tree and just being the gatekeeper of 
> > STABLE new features for 2.6. Perhaps 2.7 should be opened and Andrew 
> > will have a place to play, and features can drift to 2.6 more slowly.
> > 
> 
> I think the discussion we had at the kernel summit has been somewhat
> misrepresented by LWN et al.  What we discussed was really more of a
> "soft fork", with the -mm tree serving the purpose of 2.7, rather than
> a hard fork with a separate maintainer and putting ourselves in
> back/forward-porting hell all over again.
> 
> Note that Andrew's -mm tree *specificially* has infrastructure to keep
> changes apart and thus backporting to 2.6 mainstream of patches which
> have proven themselves becomes trivial.
>...

One problem from a user's point of view is that removal of obsolete code 
that works sufficiently for some users.

Andrew said explicitely in a mail to linux-kernel that he'd consider 
removing devfs "mid-2005" - and it didn't sound as if this would only be 
a -mm "feature".

Even if 2.7 is started this doesn't has to imply that it has to be 
flooded with big changes - a short 2.7 with relativley few invasive 
changes might also be an option.

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: A users thoughts on the new dev. model

[hpa]

>
> One problem from a user's point of view is that removal of obsolete code
> that works sufficiently for some users.
>
> Andrew said explicitely in a mail to linux-kernel that he'd consider
> removing devfs "mid-2005" - and it didn't sound as if this would only be
> a -mm "feature".
>
> Even if 2.7 is started this doesn't has to imply that it has to be
> flooded with big changes - a short 2.7 with relativley few invasive
> changes might also be an option.
>

There is no difference from a user's point of view between a "short 2.7"
and "a close -mm tree."  Either way devfs is on death row, because it's
buggy and unmaintained.  Any piece of code, *especially* one as invasive
as devfs, which is buggy and unmaintained is a hassle to for *all* kernel
development, and have to be extricated at some point.

	-hpa

Re: A users thoughts on the new dev. model

[Adrian Bunk]

On Fri, Jul 23, 2004 at 04:04:32PM -0700, hpa@zytor.com wrote:
> >
> > One problem from a user's point of view is that removal of obsolete code
> > that works sufficiently for some users.
> >
> > Andrew said explicitely in a mail to linux-kernel that he'd consider
> > removing devfs "mid-2005" - and it didn't sound as if this would only be
> > a -mm "feature".
> >
> > Even if 2.7 is started this doesn't has to imply that it has to be
> > flooded with big changes - a short 2.7 with relativley few invasive
> > changes might also be an option.
> >
> 
> There is no difference from a user's point of view between a "short 2.7"
> and "a close -mm tree."  Either way devfs is on death row, because it's

You missed one important difference:

With a "short 2.7", 2.6 stays unchanged. This way, users have a 2.6 tree 
which will continue to stay unchanged regarding such user-visible 
changes but still gets lots of fixes for several years.

For many users I know it's an important difference whether upgrading 
from 2.6.X to 2.6.Y (with Y > X) has a low risk of breaking anything 
working with 2.6.X or not.

Many people complained after USB_SCANNER was removed in 2.6.3, and the 
only excuse (besides that it had several bugs and was for most users  
inferior to SANE) is that this was very early in the 2.6 series.

> buggy and unmaintained.  Any piece of code, *especially* one as invasive
> as devfs, which is buggy and unmaintained is a hassle to for *all* kernel
> development, and have to be extricated at some point.

I don't disagree with this statement. But IMHO "some point" shouldn't 
be in 2.6 .

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: A users thoughts on the new dev. model

[Bill Davidsen]

Adrian Bunk wrote:
> On Fri, Jul 23, 2004 at 01:58:27PM +0000, H. Peter Anvin wrote:
> 
>>Followup to:  <cdpee5$otu$1@gatekeeper.tmr.com>
>>By author:    Bill Davidsen <davidsen@tmr.com>
>>In newsgroup: linux.dev.kernel
>>
>>>I confess I feel that this new model is a return to the bad old days 
>>>when the stable tree wasn't. Sounds as if Andrew is bored with the idea 
>>>of letting 2.7 be the development tree and just being the gatekeeper of 
>>>STABLE new features for 2.6. Perhaps 2.7 should be opened and Andrew 
>>>will have a place to play, and features can drift to 2.6 more slowly.
>>>
>>
>>I think the discussion we had at the kernel summit has been somewhat
>>misrepresented by LWN et al.  What we discussed was really more of a
>>"soft fork", with the -mm tree serving the purpose of 2.7, rather than
>>a hard fork with a separate maintainer and putting ourselves in
>>back/forward-porting hell all over again.
>>
>>Note that Andrew's -mm tree *specificially* has infrastructure to keep
>>changes apart and thus backporting to 2.6 mainstream of patches which
>>have proven themselves becomes trivial.
>>...
> 
> 
> One problem from a user's point of view is that removal of obsolete code 
> that works sufficiently for some users.
> 
> Andrew said explicitely in a mail to linux-kernel that he'd consider 
> removing devfs "mid-2005" - and it didn't sound as if this would only be 
> a -mm "feature".
> 
> Even if 2.7 is started this doesn't has to imply that it has to be 
> flooded with big changes - a short 2.7 with relativley few invasive 
> changes might also be an option.

I would consider removing devfs or cryptoloop invasive, since they would 
mean some people just flat-out couldn't use the kernel with their 
existing system.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: A users thoughts on the new dev. model

[Paul Jackson]

Evan,

Have you found (1) Linus' 2.6 bk tree to meet your needs over the last
few months?  Or (2) has it been too unstable for you?

If (1), seems like you might be in good shape, as from what I can
gather of this (not being in Ottawa) next month looks alot like
last month, so far as how Linux is developed.

If (2), then perhaps there is an opportunity here for a derivative of
Linus' tree that is "stabilized a bit", but not overly patched like
certain vendor kernels I won't name.

Yes, we'd all like the head kernel to march to the beat of our
particular needs, rapidly changing and adding what we need without
delay, leaving the rest untouched, and never breaking.

Now ... back to reality ...

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: A users thoughts on the new dev. model

[Bill Davidsen]

Paul Jackson wrote:
> Evan,
> 
> Have you found (1) Linus' 2.6 bk tree to meet your needs over the last
> few months?  Or (2) has it been too unstable for you?
> 
> If (1), seems like you might be in good shape, as from what I can
> gather of this (not being in Ottawa) next month looks alot like
> last month, so far as how Linux is developed.
> 
> If (2), then perhaps there is an opportunity here for a derivative of
> Linus' tree that is "stabilized a bit", but not overly patched like
> certain vendor kernels I won't name.
> 
> Yes, we'd all like the head kernel to march to the beat of our
> particular needs, rapidly changing and adding what we need without
> delay, leaving the rest untouched, and never breaking.
> 
> Now ... back to reality ...
> 
I'm not sure that's true, I personally think there is a lot to be said 
about the model currently being used for 2.2 and 2.4, which is almost 
totally bug-fix mode. Is that bad? The addition of minor fixes, like 
better scheduling, should not impact stability, let more massive changes 
(and feature deletions) be omitted. Is a new Reiser version likely to be 
more stable than what we have, or should this wait for a development 
version? Good, put it somewhere else.

I like to invert the arguments for putting new stuff in 2.6, let's go 
back to the excitement of development and open 2.7, and put 2.6 out to 
pasture right away. Then 2.6 can really be stable and 2.7 can go hog 
wild, without holding back the developers with pesky users.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: A users thoughts on the new dev. model

[Paul Jackson]

Bill wrote:
> let's go back to the excitement of development and open 2.7,

I like the plan in your .sig better <grin>:

>     -bill davidsen (davidsen@tmr.com)
> "The secret to procrastination is to put things off until the
>   last possible moment - but no longer"  -me

But, in any event, I have forsaken further efforts to persuade
anyone to change their views on this matter.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: A users thoughts on the new dev. model

[Florin Andrei]

On Thu, 2004-07-22 at 08:04, Evan Hisey wrote:

> As an end use of the vanilla 
> tree, I would like to point out that a large number of people and 
> projects rely on the vanilla kernel to be the stable tree do to the 
> overly varied and random patching nature of vendor supplied kernels 

It looks like a communication problem.

Like someone else noted, 2.6 is currently more stable than the
correspondent 2.2 and 2.4 versions, due to efforts by OSDL and others,
and perhaps due to significant contribution from A. Morton, etc.
So, when Andrew says that perhaps 2.6 is not going to be the most stable
series, it does not mean "it's going to be the least stable series among
2.0, 2.2, 2.4, etc." In fact, even taking Andrew's words into account,
it may well be that 2.6 is going to be more stable than 2.4 - the same
2.4 that "clueless" users were happily using on their production
servers, while at the same time complaining about 2.6 being too
"unstable".

It could be that the ones who are complaining have an oversimplified,
"binary" view of how things are:
- Caveman thinks 2.2, 2.4 stable is
- Caveman thinks 2.6 stable is not
Or, in other words, stability seems to be a magical property that's
added or removed to/from a software based on their names/numbers/etc.

While the reality might well be more complex. So, 2.6 is not the most
stable series. That's fine, vanilla "stable" was never the most stable -
that title goes to the Red Hat Enterprise kernels and the like.
But if 2.6 is more stable than 2.4, then by all means that's fine with
me.

It seems to me that some users do not want to just use the most stable
kernel. They want to use the most stable kernel AND that kernel must be
the "stable" vanilla kernel.
Sorry guys, but the vanilla kernel has many goals. Stability is only one
of them.

-- 
Florin Andrei

http://florin.myip.org/