Re: Change of policy for future 2.2 driver submissions

Re: Change of policy for future 2.2 driver submissions

[Wayne.Brown]

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" <mpitts@suite224.net> on 01/05/2001 12:50:26 PM

To:   Wayne Brown/Corporate/Altec@Altec
cc:   linux-kernel@vger.kernel.org

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
mpitts@suite224.net






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Nick Holloway]

In <862569CB.0070DDEE.00@smtpnotes.altec.com> Wayne.Brown@altec.com 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'  | Nick.Holloway@pyrites.org.uk
// ^ \\ | http://www.pyrites.org.uk/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Andrea Arcangeli]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Ingo Molnar]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Andrea Arcangeli]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Ingo Molnar]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Linus Torvalds]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Jakob Østergaard]

On Tue, Jan 09, 2001 at 02:54:44PM +0000, 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.

-- 
................................................................
:   jakob@unthought.net   : 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Hubert Mantel]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Wayne.Brown]

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 <tao@acc.umu.se> on 01/08/2001 05:07:08 AM

To:   Wayne Brown/Corporate/Altec@Altec
cc:   Nick Holloway <Nick.Holloway@pyrites.org.uk>, linux-kernel@vger.kernel.org

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[David Weinehall]

On Sun, Jan 07, 2001 at 10:52:48PM -0600, Wayne.Brown@altec.com 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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Wayne.Brown]

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




Nick.Holloway@pyrites.org.uk (Nick Holloway) on 01/06/2001 04:15:53 AM

To:   linux-kernel@vger.kernel.org
cc:    (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: Change of policy for future 2.2 driver submissions



In <862569CB.0070DDEE.00@smtpnotes.altec.com> Wayne.Brown@altec.com 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'  | Nick.Holloway@pyrites.org.uk
// ^ \\ | http://www.pyrites.org.uk/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Matthew D. Pitts]

----- Original Message -----
From: <Wayne.Brown@altec.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Daniel Phillips <phillips@innominate.de>; Mark Hahn
<hahn@coffee.psychology.mcmaster.ca>; <linux-kernel@vger.kernel.org>
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
mpitts@suite224.net


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Wayne.Brown]

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 <alan@lxorguk.ukuu.org.uk> on 01/05/2001 11:15:36 AM

To:   Wayne Brown/Corporate/Altec@Altec
cc:   phillips@innominate.de (Daniel Phillips),
      hahn@coffee.psychology.mcmaster.ca (Mark Hahn),
      linux-kernel@vger.kernel.org

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Linus Torvalds]

In article <3A55447D.995FB159@goingware.com>,
Michael D. Crawford <crawford@goingware.com> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Alan Cox]

> > 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Christoph.Hellwig.]

In article <E14EaSo-00083x-00@the-village.bc.nu> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Alan Cox]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Wayne.Brown]

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 <phillips@innominate.de> on 01/05/2001 06:52:00 AM

To:   Mark Hahn <hahn@coffee.psychology.mcmaster.ca>,
      linux-kernel@vger.kernel.org
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 majordomo@vger.kernel.org
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Daniel Phillips]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Rik van Riel]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Miles Lane]

Michael D. Crawford wrote:

<snip>


> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Change of policy for future 2.2 driver submissions

[Gerhard Mack]

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

gmack@innerfire.net

<>< 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: Change of policy for future 2.2 driver submissions

[Andre Tomt]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Tim Riker]

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" <alan@lxorguk.ukuu.org.uk>
> To: <linux-kernel@vger.kernel.org>
> 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! <g>
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Mark Hahn]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Michael D. Crawford]

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/
crawford@goingware.com

   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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Change of policy for future 2.2 driver submissions

[Nicholas Knight]

----- Original Message -----
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
To: <linux-kernel@vger.kernel.org>
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Change of policy for future 2.2 driver submissions

[Alan Cox]

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...

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/