Re: Change of policy for future 2.2 driver submissions
On Wed, Jan 10, 2001 at 02:17:35AM +0100, Ingo Molnar wrote: > 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/
Re: Change of policy for future 2.2 driver submissions
On Wed, 10 Jan 2001, Andrea Arcangeli wrote: > > [ 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/
Re: Change of policy for future 2.2 driver submissions
> On Tue, 9 Jan 2001, Hubert Mantel wrote: > > 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. [...] On Wed, Jan 10, 2001 at 01:33:10AM +0100, Ingo Molnar wrote: > [ 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/
Re: Change of policy for future 2.2 driver submissions
On Tue, 9 Jan 2001, Hubert Mantel wrote: > 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/
Re: Change of policy for future 2.2 driver submissions
On Wed, 10 Jan 2001, Jakob Østergaard wrote: > > 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/
Re: Change of policy for future 2.2 driver submissions
On Tue, Jan 09, 2001 at 02:54:44PM +, Alan Cox wrote:
> > 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.
--
: [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/
Re: Change of policy for future 2.2 driver submissions
> 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/
Re: Change of policy for future 2.2 driver submissions
Hi, On Fri, Jan 05, Linus Torvalds wrote: [...] > 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. > 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/
Re: Change of policy for future 2.2 driver submissions
Cool! I remember reading about the --dry-run option in the patch man page once, and thinking it would be useful, but then I forgot all about it without ever using it. (Patch is one of those programs I've been using for so many years that my fingers type it automatically and I never think to check out other options.) Thanks for reminding me. I always rename my directories to the current patchlevel, too. But in this case it didn't help me, because I wasn't sure whether the prerelease-to-final was supposed to be applied to 2.4.0-prerelease INSTEAD OF prerelease-diff or IN ADDITION to it. (After all, -test1 through test-12 all had to be applied in order, but the various -testX-pre1, -pre2, etc. patches we've seen always had to be reversed before the next one could be applied.) Rather than take the time to investigate, I took a guess, and obviously guessed wrong about this one. :-) Wayne David Weinehall <[EMAIL PROTECTED]> on 01/08/2001 05:07:08 AM To: Wayne Brown/Corporate/Altec@Altec cc: Nick Holloway <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Change of policy for future 2.2 driver submissions You know, there are reasons why patch has an option called --dry-run... bzcat patch-2.4.0.bz2 | patch -p1 --dry-run [and if everything goes well] bzcat patch-2.4.0.bz2 | patch -p1 [will be relatively painless, as the files will be cached by now...] Is the way I usually apply patches. Oh, and after applying a patch I always rename the directory to match the version of the patch. This way I always know if I have to unapply any pre-patches/test-patches/whatever. - 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/
Re: Change of policy for future 2.2 driver submissions
On Sun, Jan 07, 2001 at 10:52:48PM -0600, [EMAIL PROTECTED] wrote: > > > Actually, I have another reason for using patch-kernel, besides being > inexperienced or lazy: being weird. :-) For some reason, I have an > aversion to downloading complete kernels, and just grab the patches. > That's usually OK, because I apply each patch one at a time, within a > few hours after it comes out. But once in a while I mess up and have > to start over -- like a few days ago, when I forgot to reverse > prelease-diff before trying to apply 2.4.0-prelease-to-final. I got You know, there are reasons why patch has an option called --dry-run... bzcat patch-2.4.0.bz2 | patch -p1 --dry-run [and if everything goes well] bzcat patch-2.4.0.bz2 | patch -p1 [will be relatively painless, as the files will be cached by now...] Is the way I usually apply patches. Oh, and after applying a patch I always rename the directory to match the version of the patch. This way I always know if I have to unapply any pre-patches/test-patches/whatever. > the kernel source tree hosed up so badly that I decided to blow it all > away and get a clean copy. Instead of doing the sensible thing -- > getting a fresh copy of 2.4.0 -- I untarred 2.2.16 (the most recent > tarball I had), reverse-patched it down to 2.2.8, applied > patch-2.2.8-to-2.3.0, used patch-kernel to get up to 2.3.51, then > applied the patches for 2.3.99-pre1 through -pre9 and 2.4.0-test1 > through -test12, and finally 2.4.0-prelease and > 2.4.0-prerelease-to-final. Sure, it's insane, but it's not as tedious Yup, you're one sick little puppy. Way cool :^) > as it sounds, since I put together a script to do all this (and it > doesn't take all that long on my Pentium III, especially if I shut > down X first). Anyway, I've kind of been hoping that now that 2.4.0 > is out, maybe future patches will go back to the x.y.z format so I > could just let patch-kernel do everything. /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: Change of policy for future 2.2 driver submissions
Actually, I have another reason for using patch-kernel, besides being inexperienced or lazy: being weird. :-) For some reason, I have an aversion to downloading complete kernels, and just grab the patches. That's usually OK, because I apply each patch one at a time, within a few hours after it comes out. But once in a while I mess up and have to start over -- like a few days ago, when I forgot to reverse prelease-diff before trying to apply 2.4.0-prelease-to-final. I got the kernel source tree hosed up so badly that I decided to blow it all away and get a clean copy. Instead of doing the sensible thing -- getting a fresh copy of 2.4.0 -- I untarred 2.2.16 (the most recent tarball I had), reverse-patched it down to 2.2.8, applied patch-2.2.8-to-2.3.0, used patch-kernel to get up to 2.3.51, then applied the patches for 2.3.99-pre1 through -pre9 and 2.4.0-test1 through -test12, and finally 2.4.0-prelease and 2.4.0-prerelease-to-final. Sure, it's insane, but it's not as tedious as it sounds, since I put together a script to do all this (and it doesn't take all that long on my Pentium III, especially if I shut down X first). Anyway, I've kind of been hoping that now that 2.4.0 is out, maybe future patches will go back to the x.y.z format so I could just let patch-kernel do everything. Wayne [EMAIL PROTECTED] (Nick Holloway) on 01/06/2001 04:15:53 AM To: [EMAIL PROTECTED] cc:(bcc: Wayne Brown/Corporate/Altec) Subject: Re: Change of policy for future 2.2 driver submissions In <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > Either I'm blind, or especially dense today, or both (quite possible :-) but I > don't see any reference in patch-kernel to the extra version information. > EXTRAVERSION is defined in the kernel Makefile, and I tried using the script > found in the 2.4.0-test1 source like this: > > patch-kernel /usr/src/linux /pub/linux/kernel/v2.4/test-kernels > > but the test-2 and following patches are not applied. All I get is "Current > kernel version is 2.4.0." What am I missing? The distributed version of patch-kernel has only ever known about the "standard" progression x.y.z => x.y.z+1. This all gets horribly broken when Linus gets imaginative with his kernel numbering. I have said before that I thought this was OK, because the people that need to cope with the EXTRAVERSION guff are people on the development branch, and should be able to patch the kernel themselves. The main users of patch-kernel are less experienced people. However, this does conflict with the aim of getting users into testing kernels late in the development branch cycle. It also affects people like me who are lazy. I don't think that getting the kernel version to support the naming scheme du-jour will work, as this would require Linus to update patch-kernel when he dreams up a new scheme -- and Linus is the one person I'm fairly sure does not use it! For myself, I have a version of patch-kernel that does know how to deal with the wacky naming versions (because I'm lazy). In future I'll make this available to anyone that wants to download it for their own use, but I won't push to get it included. A (temporary) location for the current version is: http://www.alfie.demon.co.uk/download/patch-kernel -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - 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/ - 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/
Re: Change of policy for future 2.2 driver submissions
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > Either I'm blind, or especially dense today, or both (quite possible :-) but I > don't see any reference in patch-kernel to the extra version information. > EXTRAVERSION is defined in the kernel Makefile, and I tried using the script > found in the 2.4.0-test1 source like this: > > patch-kernel /usr/src/linux /pub/linux/kernel/v2.4/test-kernels > > but the test-2 and following patches are not applied. All I get is "Current > kernel version is 2.4.0." What am I missing? The distributed version of patch-kernel has only ever known about the "standard" progression x.y.z => x.y.z+1. This all gets horribly broken when Linus gets imaginative with his kernel numbering. I have said before that I thought this was OK, because the people that need to cope with the EXTRAVERSION guff are people on the development branch, and should be able to patch the kernel themselves. The main users of patch-kernel are less experienced people. However, this does conflict with the aim of getting users into testing kernels late in the development branch cycle. It also affects people like me who are lazy. I don't think that getting the kernel version to support the naming scheme du-jour will work, as this would require Linus to update patch-kernel when he dreams up a new scheme -- and Linus is the one person I'm fairly sure does not use it! For myself, I have a version of patch-kernel that does know how to deal with the wacky naming versions (because I'm lazy). In future I'll make this available to anyone that wants to download it for their own use, but I won't push to get it included. A (temporary) location for the current version is: http://www.alfie.demon.co.uk/download/patch-kernel -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - 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/
Re: Change of policy for future 2.2 driver submissions
Either I'm blind, or especially dense today, or both (quite possible :-) but I don't see any reference in patch-kernel to the extra version information. EXTRAVERSION is defined in the kernel Makefile, and I tried using the script found in the 2.4.0-test1 source like this: patch-kernel /usr/src/linux /pub/linux/kernel/v2.4/test-kernels but the test-2 and following patches are not applied. All I get is "Current kernel version is 2.4.0." What am I missing? Wayne "Matthew D. Pitts" <[EMAIL PROTECTED]> on 01/05/2001 12:50:26 PM To: Wayne Brown/Corporate/Altec@Altec cc: [EMAIL PROTECTED] Subject: Re: Change of policy for future 2.2 driver submissions Wayne, The versions of patch-kernel included in 2.3/2.4 support extra version information, so patches from Linus and others (i.e. Alan Cox) can be applied if proper information is placed in the kernel Makefile. Matthew D. Pitts [EMAIL PROTECTED] - 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/
Re: Change of policy for future 2.2 driver submissions
- Original Message - From: <[EMAIL PROTECTED]> To: Alan Cox <[EMAIL PROTECTED]> Cc: Daniel Phillips <[EMAIL PROTECTED]>; Mark Hahn <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, January 05, 2001 12:32 PM Subject: Re: Change of policy for future 2.2 driver submissions > On another subject, is all this new "testXX-preYY" stuff over now that 2.4.0 is > out, and will we be going back to the standard x.y.z numbering scheme? Or is > this another thing that's changed for good? I really miss being able to apply > all the patches at once with linux/scripts/patchkernel. > > Wayne > Wayne, The versions of patch-kernel included in 2.3/2.4 support extra version information, so patches from Linus and others (i.e. Alan Cox) can be applied if proper information is placed in the kernel Makefile. Matthew D. Pitts [EMAIL PROTECTED] - 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/
Re: Change of policy for future 2.2 driver submissions
In article <[EMAIL PROTECTED]>, Michael D. Crawford <[EMAIL PROTECTED]> wrote: > >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/
Re: Change of policy for future 2.2 driver submissions
Well, I got off linux-kernel while 2.0.3x was still current, and didn't return until a few months ago. Apparently the definitions have changed over the past few years. On another subject, is all this new "testXX-preYY" stuff over now that 2.4.0 is out, and will we be going back to the standard x.y.z numbering scheme? Or is this another thing that's changed for good? I really miss being able to apply all the patches at once with linux/scripts/patchkernel. Wayne Alan Cox <[EMAIL PROTECTED]> on 01/05/2001 11:15:36 AM To: Wayne Brown/Corporate/Altec@Altec cc: [EMAIL PROTECTED] (Daniel Phillips), [EMAIL PROTECTED] (Mark Hahn), [EMAIL PROTECTED] Subject: Re: Change of policy for future 2.2 driver submissions > In other words, there's no longer any such thing as a "stable" branch. The > whole point of having separate production and development branches was to have > one in which each succeeding patch could be counted upon to be more reliable By your personal definition of stable 2.0.3x is the current stable kernel. Alan - 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/
Re: Change of policy for future 2.2 driver submissions
> > By your personal definition of stable 2.0.3x is the current stable kernel. > > Btw: Any chance to see an official 2.0.39 soon? > 2.0.39final is out for about half a year now... David sent me one thing to look at before he's happy. So right now Im the guilty party holding it up. Hopefulyl a day or two - 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/
Re: Change of policy for future 2.2 driver submissions
In article <[EMAIL PROTECTED]> you wrote: >> In other words, there's no longer any such thing as a "stable" branch. The >> whole point of having separate production and development branches was to have >> one in which each succeeding patch could be counted upon to be more reliable > By your personal definition of stable 2.0.3x is the current stable kernel. Btw: Any chance to see an official 2.0.39 soon? 2.0.39final is out for about half a year now... Christoph -- Whip me. Beat me. Make me maintain AIX. - 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/
Re: Change of policy for future 2.2 driver submissions
> In other words, there's no longer any such thing as a "stable" branch. The > whole point of having separate production and development branches was to have > one in which each succeeding patch could be counted upon to be more reliable By your personal definition of stable 2.0.3x is the current stable kernel. Alan - 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/
Re: Change of policy for future 2.2 driver submissions
In other words, there's no longer any such thing as a "stable" branch. The whole point of having separate production and development branches was to have one in which each succeeding patch could be counted upon to be more reliable than the last. If new development is going into the "stable" kernels, then there's no way to be certain that the latest patches don't have more bugs than the earlier ones, at least not without thoroughly testing them. And if testing is necessary, then we might as well just use the development kernels for everything, because we have to test them anyway. Wayne Daniel Phillips <[EMAIL PROTECTED]> on 01/05/2001 06:52:00 AM To: Mark Hahn <[EMAIL PROTECTED]>, [EMAIL PROTECTED] cc: (bcc: Wayne Brown/Corporate/Altec) Subject: Re: Change of policy for future 2.2 driver submissions Mark Hahn wrote: > > I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to > ... > > afraid that this may partialy criple 2.2 driver development. > > egads! how can there be "development" on a *stable* kernel line? > > maybe this is the time to reconsider terminology/policy: > does "stable" mean "bugfixes only"? > or does it mean "development kernel for conservatives"? It means development kernel for those who don't have enough time to debug the main kernel as well as their own project. The stable branch tends to be *far* better documented than the bleeding edge branch. Try to find documentation on the all-important page cache, for example. It makes a whole lot of sense to develop in the stable branch, especially for new kernel developers, providing, of course, that the stable branch has the basic capabilities you need for your project. Alan isn't telling anybody which branch to develop in - he's telling people what they have to do if they want their code in his tree. This means that when you develop in the stable branch you've got an extra step to do at the end of your project: port to the unstable branch. This only has to be done once and your code *will* get cleaned up a lot in the process. (It's amazing how the prospect of merging 500 lines of rejected patch tends to concentrate the mind.) I'd even suggest another step after that: port your unstable version back to the stable branch, and both versions will be cleaned up. -- Daniel - 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/ - 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/
Re: Change of policy for future 2.2 driver submissions
Mark Hahn wrote: > > I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to > ... > > afraid that this may partialy criple 2.2 driver development. > > egads! how can there be "development" on a *stable* kernel line? > > maybe this is the time to reconsider terminology/policy: > does "stable" mean "bugfixes only"? > or does it mean "development kernel for conservatives"? It means development kernel for those who don't have enough time to debug the main kernel as well as their own project. The stable branch tends to be *far* better documented than the bleeding edge branch. Try to find documentation on the all-important page cache, for example. It makes a whole lot of sense to develop in the stable branch, especially for new kernel developers, providing, of course, that the stable branch has the basic capabilities you need for your project. Alan isn't telling anybody which branch to develop in - he's telling people what they have to do if they want their code in his tree. This means that when you develop in the stable branch you've got an extra step to do at the end of your project: port to the unstable branch. This only has to be done once and your code *will* get cleaned up a lot in the process. (It's amazing how the prospect of merging 500 lines of rejected patch tends to concentrate the mind.) I'd even suggest another step after that: port your unstable version back to the stable branch, and both versions will be cleaned up. -- Daniel - 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/
Re: Change of policy for future 2.2 driver submissions
On Thu, 4 Jan 2001, Nicholas Knight wrote: > While I understand the reasoning behind this, and might do the > same thing if I was in your position, I feel it may be a > mistake. I personaly do not trust the 2.4.x kernel entirely yet, > and would prefer to wait for 2.4.1 or 2.4.2 before upgrading > from 2.2.18 to ensure last-minute wrinkles have been completely > ironed out, This is *exactly* why Alan's policy change makes sense. If somebody submits a driver bugfix or update for 2.2, but not for 2.4, it'll take FOREVER for 2.4 to become as "trustable" as 2.2... This change, however, will make sure that 2.4 will be as reliable as 2.2 much faster. Unlike 2.2, the core kernel of 2.4 is reliable ... only the peripheral stuff like drivers may be out of date or missing. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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/
Re: Change of policy for future 2.2 driver submissions
Michael D. Crawford wrote: > 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/
RE: Change of policy for future 2.2 driver submissions
On Fri, 5 Jan 2001, Andre Tomt wrote: > I would wait for at least 2.4.10 on production systems (servers in > particular). Not to start a flame or anything (yeah, right), but 2.2.x was > not usable on such systems before it reached 2.2.16 IMHO. > > So, I guess, the "crippling" of driver submissions could hurt me bit, in > theory, which I don't like. ;-) I don't remember 2.2.0 being this well tested... I seem to recall it having a huge list of known bugs at the time too. 2.4.0 seems to have come with much better bug tracking and the time was spent fixing those bugs. Some of the servers I ran at the time wouldn't stabilize until 2.2.7 .. I'm betting on things going much more smoothly (though I won't know for sure since that company lost it's ability to afford me ;) ) Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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/
Re: 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 -- 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/
RE: Change of policy for future 2.2 driver submissions
> I was in your position, I feel it may be a mistake. > I personaly do not trust the 2.4.x kernel entirely yet, and would > prefer to > wait for 2.4.1 or 2.4.2 before upgrading from 2.2.18 to ensure last-minute > wrinkles have been completely ironed out, and I know there are people who > share my viewpoint, and would rather use 2.2.XX for a while yet, and I'm > afraid that this may partialy criple 2.2 driver development. I would wait for at least 2.4.10 on production systems (servers in particular). Not to start a flame or anything (yeah, right), but 2.2.x was not usable on such systems before it reached 2.2.16 IMHO. So, I guess, the "crippling" of driver submissions could hurt me bit, in theory, which I don't like. ;-) -- André. Alfred? http://www.tomt.net - 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/
Re: Change of policy for future 2.2 driver submissions
Nicholas, While I can see what you are asking, here are some comments in Alan's favor: He did not say people can not release 2.2 patches without 2.4 patches. He only said they will not be integrated into the kernel distribution without 2.4 patches. If people continue to develop for 2.2 and have someone else, who is probably less familiar with the hardware, port to 2.4 for them, how soon would you trust the drivers over the 2.2 drivers? In short, I agree with Alan completely. This is the correct move forward to cause 2.4 to become the stable release that everyone will be willing to adopt. Nicholas Knight wrote: > > - Original Message - > From: "Alan Cox" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, January 04, 2001 6:41 PM > Subject: Change of policy for future 2.2 driver submissions > > > > > Linux 2.4 is now out, it is also what people should be concentrating on > first > > when issuing production drivers and driver updates. Effective from this > point > > 2.2 driver submissions or major driver updates will only be accepted if > the > > same code is also available for 2.4. > > > > Someone has to do the merging otherwise, and it isnt going to be me... > > This is the first time I'll have sent anything to this list, and I hadn't > planned on sending anything for a long time to come, but I think in this > case I must toss in my 2cents. > While I understand the reasoning behind this, and might do the same thing if > I was in your position, I feel it may be a mistake. > I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to > wait for 2.4.1 or 2.4.2 before upgrading from 2.2.18 to ensure last-minute > wrinkles have been completely ironed out, and I know there are people who > share my viewpoint, and would rather use 2.2.XX for a while yet, and I'm > afraid that this may partialy criple 2.2 driver development. > It can take little or a lot of time to port a driver from 2.2 to 2.4, and in > some cases people may just not want to do it untill 2.4 has gone through a > little more refining, and that could take a while. > > To sum it up, I just don't think this is the right decision to make, at > least not yet. > My opinion probably won't matter one bit, but I thought I might as well toss > it out there. > > -NK -- Tim Riker - http://rikers.org/ - short SIGs! All I need to know I could have learned in Kindergarten ... if I'd just been paying attention. - 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/
Re: Change of policy for future 2.2 driver submissions
> I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to ... > afraid that this may partialy criple 2.2 driver development. egads! how can there be "development" on a *stable* kernel line? maybe this is the time to reconsider terminology/policy: does "stable" mean "bugfixes only"? or does it mean "development kernel for conservatives"? me, I've run the "progressive" kernel line on production boxes since ~2.3.36. - 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/
Re: Change of policy for future 2.2 driver submissions
- Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 04, 2001 6:41 PM Subject: Change of policy for future 2.2 driver submissions > > Linux 2.4 is now out, it is also what people should be concentrating on first > when issuing production drivers and driver updates. Effective from this point > 2.2 driver submissions or major driver updates will only be accepted if the > same code is also available for 2.4. > > Someone has to do the merging otherwise, and it isnt going to be me... This is the first time I'll have sent anything to this list, and I hadn't planned on sending anything for a long time to come, but I think in this case I must toss in my 2cents. While I understand the reasoning behind this, and might do the same thing if I was in your position, I feel it may be a mistake. I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to wait for 2.4.1 or 2.4.2 before upgrading from 2.2.18 to ensure last-minute wrinkles have been completely ironed out, and I know there are people who share my viewpoint, and would rather use 2.2.XX for a while yet, and I'm afraid that this may partialy criple 2.2 driver development. It can take little or a lot of time to port a driver from 2.2 to 2.4, and in some cases people may just not want to do it untill 2.4 has gone through a little more refining, and that could take a while. To sum it up, I just don't think this is the right decision to make, at least not yet. My opinion probably won't matter one bit, but I thought I might as well toss it out there. -NK - 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/
