Change of policy for future 2.2 driver submissions
You might find it interesting to read the section entitled "Monkeywrenching the Virtual Machine" towards the end of "Why We Should All Test the New Linux Kernel". It's in my second comment after the main article:
http://advogato.org/article/224.html
I understand Linus' desire to have more widespread testing done on the kernel, and certainly he can accomplish that by labeling some random build as the new stable version. But I think a better choice would have been to advocate testing more widely - don't just announce it to the linux-kernel list, get on National Public Radio, the Linux Journal and Slashdot and stuff.
Don't just announce the existence of a kernel that people ought to test, but hit the streets and provide advice and assistance and encouragement to those who might help out.
That's the kind of thing I was trying to do in my article above.
My concern is that declaring this kernel as production and stable, with patching still happening by the minute, is that a lot of people who don't know what they're doing will slap it into machines they depend on for their livelihood, and a lot of distributions will quickly adopt it in order to be perceived as competitive. The very first experience many people will ever have with Free Software will boot off Linux 2.4.0 - not 2.4.1, because some distro will want to be the first.
You might think this is great because of all the extra testing the new users will do but I assert that it isn't. The environment for Linux is quite different these days than when 2.2 or 2.0 were released.
A lot of the people who will be using it are not technically savvy people, and many of those who do know technology depend on its reliability for the profitability of large businesses but may not read Linus' message that indicates this is really just for testing.
It would be really bad if this particular version of the kernel turns out to have a lot of problems.
I guess you can get more people testing by releasing it yourselves than I can with my websites saying people should test, but I feel that having the testing done by people who know what they're getting into and have some guidance is a wiser course of action.
If you're in the neighborhood, please stop by:
http://linuxquality.sunsite.dk
Mike
Signature · 10 lines
Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [email protected] Tilting at Windmills for a Better Tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Michael D. Crawford wrote:
<snip>
Quoted 8 lines
You might think this is great because of all the extra testing the new users will do but I assert that it isn't. The environment for Linux is quite different these days than when 2.2 or 2.0 were released.
A lot of the people who will be using it are not technically savvy people, and many of those who do know technology depend on its reliability for the profitability of large businesses but may not read Linus' message that indicates this is really just for testing.
Alan's comments were addressed to driver developers, not users. It's driver developers who need to work with Alan to make sure he doesn't have to now do twice as much work as he used to (BTW: I think this is a mental and physical impossibility).
The distros will ship 2.4.0 kernels whenever they want to, which will probably be when they think there are no major gotchas in it.
If I remember correctly, when 2.2.0 was released, a similar process took place. Alan helped get patches into the 2.0 kernel tree for a while. When the 2.3.0 tree was opened up, Linus' attention shifted completely to that new development tree. That left Alan to take up the slack by becoming the maintainer of the 2.2 tree. Very shortly after Alan moved onto the 2.2 tree, he announced that the vast amount of his work would be focussed there and not on the 2.0 tree.
As far as I know, 2.0 to 2.2 transition went really quite smoothly, so this process must be working.
I would suggest that if you are writing drivers for the 2.2 tree, that you just work with Alan and make sure your code is also in the 2.4 tree. Alan's doing you a favor by clearly spelling out what he can reasonably be expected to accomplish. If he over- estimated his ability to process code changes, we'd all be in a world of hurt and disappointment.
As for users, their fate is in the hands of the distribution developers. It's the distribution developers' responsibility to ship good, solid code. If you are scared that they won't do a good job of that, I guess you'll want to wait for one of their later releases.
Best wishes,
Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
In article <[email protected]>,
Quoted 6 lines · Michael D. Crawford
I understand Linus' desire to have more widespread testing done on the kernel, and certainly he can accomplish that by labeling some random build as the new stable version. But I think a better choice would have been to advocate testing more widely - don't just announce it to the linux-kernel list, get on National Public Radio, the Linux Journal and Slashdot and stuff.
You don't understand people, I think.
No amount of publicity will matter all that much in the end: yes, it will result in many people who are not afraid of a compiler to try it out. And we've had that for over six months now, realistically.
But that's very different from having somebody like RedHat, SuSE or Debian make such a kernel part of their standard package. No, I don't expect that they'll switch over completely immediately: that would show a lack of good judgement. The prudent approach has always been to have both a 2.2.19 and a 2.4.0 kernel on there, and ask the user if he wants to test the new kernel first.
That way you get a completely different kind of user that tests it.
The other thing is that even if something like 2.4.0-test8 gets rave reviews, that doesn't _matter_ to people who crave stability. The fact is that 2.4.0 has been getting quite a lot of testing: people haven't even seen how the big vendors have all done testing in their labs etc.
And to the people who really want to have stability, none of that matters. They will basically "start fresh" at the 2.4.0 release, and give it a few months just to follow the kernel list etc to see what the problems will be. They'll have people starting to ramp up 2.4.0 kernels in their own internal test environment, moving it first to machines they feel more comfortable with etc etc.
None of which would happen if you just try to make the beta testing cycle much bigger.
Which is why to _me_ the most important thing is that I'm happy with the core infrastructure - because once you've tested it to a certain degree, it's not going to improve without a real public release.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Hi,
On Fri, Jan 05, Linus Torvalds wrote:
[...]
Quoted 6 lines
But that's very different from having somebody like RedHat, SuSE or Debian make such a kernel part of their standard package. No, I don't expect that they'll switch over completely immediately: that would show a lack of good judgement. The prudent approach has always been to have both a 2.2.19 and a 2.4.0 kernel on there, and ask the user if he wants to test the new kernel first.
Right, but now there is a problem: Software RAID. The RAID code of 2.4.0 is not backwards compatible to the one in 2.2.18; if somebody has used 2.4.0 on softraid and discovers some problem, he can not switch back to some official 2.2 kernel. In order to make it possible to switch between kernel releases, every vendor now really is forced to integrate the new RAID0.90 code to their 2.2 kernel. IMHO this code should be integrated to the next official 2.2 kernel so people can use whatever they want.
Quoted 1 line
Linus
-o)
Hubert Mantel Goodbye, dots... /\\
_\_v-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines
some official 2.2 kernel. In order to make it possible to switch between kernel releases, every vendor now really is forced to integrate the new RAID0.90 code to their 2.2 kernel. IMHO this code should be integrated to the next official 2.2 kernel so people can use whatever they want.
Then people using a newer 2.2 cannot go back to an older 2.2 thats really far far worse.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · Alan Cox
Quoted 4 lines
some official 2.2 kernel. In order to make it possible to switch between kernel releases, every vendor now really is forced to integrate the new RAID0.90 code to their 2.2 kernel. IMHO this code should be integrated to the next official 2.2 kernel so people can use whatever they want.
Then people using a newer 2.2 cannot go back to an older 2.2 thats really far far worse.
And don't forget, the 0.90 patches are available for 2.2 - so 2.2 can do 0.90 Software RAID just fine.
Besides, most people using Software RAID have been using 0.90 for at least two years - so I doubt this would have been much of a problem if the 0.90 patches weren't available for 2.2, which they are.
Signature · 10 lines
................................................................ : [email protected] : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Jakob Østergaard
Besides, most people using Software RAID have been using 0.90 for at least two years - so I doubt this would have been much of a problem if the 0.90 patches weren't available for 2.2, which they are.
This is probably th eimportant part. Most heavy RAID 2.2.x users have in fact probably already used the "new" 2.4.x interface for some time.
I do agree with Alan, though: the decision on making that the _official_ 2.2.x interface is a nasty decision. It will screw some people, and they would be right in being unhappy about interface changes in the middle of a stable kernel release.
For 2.2.x I suspect that 0.90 should continue to just be a (common) extra patch.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Hubert Mantel
Right, but now there is a problem: Software RAID. The RAID code of 2.4.0 is not backwards compatible to the one in 2.2.18; if somebody has used 2.4.0 on softraid and discovers some problem, he can not switch back to some official 2.2 kernel. [...]
that is simply not true - at least for the RAID0 and LINEAR mdtools arrays. You can start up 'new' RAID devices via mdtools just fine, even if these new devices have RAID-superblocks. (because those superblocks are at the end of the device, and ext2fs knows the true size of the filesystem.)
you have to keep two sets of configuration files (/etc/raidtab and /etc/mdtab), but that is not new nor unreasonable. The tools do not clash either.
[ the only category impacted are people who are still using the RAID1/RAID4,5 code in the stock 2.2 kernel - i do believe the number of these people is very low, and they should imminently upgrade to the 0.90 driver anyway, for stability and data integrity reasons. ]
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Hubert Mantel
Quoted 4 lines
Right, but now there is a problem: Software RAID. The RAID code of 2.4.0 is not backwards compatible to the one in 2.2.18; if somebody has used 2.4.0 on softraid and discovers some problem, he can not switch back to some official 2.2 kernel. [...]
^^^^^^^^^^^^^^^^^^^^^^^^
Quoted 2 lines · Ingo Molnar
[ the only category impacted are people who are still using the RAID1/RAID4,5 code in the stock 2.2 kernel - i do believe the number of
^^^^^^^^^^^^^^^^^^^^
That's the category Hubert was talking about indeed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Andrea Arcangeli
Quoted 2 lines
[ the only category impacted are people who are still using the RAID1/RAID4,5 code in the stock 2.2 kernel - i do believe the number of
^^^^^^^^^^^^^^^^^^^^That's the category Hubert was talking about indeed.
i understand now - well, there is no reliable RAID1/RAID5 support in the stock 2.2 kernel indeed, you need the 0.90 patch.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Ingo Molnar
i understand now - well, there is no reliable RAID1/RAID5 support in the stock 2.2 kernel indeed, you need the 0.90 patch.
I used raid1 without problems in stock 2.2 kernel. For raid5 I certainly agree ;).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/