A users thoughts on the new dev. model

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

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 ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me

Followup to:  <[email protected]>
By author:    Bill Davidsen <[email protected]>
In newsgroup: linux.dev.kernel

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

--- "H. Peter Anvin" <[email protected]> a écrit : > Followup to:
<[email protected]>

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 ;-) )

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

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

begin:vcard
fn:David Ford
n:Ford;David
email;internet:[email protected]
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

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

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

Tim Wright <[email protected]>
Splhi

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.

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

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

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.

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

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

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 ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me

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 <[email protected]> 1.650.933.1373

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 ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me

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

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 <[email protected]> 1.650.933.1373

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/