Hi,
So here it goes 2.4.16-pre1. Obviously the most important fix is the
iput() one, which probably fixes the filesystem corruption problem people
have been seeing.
Please, people who have been experiencing the fs corruption problems test
this and tell me its now working so I can release a final 2.4.16 ASAP.
- Correctly sync inodes in iput() (Alexander Viro)
- Make pagecache readahead size tunable via /proc (was in -ac tree)
- Fix PPC kernel compilation problems (Paul Mackerras)
Its available at
ftp.xx.kernel.org/pub/linux/kernel/people/marcelo/2.4/testing/
duh. :)
On Sat, 24 Nov 2001, Marcelo Tosatti wrote:
>
> Hi,
>
> So here it goes 2.4.16-pre1. Obviously the most important fix is the
> iput() one, which probably fixes the filesystem corruption problem people
> have been seeing.
>
> Please, people who have been experiencing the fs corruption problems test
> this and tell me its now working so I can release a final 2.4.16 ASAP.
>
>
> - Correctly sync inodes in iput() (Alexander Viro)
> - Make pagecache readahead size tunable via /proc (was in -ac tree)
> - Fix PPC kernel compilation problems (Paul Mackerras)
>
>
On Sat, 2001-11-24 at 13:40, Marcelo Tosatti wrote:
>
> Its available at
> ftp.xx.kernel.org/pub/linux/kernel/people/marcelo/2.4/testing/
>
> duh. :)
Are these going to appear on the front page of kernel.org? all i see
there now is 2.5.1pre1, no 2.4.16pre1.
--
Phil Sorber
AIM: PSUdaemon
IRC: irc.openprojects.net #psulug PSUdaemon
GnuPG: keyserver - pgp.mit.edu
On November 24, 2001 12:36, Phil Sorber wrote:
> On Sat, 2001-11-24 at 13:40, Marcelo Tosatti wrote:
> > Its available at
> > ftp.xx.kernel.org/pub/linux/kernel/people/marcelo/2.4/testing/
> >
> > duh. :)
>
> Are these going to appear on the front page of kernel.org? all i see
> there now is 2.5.1pre1, no 2.4.16pre1.
I doubt that the kernel.org update scripts respect Marcelo's new position by
checking people/marcelo/2.4/testing/ for prepatches. Personally, I think his
prepatches should go in v2.4/testing, and Linus' should go in v2.5/testing,
it'd be much cleaner that way.
-Ryan
On 24 Nov 2001, Phil Sorber wrote:
> On Sat, 2001-11-24 at 13:40, Marcelo Tosatti wrote:
> >
> > Its available at
> > ftp.xx.kernel.org/pub/linux/kernel/people/marcelo/2.4/testing/
> >
> > duh. :)
>
> Are these going to appear on the front page of kernel.org?
They have to...
I'm sure hpa will do that as soon as he has time to...
> Hi,
>
> So here it goes 2.4.16-pre1. Obviously the most important fix is the
> iput() one, which probably fixes the filesystem corruption problem people
> have been seeing.
>
> Please, people who have been experiencing the fs corruption problems test
> this and tell me its now working so I can release a final 2.4.16 ASAP.
>
>
> - Correctly sync inodes in iput() (Alexander Viro)
> - Make pagecache readahead size tunable via /proc (was in -ac tree)
> - Fix PPC kernel compilation problems (Paul Mackerras)
I build Andrea's patch and everything seemed to work fine. I am building 2.4.16-pre1 on two systems right now. What can I check to test the iput() patch or any other patches?
--
Marc A. Ohmann
Digital Solutions, Inc
http://ds6.net
[email protected]
On Sat, 24 Nov 2001, Marc A. Ohmann wrote:
> > Hi,
> >
> > So here it goes 2.4.16-pre1. Obviously the most important fix is the
> > iput() one, which probably fixes the filesystem corruption problem people
> > have been seeing.
> >
> > Please, people who have been experiencing the fs corruption problems test
> > this and tell me its now working so I can release a final 2.4.16 ASAP.
> >
> >
> > - Correctly sync inodes in iput() (Alexander Viro)
> > - Make pagecache readahead size tunable via /proc (was in -ac tree)
> > - Fix PPC kernel compilation problems (Paul Mackerras)
>
> I build Andrea's patch and everything seemed to work fine. I am building 2.4.16-pre1 on two systems right now.
> What can I check to test the iput() patch or any other patches?
To test the iput() patch do some filesystem activity (with lots of files),
reboot the machine, and check if your fs is still sane after that.
The other patches you can't really test I guess: one is for PPC, the other
one is known to work correctly.
Em Sat, Nov 24, 2001 at 03:09:05PM -0600, Marc A. Ohmann escreveu:
> I build Andrea's patch and everything seemed to work fine. I am building
> 2.4.16-pre1 on two systems right now. What can I check to test the
> iput() patch or any other patches?
Well, as both fix the same problem, you can do the very same test you did
to conclude that Andrea's patch made everything work ok for you :)
- Arnaldo
On Sat, 24 Nov 2001, Marcelo Tosatti wrote:
> >
> > Are these going to appear on the front page of kernel.org?
>
> They have to...
>
> I'm sure hpa will do that as soon as he has time to...
I also decided that the suggestion to move the "testing" subdirectory down
to below the kernel that the directory is for is a good idea.
So I moved all the 2.5.x testing stuff to kernel/v2.5/testing, leaving the
old kernel/testing directory basically orphaned.
Marcelo could either take over the old directory (which will make his
pre-patches show up on kernel.org automatically), or preferably just do
the same thing, and make the v2.4 test patches in v2.4/testing (which will
also require support from the site admin, who is probably overworked as-is
with the RAID failures ;)
Linus
Linus Torvalds wrote:
> On Sat, 24 Nov 2001, Marcelo Tosatti wrote:
>
>>>Are these going to appear on the front page of kernel.org?
>>>
>>They have to...
>>
>>I'm sure hpa will do that as soon as he has time to...
>>
>
> I also decided that the suggestion to move the "testing" subdirectory down
> to below the kernel that the directory is for is a good idea.
>
> So I moved all the 2.5.x testing stuff to kernel/v2.5/testing, leaving the
> old kernel/testing directory basically orphaned.
>
> Marcelo could either take over the old directory (which will make his
> pre-patches show up on kernel.org automatically), or preferably just do
> the same thing, and make the v2.4 test patches in v2.4/testing (which will
> also require support from the site admin, who is probably overworked as-is
> with the RAID failures ;)
>
> Linus
>
I like this idea much better than Marcelo's idea, which requires yet a
whole slew of ad hoc knowledge in the scripts -- there is just way too
much of that already. I'll try to implement this.
To summarize:
I'll expect v2.5 prepatches in v2.5/testing; v2.4 prepatches in
v2.4/testing, and nothing else...
-hpa
> I'll expect v2.5 prepatches in v2.5/testing; v2.4 prepatches in
> v2.4/testing, and nothing else...
Marcelo's prepatches are already there, finger @finger.kernel.org still
answers with the old Linus pre-patches in ../testing directory.
Regards (and thanks),
--ricardo
H. Peter Anvin wrote
> To summarize:
>
> I'll expect v2.5 prepatches in v2.5/testing; v2.4 prepatches in
> v2.4/testing, and nothing else...
>
> -hpa
Maybe I'm wrong, but it would be *good* if there were a v2.2/testing
and a v2.0/testing too, since they are maintained...
Best Regards, thanks to all of you for your work
Fran?ois Cami
Followup to: <E167jsx-0005PL-00@localhost>
By author: Ryan Cumming <[email protected]>
In newsgroup: linux.dev.kernel
>
> On November 24, 2001 12:36, Phil Sorber wrote:
> > On Sat, 2001-11-24 at 13:40, Marcelo Tosatti wrote:
> > > Its available at
> > > ftp.xx.kernel.org/pub/linux/kernel/people/marcelo/2.4/testing/
> > >
> > > duh. :)
> >
> > Are these going to appear on the front page of kernel.org? all i see
> > there now is 2.5.1pre1, no 2.4.16pre1.
>
> I doubt that the kernel.org update scripts respect Marcelo's new position by
> checking people/marcelo/2.4/testing/ for prepatches. Personally, I think his
> prepatches should go in v2.4/testing, and Linus' should go in v2.5/testing,
> it'd be much cleaner that way.
>
Indeed it is. Now, let me vent here for a moment...
I WOULD BE BLOODY GRATEFUL IF SOMEONE WOULD ACTUALLY TELL ME THESE
THINGS AHEAD OF TIME FOR A BLOODY CHANGE!!!!!!!!!!!!!!!!!!!!!!!!
Every time something changes, something like 200 lusers write to me to
bitch & whine, and I have to do script maintenance as soon as
possible, despite anything else I may have wanted to do. I am getting
rather sick and tired of having to second-guess the kernel
maintainers, and I would really like to get just a bit of
consideration in that manner.
Thank you,
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
> Indeed it is. Now, let me vent here for a moment...
<snip>
>
> bitch & whine, and I have to do script maintenance as soon as
> possible, despite anything else I may have wanted to do. I am getting
>
Not sure if any one is giving you a hand in maintaining kernel.org site
scripts, but if it'd be of interest i would be more than happy to extend a
hand in helping to maintain the site.
With regards,
Ahmed Masud.
On Saturday, November 24, 2001, at 05:21 , H. Peter Anvin wrote:
> maintainers, and I would really like to get just a bit of
> consideration in that manner.
Heh. Would you settle for a helping hand? Let me know.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Developer/Project Lead
Don't drink and derive." --Unknown http://www.themes.org/
[email protected]
=====================================================================
On Saturday 24 November 2001 19:39, Marcelo Tosatti wrote:
> Hi,
>
> So here it goes 2.4.16-pre1. Obviously the most important fix is the
> iput() one, which probably fixes the filesystem corruption problem people
> have been seeing.
>
> Please, people who have been experiencing the fs corruption problems test
> this and tell me its now working so I can release a final 2.4.16 ASAP.
>
>
> - Correctly sync inodes in iput() (Alexander Viro)
> - Make pagecache readahead size tunable via /proc (was in -ac tree)
> - Fix PPC kernel compilation problems (Paul Mackerras)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi,
After compiling and installing the new 2.4.16-pre1 uname -a reports here
version 2.4.15-greased-turkey, not 2.4.16-pre1.
bash-2.05$ uname -a
Linux nert 2.4.15-greased-turkey #1 Sat Nov 24 23:48:07 CET 2001 i686 unknown
Cheers,
Fred Bulthuis
n00b to this list :)
On Sun, 25 Nov 2001, F.H. Bulthuis wrote:
> After compiling and installing the new 2.4.16-pre1 uname -a reports
> here version 2.4.15-greased-turkey, not 2.4.16-pre1.
Then you should reboot and start the new kernel ;)
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
On Sunday 25 November 2001 00:37, you wrote:
> On Sun, 25 Nov 2001, F.H. Bulthuis wrote:
> > After compiling and installing the new 2.4.16-pre1 uname -a reports
> > here version 2.4.15-greased-turkey, not 2.4.16-pre1.
>
> Then you should reboot and start the new kernel ;)
>
> Rik
Aha., thanks , I'll do that ;)
Fred
Heh, speaking about stuff like this, isnt testing suppost to happen to kernels? I mean, in 2.4.14 we had the file loopback problem (_alot_ of people use that module, its great for building iso images and stuff) and then we have the inode.c bug (which may or may not exist and the fix may or may not actually fix it) then it seems bugs in other sections of the kernel. Whats going on Linus? Stable kernel releases were never this bad before.
On 24-Nov-2001, Linus Torvalds wrote:
>
> On Sat, 24 Nov 2001, Marcelo Tosatti wrote:
> > >
> > > Are these going to appear on the front page of kernel.org?
> >
> > They have to...
> >
> > I'm sure hpa will do that as soon as he has time to...
>
> I also decided that the suggestion to move the "testing" subdirectory down
> to below the kernel that the directory is for is a good idea.
>
> So I moved all the 2.5.x testing stuff to kernel/v2.5/testing, leaving the
> old kernel/testing directory basically orphaned.
>
> Marcelo could either take over the old directory (which will make his
> pre-patches show up on kernel.org automatically), or preferably just do
> the same thing, and make the v2.4 test patches in v2.4/testing (which will
> also require support from the site admin, who is probably overworked as-is
> with the RAID failures ;)
>
> Linus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
er, I think I ment 2.4.13 for the loopback bug... or did that have the ieee parport problem...
On 24-Nov-2001, Patrick McFarland wrote:
> Heh, speaking about stuff like this, isnt testing suppost to happen to kernels? I mean, in 2.4.14 we had the file loopback problem (_alot_ of people use that module, its great for building iso images and stuff) and then we have the inode.c bug (which may or may not exist and the fix may or may not actually fix it) then it seems bugs in other sections of the kernel. Whats going on Linus? Stable kernel releases were never this bad before.
>
> On 24-Nov-2001, Linus Torvalds wrote:
> >
> > On Sat, 24 Nov 2001, Marcelo Tosatti wrote:
> > > >
> > > > Are these going to appear on the front page of kernel.org?
> > >
> > > They have to...
> > >
> > > I'm sure hpa will do that as soon as he has time to...
> >
> > I also decided that the suggestion to move the "testing" subdirectory down
> > to below the kernel that the directory is for is a good idea.
> >
> > So I moved all the 2.5.x testing stuff to kernel/v2.5/testing, leaving the
> > old kernel/testing directory basically orphaned.
> >
> > Marcelo could either take over the old directory (which will make his
> > pre-patches show up on kernel.org automatically), or preferably just do
> > the same thing, and make the v2.4 test patches in v2.4/testing (which will
> > also require support from the site admin, who is probably overworked as-is
> > with the RAID failures ;)
> >
> > Linus
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> Patrick "Diablo-D3" McFarland || [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
2.4.14 - Has deactivate_page linker bug. Fix: Edit loop.c, and delete the deactivate_page() function calls.
2.4.13 - No known bugs.
2.4.12 - Parallel port driver broken in this release.
2.4.11 - Allows local denial of service using symlinks.
http://www.ramdown.com/war/kernel.html
Patrick McFarland wrote:
> er, I think I ment 2.4.13 for the loopback bug... or did that have the ieee parport problem...
>
> On 24-Nov-2001, Patrick McFarland wrote:
> > Heh, speaking about stuff like this, isnt testing suppost to happen to kernels? I mean, in 2.4.14 we had the file loopback problem (_alot_ of people use that module, its great for building iso images and stuff) and then we have the inode.c bug (which may or may not exist and the fix may or may not actually fix it) then it seems bugs in other sections of the kernel. Whats going on Linus? Stable kernel releases were never this bad before.
> >
> > On 24-Nov-2001, Linus Torvalds wrote:
> > >
> > > On Sat, 24 Nov 2001, Marcelo Tosatti wrote:
> > > > >
> > > > > Are these going to appear on the front page of kernel.org?
> > > >
> > > > They have to...
> > > >
> > > > I'm sure hpa will do that as soon as he has time to...
> > >
> > > I also decided that the suggestion to move the "testing" subdirectory down
> > > to below the kernel that the directory is for is a good idea.
> > >
> > > So I moved all the 2.5.x testing stuff to kernel/v2.5/testing, leaving the
> > > old kernel/testing directory basically orphaned.
> > >
> > > Marcelo could either take over the old directory (which will make his
> > > pre-patches show up on kernel.org automatically), or preferably just do
> > > the same thing, and make the v2.4 test patches in v2.4/testing (which will
> > > also require support from the site admin, who is probably overworked as-is
> > > with the RAID failures ;)
> > >
> > > Linus
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [email protected]
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> > >
> >
> > --
> > Patrick "Diablo-D3" McFarland || [email protected]
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> Patrick "Diablo-D3" McFarland || [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Okay, so it was 14 that had the file loopback bug, and 12 that had the ieee bug.Those bugs shouldnt have been in there in the first place! Those are very major potentially show stopping bugs. What If I get up one day, and I cant print? Or build isos? That sounds minor to you, but thats a big thing if say, the linux box is a network print server, or, its the workstation for the guy in the company who builds the iso. And, no, "use the previous kernel" isnt a good excuse. Because what if you get hit with bugs back to back? You'll have to go back to some kernel way way back. Like 2.4.2. The Kernel needs Quality Assurance.
On 24-Nov-2001, war wrote:
> 2.4.14 - Has deactivate_page linker bug. Fix: Edit loop.c, and delete the deactivate_page() function calls.
>
> 2.4.13 - No known bugs.
>
> 2.4.12 - Parallel port driver broken in this release.
>
> 2.4.11 - Allows local denial of service using symlinks.
>
> http://www.ramdown.com/war/kernel.html
>
> Patrick McFarland wrote:
>
> > er, I think I ment 2.4.13 for the loopback bug... or did that have the ieee parport problem...
> >
> > On 24-Nov-2001, Patrick McFarland wrote:
> > > Heh, speaking about stuff like this, isnt testing suppost to happen to kernels? I mean, in 2.4.14 we had the file loopback problem (_alot_ of people use that module, its great for building iso images and stuff) and then we have the inode.c bug (which may or may not exist and the fix may or may not actually fix it) then it seems bugs in other sections of the kernel. Whats going on Linus? Stable kernel releases were never this bad before.
> > >
> > > On 24-Nov-2001, Linus Torvalds wrote:
> > > >
> > > > On Sat, 24 Nov 2001, Marcelo Tosatti wrote:
> > > > > >
> > > > > > Are these going to appear on the front page of kernel.org?
> > > > >
> > > > > They have to...
> > > > >
> > > > > I'm sure hpa will do that as soon as he has time to...
> > > >
> > > > I also decided that the suggestion to move the "testing" subdirectory down
> > > > to below the kernel that the directory is for is a good idea.
> > > >
> > > > So I moved all the 2.5.x testing stuff to kernel/v2.5/testing, leaving the
> > > > old kernel/testing directory basically orphaned.
> > > >
> > > > Marcelo could either take over the old directory (which will make his
> > > > pre-patches show up on kernel.org automatically), or preferably just do
> > > > the same thing, and make the v2.4 test patches in v2.4/testing (which will
> > > > also require support from the site admin, who is probably overworked as-is
> > > > with the RAID failures ;)
> > > >
> > > > Linus
> > > >
> > > > -
> > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > the body of a message to [email protected]
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > Please read the FAQ at http://www.tux.org/lkml/
> > > >
> > >
> > > --
> > > Patrick "Diablo-D3" McFarland || [email protected]
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [email protected]
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> > >
> >
> > --
> > Patrick "Diablo-D3" McFarland || [email protected]
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
If nothing else, the wart in 2.4.15 will make sure people move to the
Marcelo Tosatti tree promptly. Not a bad result...
john alvord
On Sat, 24 Nov 2001, Patrick McFarland wrote:
> Heh, speaking about stuff like this, isnt testing suppost to happen to kernels? I mean, in 2.4.14 we had the file loopback problem (_alot_ of people use that module, its great for building iso images and stuff) and then we have the inode.c bug (which may or may not exist and the fix may or may not actually fix it) then it seems bugs in other sections of the kernel. Whats going on Linus? Stable kernel releases were never this bad before.
>
> On 24-Nov-2001, Linus Torvalds wrote:
> >
> > On Sat, 24 Nov 2001, Marcelo Tosatti wrote:
> > > >
> > > > Are these going to appear on the front page of kernel.org?
> > >
> > > They have to...
> > >
> > > I'm sure hpa will do that as soon as he has time to...
> >
> > I also decided that the suggestion to move the "testing" subdirectory down
> > to below the kernel that the directory is for is a good idea.
> >
> > So I moved all the 2.5.x testing stuff to kernel/v2.5/testing, leaving the
> > old kernel/testing directory basically orphaned.
> >
> > Marcelo could either take over the old directory (which will make his
> > pre-patches show up on kernel.org automatically), or preferably just do
> > the same thing, and make the v2.4 test patches in v2.4/testing (which will
> > also require support from the site admin, who is probably overworked as-is
> > with the RAID failures ;)
> >
> > Linus
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> Patrick "Diablo-D3" McFarland || [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Saturday, November 24, 2001, at 09:41 , Patrick McFarland wrote:
> Okay, so it was 14 that had the file loopback bug, and 12 that had the
> ieee bug.Those bugs shouldnt have been in there in the first place!
> Those are very major potentially show stopping bugs. What If I get up
> one day, and I cant print? Or build isos? That sounds minor to you, but
> thats a big thing if say, the linux box is a network print server, or,
> its the workstation for the guy in the company who builds the iso. And,
> no, "use the previous kernel" isnt a good excuse. Because what if you
> get hit with bugs back to back? You'll have to go back to some kernel
> way way back. Like 2.4.2. The Kernel needs Quality Assurance.
Yes, this is a QA problem. But also .. if you're a smart net/system
admin, you don't go out installing a just released kernel without
letting others bang on it or run it on some test servers. Where I work,
I insist the admins wait at least 1-2 weeks before going to the latest
release unless there's some huge security fix.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Developer/Project Lead
Don't drink and derive." --Unknown http://www.themes.org/
[email protected]
=====================================================================
Patrick McFarland wrote:
> What If I get up one day, and I cant print? Or build isos?
Who would switch kernels on you while you sleep?
> The Kernel needs Quality Assurance.
Yep, and that's what the vendors do for you.
Stick with the tested, QA'd, vendor-supplied
kernel unless you're a developer or a skilled,
adventurous sys admin who reads lkml!
kernel tarballs are NOT for mom -
cu
jjs
On Sat, Nov 24, 2001 at 09:41:15PM -0500, Patrick McFarland wrote:
> Okay, so it was 14 that had the file loopback bug, and 12 that had the ieee bug.Those bugs shouldnt have been in there in the first place! Those are very major potentially show stopping bugs. What If I get up one day, and I cant print? Or build isos? That sounds minor to you, but thats a big thing if say, the linux box is a network print server, or, its the workstation for the guy in the company who builds the iso. And, no, "use the previous kernel" isnt a good excuse. Because what if you get hit with bugs back to back? You'll have to go back to some kernel way way back. Like 2.4.2. The Kernel needs Quality Assurance.
\
Thanks for volunteering. Please publish those results.
On Sun, 25 Nov 2001, F.H. Bulthuis wrote:
> After compiling and installing the new 2.4.16-pre1 uname -a reports
> here version 2.4.15-greased-turkey, not 2.4.16-pre1.
Looks like it was a local problem. Some strange behaviour of a symlink
/usr/src/linux pointing at /usr/src/linux-2.4.16-pre1. But when I entered
/usr/src/linux and did a make menuconfig, make dep etc. it started building
in the linux-2.4.15 directory. Don't know if that's a local fs corruption,
but after entering the /usr/src/linux-2.4.16-pre1 directory it builds correct.
Fred Bulthuis.
On Sat, Nov 24, 2001 at 04:39:15PM -0200, Marcelo Tosatti wrote:
> - Correctly sync inodes in iput() (Alexander Viro)
Given the fact that this bug in a presumably stable linux kernel is
getting quite some attention in the media (electronic and otherwise). It
would be prudent to get out a 2.4.16 which fixes this bug right about
now.
Just my 2 cents...
Dominik Kubla
--
ScioByte GmbH Zum Schiersteiner Grund 2 55127 Mainz (Germany)
Phone: +49 700 724 629 83 Fax: +49 700 724 629 84
1024D/717F16BB A384 F5F1 F566 5716 5485 27EF 3B00 C007 717F 16BB
On Sun, 25 Nov 2001 14:34:49 +0100
Dominik Kubla <[email protected]> wrote:
> On Sat, Nov 24, 2001 at 04:39:15PM -0200, Marcelo Tosatti wrote:
>
> > - Correctly sync inodes in iput() (Alexander Viro)
>
> Given the fact that this bug in a presumably stable linux kernel is
> getting quite some attention in the media (electronic and otherwise). It
> would be prudent to get out a 2.4.16 which fixes this bug right about
> now.
The "problem" effectively arises from _fast_ releasing "stable" versions. I
tend to think there should be a slowdown, not a speedup in stable releases,
just because the weird bugs we saw lately were all found shortly after release.
Maybe it would be a good idea to declare a good-looking pre-version "stable"
after a week delay (for testing) or so, omitting further patches.
I think there is no need to fear "bad" media appearance. It's just what makes
the difference: we try to solve the problem in case one is found _and_ talk
frankly about it. No need to hide.
It isn't really the same as shooting down XP/W2K/NT by type'ing a text-file in
a console-window...
Regards,
Stephan
Dominik Kubla <[email protected]> writes:
> On Sat, Nov 24, 2001 at 04:39:15PM -0200, Marcelo Tosatti wrote:
>
> > - Correctly sync inodes in iput() (Alexander Viro)
>
> Given the fact that this bug in a presumably stable linux kernel is
> getting quite some attention in the media (electronic and otherwise). It
> would be prudent to get out a 2.4.16 which fixes this bug right about
> now.
BTW, what is the correct recovery strategy, assuming 2.4.15 has not
been rebooted yet? Installing a fixed kernel is obviously the first
step. How should one reboot the system to minimize damage? Use a
normal system shutdown (with the -F parameter to forc fsck on next
boot), or go to single user, "touch /forcefsck", sync, wait a minute,
and switching of power?
--
Florian Weimer [email protected]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
On Sun, Nov 25, 2001 at 03:39:08PM +0100, Florian Weimer wrote:
> BTW, what is the correct recovery strategy, assuming 2.4.15 has not
> been rebooted yet? Installing a fixed kernel is obviously the first
> step. How should one reboot the system to minimize damage? Use a
> normal system shutdown (with the -F parameter to forc fsck on next
> boot), or go to single user, "touch /forcefsck", sync, wait a minute,
> and switching of power?
>From Viro's mail (on http://lwn.net/daily/2.4.15-recovery.php3):
| IOW, if you are running 2.4.15 - build a patched kernel, install it and
| do the following:
| * switch to single-user
| * sync
| * umount everything non-buys
| * remount the rest read-only
| * turn the thing off
| * boot with patched kernel or with anything before 2.4.15-pre9
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King <[email protected]> writes:
> | * umount everything non-buys
^^^^^^^^
What does that mean? It's a typo, isn't it?
--
Florian Weimer [email protected]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
On 25 Nov 2001, Florian Weimer wrote:
> Russell King <[email protected]> writes:
>
> > | * umount everything non-buys
> ^^^^^^^^
>
> What does that mean? It's a typo, isn't it?
Sigh... s/ys/sy/
On 25 Nov 2001 15:58:19 +0100
Florian Weimer <[email protected]> wrote:
> Russell King <[email protected]> writes:
>
> > | * umount everything non-buys
> ^^^^^^^^
>
> What does that mean? It's a typo, isn't it?
It should be "non-busy" - i.e., everything that will let you umount it without
a "device is busy" error.
Bruce
On Sun, 25 Nov 2001, Stephan von Krawczynski wrote:
> The "problem" effectively arises from _fast_ releasing "stable" versions. I
> tend to think there should be a slowdown, not a speedup in stable releases,
> just because the weird bugs we saw lately were all found shortly after release.
True, but 2.4.15 should have been renamed 2.4.15-dontuse as soon as the
corruption bug was discovered, even if there is no 2.4.16 available. The
important thing is not to get a new version out quickly, but to prevent
spreading of the bad version. IMHO, of course...
/Tobias
On Sun, 25 Nov 2001, Stephan von Krawczynski wrote:
>
> The "problem" effectively arises from _fast_ releasing "stable" versions.
Actually, I think that is just the _symptom_ of the basic issue: I do not
like being a maintainer.
Let's face it, we had similar problems in 2.2.x, for all the same reasons:
I'm simply not a good maintainer, because I'm too impatient and get too
bored with it.
The fact that I've held on to 2.4.x for too long, mostly due to the VM
problems, really doesn't help. That just makes me _less_ likely to be
careful. Especially when the last known VM problem was fixed (ie the
Oracle highmem deadlock), I had a very strong urge to just "get the d*mn
thing out to Marcelo".
I'm much happier doing development, and what I'm best at for Linux is at
doing the "hard decisions" - and not necessarily because of technical
reasons, but simply because I _can_ make them without too many people
grumbling. An example of this is to do the VM reorg in the first place,
something that at the time a lot of people disagreed with.
But I'm not a good, careful, maintainer. I never claim to be.
I bet you'll see better, more consistent quality from Marcelo.
Linus
On Sun, 25 Nov 2001 10:17:15 -0800 (PST)
Linus Torvalds <[email protected]> wrote:
[about Gods' pure nature] ;-)
lets face it, guys: God gave us the stones, its our free decision if we either
throw them at each other or build a house to live in.
:-)
Well, in fact I'd rather let the Eagles fly in my house, than Rolling the
Stones ...
But that's a personal decision :-)
Take it easy,
Stephan
Hello,
Could someone tell if reiserfs or ext3 filesystems are affected by this?
Teodor Iacob,
Astral TELECOM Internet
On Sun, 25 Nov 2001, Russell King wrote:
> On Sun, Nov 25, 2001 at 03:39:08PM +0100, Florian Weimer wrote:
> > BTW, what is the correct recovery strategy, assuming 2.4.15 has not
> > been rebooted yet? Installing a fixed kernel is obviously the first
> > step. How should one reboot the system to minimize damage? Use a
> > normal system shutdown (with the -F parameter to forc fsck on next
> > boot), or go to single user, "touch /forcefsck", sync, wait a minute,
> > and switching of power?
>
> >From Viro's mail (on http://lwn.net/daily/2.4.15-recovery.php3):
>
> | IOW, if you are running 2.4.15 - build a patched kernel, install it and
> | do the following:
> | * switch to single-user
> | * sync
> | * umount everything non-buys
> | * remount the rest read-only
> | * turn the thing off
> | * boot with patched kernel or with anything before 2.4.15-pre9
>
> --
> Russell King ([email protected]) The developer of ARM Linux
> http://www.arm.linux.org.uk/personal/aboutme.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Em Sun, Nov 25, 2001 at 11:44:11PM +0200, Teodor Iacob escreveu:
> Could someone tell if reiserfs or ext3 filesystems are affected by this?
AFAIK, yes, all filesystems with backing storage are affected.
- Arnaldo
Yeah, but there have been one or two security problems in recent 2.4 kernels. Like the symlink attack one.
On 24-Nov-2001, Mohammad A. Haque wrote:
> On Saturday, November 24, 2001, at 09:41 , Patrick McFarland wrote:
>
> >Okay, so it was 14 that had the file loopback bug, and 12 that had the
> >ieee bug.Those bugs shouldnt have been in there in the first place!
> >Those are very major potentially show stopping bugs. What If I get up
> >one day, and I cant print? Or build isos? That sounds minor to you, but
> >thats a big thing if say, the linux box is a network print server, or,
> >its the workstation for the guy in the company who builds the iso. And,
> >no, "use the previous kernel" isnt a good excuse. Because what if you
> >get hit with bugs back to back? You'll have to go back to some kernel
> >way way back. Like 2.4.2. The Kernel needs Quality Assurance.
>
> Yes, this is a QA problem. But also .. if you're a smart net/system
> admin, you don't go out installing a just released kernel without
> letting others bang on it or run it on some test servers. Where I work,
> I insist the admins wait at least 1-2 weeks before going to the latest
> release unless there's some huge security fix.
>
> --
>
> =====================================================================
> Mohammad A. Haque http://www.haque.net/
> [email protected]
>
> "Alcohol and calculus don't mix. Developer/Project Lead
> Don't drink and derive." --Unknown http://www.themes.org/
> [email protected]
> =====================================================================
>
--
Patrick "Diablo-D3" McFarland || [email protected]
So your saying I should actually trust my distro to build a kernel right? I build my own kernels, I have since day one. But, heres a semi-key point, what happens to vendor patches? Do they ever get folded back into the main tree? mdk and rh I know do alot of patching. Its a waste of effort if the patches arnt looked at. And also, I was using that as a rant example. Ive never had a kernel break for me except for the parport and loopback problems. And then, I just built parport without ieee, and Im not using loopback rightnow anyhow, so its not a big loss.
On 24-Nov-2001, J Sloan wrote:
> Patrick McFarland wrote:
>
> > What If I get up one day, and I cant print? Or build isos?
>
> Who would switch kernels on you while you sleep?
>
> > The Kernel needs Quality Assurance.
>
> Yep, and that's what the vendors do for you.
>
> Stick with the tested, QA'd, vendor-supplied
> kernel unless you're a developer or a skilled,
> adventurous sys admin who reads lkml!
>
> kernel tarballs are NOT for mom -
>
> cu
>
> jjs
>
>
--
Patrick "Diablo-D3" McFarland || [email protected]
Then quit being maintainer. Not to sound rude or anything, but if its effecting your performance of being maintainer, you shouldnt be maintainer in the first place. The Linux kernel is a very important peice of software, not the little project you started many years ago. Its grown beyond what you can manage alone, Linus. Find someone to help you. You cant develop and maintain at the same time. Well, not unless we can clone you, or get rid of whatever real life you have.
On 25-Nov-2001, Linus Torvalds wrote:
>
> On Sun, 25 Nov 2001, Stephan von Krawczynski wrote:
> >
> > The "problem" effectively arises from _fast_ releasing "stable" versions.
>
> Actually, I think that is just the _symptom_ of the basic issue: I do not
> like being a maintainer.
>
> Let's face it, we had similar problems in 2.2.x, for all the same reasons:
> I'm simply not a good maintainer, because I'm too impatient and get too
> bored with it.
>
> The fact that I've held on to 2.4.x for too long, mostly due to the VM
> problems, really doesn't help. That just makes me _less_ likely to be
> careful. Especially when the last known VM problem was fixed (ie the
> Oracle highmem deadlock), I had a very strong urge to just "get the d*mn
> thing out to Marcelo".
>
> I'm much happier doing development, and what I'm best at for Linux is at
> doing the "hard decisions" - and not necessarily because of technical
> reasons, but simply because I _can_ make them without too many people
> grumbling. An example of this is to do the VM reorg in the first place,
> something that at the time a lot of people disagreed with.
>
> But I'm not a good, careful, maintainer. I never claim to be.
>
> I bet you'll see better, more consistent quality from Marcelo.
>
> Linus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
Em Sun, Nov 25, 2001 at 05:07:01PM -0500, Patrick McFarland escreveu:
> Then quit being maintainer.
Read the message again, he did that for 2.2 with Alan and now with Marcelo
for 2.4.
- Arnaldo
>
> Could someone tell if reiserfs or ext3 filesystems are affected by this?
>
yes, the problem isnt in the ext2 or other fs, the problem
is in the fs layer.
-Thiago Rondon
To clarify, I was talking about the 2.5 tree. Linus is technically still (a) maintainer for it.
On 25-Nov-2001, Arnaldo Carvalho de Melo wrote:
> Em Sun, Nov 25, 2001 at 05:07:01PM -0500, Patrick McFarland escreveu:
>
> > Then quit being maintainer.
>
> Read the message again, he did that for 2.2 with Alan and now with Marcelo
> for 2.4.
>
> - Arnaldo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
Patrick McFarland wrote:
> The Linux kernel is a very important peice of software,
So true
> not the little project you started many years ago.
Yes. But I believe Linus does want to manage it. It was very kind of
him to allow us to play with it in the first place. If you're not happy
with that, I believe you're free to leave, exactly the same as you
were free to join.
> Its grown beyond what you can manage alone, Linus.
> Find someone to help you. You cant develop and maintain at the same time.
2.4 is now in the hands of Marcelo, to me that means 2.4 is nearly
"finished", i.e. going into *real* maintenance mode.
> Well, not unless we can clone you, or get rid of whatever real life you have.
I won't comment on that one.
Regards,
Fran?ois Cami
> On 25-Nov-2001, Linus Torvalds wrote:
>
>>On Sun, 25 Nov 2001, Stephan von Krawczynski wrote:
>>
>>>The "problem" effectively arises from _fast_ releasing "stable" versions.
>>>
>>Actually, I think that is just the _symptom_ of the basic issue: I do not
>>like being a maintainer.
>>
>>Let's face it, we had similar problems in 2.2.x, for all the same reasons:
>>I'm simply not a good maintainer, because I'm too impatient and get too
>>bored with it.
>>
>>The fact that I've held on to 2.4.x for too long, mostly due to the VM
>>problems, really doesn't help. That just makes me _less_ likely to be
>>careful. Especially when the last known VM problem was fixed (ie the
>>Oracle highmem deadlock), I had a very strong urge to just "get the d*mn
>>thing out to Marcelo".
>>
>>I'm much happier doing development, and what I'm best at for Linux is at
>>doing the "hard decisions" - and not necessarily because of technical
>>reasons, but simply because I _can_ make them without too many people
>>grumbling. An example of this is to do the VM reorg in the first place,
>>something that at the time a lot of people disagreed with.
>>
>>But I'm not a good, careful, maintainer. I never claim to be.
>>
>>I bet you'll see better, more consistent quality from Marcelo.
>>
>> Linus
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to [email protected]
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>
> On 25-Nov-2001, Linus Torvalds wrote:
> > I bet you'll see better, more consistent quality from Marcelo.
...
> Then quit being maintainer.
Has l-k turned into a write-only medium?
--
Alex Bligh
Em Sun, Nov 25, 2001 at 05:18:18PM -0500, Patrick McFarland escreveu:
> To clarify, I was talking about the 2.5 tree. Linus is technically still
> (a) maintainer for it.
We all know that and thats what he does best: to develop kernels, not
maintain, or do you use a development kernel on your mission critical
servers?
2.4 is not supposed to be bugfixes and new drivers/whatever that don't
touch common stable code, isn't? Thats maintainance. 2.5 is about
development.
- Arnaldo
> On 25-Nov-2001, Arnaldo Carvalho de Melo wrote:
> > Em Sun, Nov 25, 2001 at 05:07:01PM -0500, Patrick McFarland escreveu:
> >
> > > Then quit being maintainer.
> >
> > Read the message again, he did that for 2.2 with Alan and now with Marcelo
> > for 2.4.
Em Sun, Nov 25, 2001 at 08:26:10PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Sun, Nov 25, 2001 at 05:18:18PM -0500, Patrick McFarland escreveu:
>
> > To clarify, I was talking about the 2.5 tree. Linus is technically still
> > (a) maintainer for it.
>
> We all know that and thats what he does best: to develop kernels, not
> maintain, or do you use a development kernel on your mission critical
> servers?
>
> 2.4 is not supposed to be bugfixes and new drivers/whatever that don't
Aplogies, above it should be "2.4 is supposed to", of course :)
> touch common stable code, isn't? Thats maintainance. 2.5 is about
> development.
Again, Ill clarify my possition, I didnt mean to slam on Linus, but its too big
for him to maintain AND code for. As much as I would like him to maintain it,
he is a human, like us. Well, most of us. Im still wondering about ac. ;)
And he still is technically maintainer for the 2.5 kernel because he hasnt officially named anyone else. And no, im not saying 2.5 is in maintence mode, but you have to maintain code already written to improve it. Recoding falls under maintance, belive it or not.
And yes, I think Linus is cool for letting all of us use the kernel and hack the kernel and all the other geek goodness. And dont take this as Im slamming the kernel either. But I mean, we need more dedicated kernels coder. Linus just happens to be (imho) the best kernel coder we have.
On 25-Nov-2001, Fran?ois Cami wrote:
> Patrick McFarland wrote:
>
> >The Linux kernel is a very important peice of software,
>
>
> So true
>
> >not the little project you started many years ago.
>
>
> Yes. But I believe Linus does want to manage it. It was very kind of
> him to allow us to play with it in the first place. If you're not happy
> with that, I believe you're free to leave, exactly the same as you
> were free to join.
>
> >Its grown beyond what you can manage alone, Linus.
>
> >Find someone to help you. You cant develop and maintain at the same time.
>
>
> 2.4 is now in the hands of Marcelo, to me that means 2.4 is nearly
> "finished", i.e. going into *real* maintenance mode.
>
> >Well, not unless we can clone you, or get rid of whatever real life you
> >have.
>
>
> I won't comment on that one.
>
> Regards,
>
> Fran?ois Cami
>
>
> >On 25-Nov-2001, Linus Torvalds wrote:
> >
> >>On Sun, 25 Nov 2001, Stephan von Krawczynski wrote:
> >>
> >>>The "problem" effectively arises from _fast_ releasing "stable" versions.
> >>>
> >>Actually, I think that is just the _symptom_ of the basic issue: I do not
> >>like being a maintainer.
> >>
> >>Let's face it, we had similar problems in 2.2.x, for all the same reasons:
> >>I'm simply not a good maintainer, because I'm too impatient and get too
> >>bored with it.
> >>
> >>The fact that I've held on to 2.4.x for too long, mostly due to the VM
> >>problems, really doesn't help. That just makes me _less_ likely to be
> >>careful. Especially when the last known VM problem was fixed (ie the
> >>Oracle highmem deadlock), I had a very strong urge to just "get the d*mn
> >>thing out to Marcelo".
> >>
> >>I'm much happier doing development, and what I'm best at for Linux is at
> >>doing the "hard decisions" - and not necessarily because of technical
> >>reasons, but simply because I _can_ make them without too many people
> >>grumbling. An example of this is to do the VM reorg in the first place,
> >>something that at the time a lot of people disagreed with.
> >>
> >>But I'm not a good, careful, maintainer. I never claim to be.
> >>
> >>I bet you'll see better, more consistent quality from Marcelo.
> >>
> >> Linus
> >>
> >>-
> >>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>the body of a message to [email protected]
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>Please read the FAQ at http://www.tux.org/lkml/
> >>
> >>
> >
>
>
>
--
Patrick "Diablo-D3" McFarland || [email protected]
On 25-Nov-2001, Patrick McFarland wrote:
> Again, Ill clarify my possition, I didnt mean to slam on Linus, but its too big
Well, its great to know I cant spell. =) s/possition/position/
> for him to maintain AND code for. As much as I would like him to maintain it,
> he is a human, like us. Well, most of us. Im still wondering about ac. ;)
>
> And he still is technically maintainer for the 2.5 kernel because he hasnt officially named anyone else. And no, im not saying 2.5 is in maintence mode, but you have to maintain code already written to improve it. Recoding falls under maintance, belive it or not.
>
> And yes, I think Linus is cool for letting all of us use the kernel and hack the kernel and all the other geek goodness. And dont take this as Im slamming the kernel either. But I mean, we need more dedicated kernels coder. Linus just happens to be (imho) the best kernel coder we have.
>
>
> On 25-Nov-2001, Fran?ois Cami wrote:
> > Patrick McFarland wrote:
> >
> > >The Linux kernel is a very important peice of software,
> >
> >
> > So true
> >
> > >not the little project you started many years ago.
> >
> >
> > Yes. But I believe Linus does want to manage it. It was very kind of
> > him to allow us to play with it in the first place. If you're not happy
> > with that, I believe you're free to leave, exactly the same as you
> > were free to join.
> >
> > >Its grown beyond what you can manage alone, Linus.
> >
> > >Find someone to help you. You cant develop and maintain at the same time.
> >
> >
> > 2.4 is now in the hands of Marcelo, to me that means 2.4 is nearly
> > "finished", i.e. going into *real* maintenance mode.
> >
> > >Well, not unless we can clone you, or get rid of whatever real life you
> > >have.
> >
> >
> > I won't comment on that one.
> >
> > Regards,
> >
> > Fran?ois Cami
> >
> >
> > >On 25-Nov-2001, Linus Torvalds wrote:
> > >
> > >>On Sun, 25 Nov 2001, Stephan von Krawczynski wrote:
> > >>
> > >>>The "problem" effectively arises from _fast_ releasing "stable" versions.
> > >>>
> > >>Actually, I think that is just the _symptom_ of the basic issue: I do not
> > >>like being a maintainer.
> > >>
> > >>Let's face it, we had similar problems in 2.2.x, for all the same reasons:
> > >>I'm simply not a good maintainer, because I'm too impatient and get too
> > >>bored with it.
> > >>
> > >>The fact that I've held on to 2.4.x for too long, mostly due to the VM
> > >>problems, really doesn't help. That just makes me _less_ likely to be
> > >>careful. Especially when the last known VM problem was fixed (ie the
> > >>Oracle highmem deadlock), I had a very strong urge to just "get the d*mn
> > >>thing out to Marcelo".
> > >>
> > >>I'm much happier doing development, and what I'm best at for Linux is at
> > >>doing the "hard decisions" - and not necessarily because of technical
> > >>reasons, but simply because I _can_ make them without too many people
> > >>grumbling. An example of this is to do the VM reorg in the first place,
> > >>something that at the time a lot of people disagreed with.
> > >>
> > >>But I'm not a good, careful, maintainer. I never claim to be.
> > >>
> > >>I bet you'll see better, more consistent quality from Marcelo.
> > >>
> > >> Linus
> > >>
> > >>-
> > >>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > >>the body of a message to [email protected]
> > >>More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >>Please read the FAQ at http://www.tux.org/lkml/
> > >>
> > >>
> > >
> >
> >
> >
>
> --
> Patrick "Diablo-D3" McFarland || [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
Patrick McFarland wrote:
> So your saying I should actually trust my distro to build a kernel right?
Depends on how paranoid you are - I find the
red hat kernels to be a safe, if boring choice.
> I build my own kernels, I have since day one.
Sounds like you would have done better to use
the vendor suppplied kernel in this case -
> But, heres a semi-key point, what happens to vendor patches? Do they ever get folded back into the main tree?
Many do, some don't.
Actual bug fixes get folded into the main tree,
but things like the e100 driver, the dell perc
raid drivers, the tux webserver, the linux
vertual server etc that are all in the red hat
kernel may never be in mainstream.
I would sure like to see tux in main kernel,
since it's superior to the khttpd that's part
of the mainline tree.
But things like the e100 driver I could live
without if eepro100 gets to the point where
it works just as well.
cu
jjs
I have an eepro100 in my box, but I dont use it, I dont have a network. =)
Im actually wondering if it works.
On 25-Nov-2001, J Sloan wrote:
> Patrick McFarland wrote:
>
> > So your saying I should actually trust my distro to build a kernel right?
>
> Depends on how paranoid you are - I find the
> red hat kernels to be a safe, if boring choice.
>
> > I build my own kernels, I have since day one.
>
> Sounds like you would have done better to use
> the vendor suppplied kernel in this case -
>
> > But, heres a semi-key point, what happens to vendor patches? Do they ever get folded back into the main tree?
>
> Many do, some don't.
>
> Actual bug fixes get folded into the main tree,
> but things like the e100 driver, the dell perc
> raid drivers, the tux webserver, the linux
> vertual server etc that are all in the red hat
> kernel may never be in mainstream.
>
> I would sure like to see tux in main kernel,
> since it's superior to the khttpd that's part
> of the mainline tree.
>
> But things like the e100 driver I could live
> without if eepro100 gets to the point where
> it works just as well.
>
> cu
>
> jjs
>
>
--
Patrick "Diablo-D3" McFarland || [email protected]
On Sun, Nov 25, 2001 at 10:17:15AM -0800, Linus Torvalds wrote:
>
> On Sun, 25 Nov 2001, Stephan von Krawczynski wrote:
> >
> > The "problem" effectively arises from _fast_ releasing "stable" versions.
>
> Actually, I think that is just the _symptom_ of the basic issue: I do not
> like being a maintainer.
>
Ok, here's *another* suggestion for future working of stable and development
kernels...
Linus,
You admit that you do not like to maintain. We have seen that, and
unfortunately for 2.4 it is true.
Personally, I think that 2.4 was released too early. It was when the
Internet hype was going full force, and nobody (including myself) could be
faulted for getting swept up in the wave that it was.
I'd like to suggest two possibilities.
1) Develop 2.5 until it is ready to be 2.6 and immediately give it over to
a maintainer, and start 2.7.
2) Develop 2.5 until it has the features you want to go into 2.6, and give
it over to the future 2.6 maintainer to stabalize and release it. (there
would be two develoment kernel at the same time for a short period with this)
With both you would get to do what you like and won't get bored with, and
let people share their latest code for many to see.
Linus, can you say if you plan to do anything like this?
MF
Anyhow, back to the original problem, it seems that everyone thinks you can devlope code and not have to maintain it at the same time. If linus doesnt maintain the 2.5 tree while he develops it, it will turn into an unweildly bloated mess. Now, from what I understand, linus doesnt wanna maintain the code, and thats why I think he should have someone to help him maintain the 2.5 tree while he develops it. As a project gets bigger, no matter if its the stable tree or development tree, it needs to be constantly trimmed and pruned like a real tree.
On 25-Nov-2001, Patrick McFarland wrote:
> I have an eepro100 in my box, but I dont use it, I dont have a network. =)
> Im actually wondering if it works.
>
> On 25-Nov-2001, J Sloan wrote:
> > Patrick McFarland wrote:
> >
> > > So your saying I should actually trust my distro to build a kernel right?
> >
> > Depends on how paranoid you are - I find the
> > red hat kernels to be a safe, if boring choice.
> >
> > > I build my own kernels, I have since day one.
> >
> > Sounds like you would have done better to use
> > the vendor suppplied kernel in this case -
> >
> > > But, heres a semi-key point, what happens to vendor patches? Do they ever get folded back into the main tree?
> >
> > Many do, some don't.
> >
> > Actual bug fixes get folded into the main tree,
> > but things like the e100 driver, the dell perc
> > raid drivers, the tux webserver, the linux
> > vertual server etc that are all in the red hat
> > kernel may never be in mainstream.
> >
> > I would sure like to see tux in main kernel,
> > since it's superior to the khttpd that's part
> > of the mainline tree.
> >
> > But things like the e100 driver I could live
> > without if eepro100 gets to the point where
> > it works just as well.
> >
> > cu
> >
> > jjs
> >
> >
>
> --
> Patrick "Diablo-D3" McFarland || [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
On Sun, Nov 25, 2001 at 05:07:01PM -0500, Patrick McFarland wrote:
> Then quit being maintainer.
I for one believe that Linus was the best person to lead Linux
through the 2.4 series stabilization. It was bumpy, but who else
could have pulled off the rather deep changes that put 2.4 on firmer
footing? On the down side, he released some kernels with small but
annoying bugs. A small price, in my estimation. Hardly grounds for
disqualification.
If this is such a concern for you, form a post-Linus QA group that
certifies Linus kernels after testing them and applying small
bug-fixes. Then, you get the benefits of Linus's judgement without
the brown paper bags. Sounds like a win all around.
If you want to knock Linus[1], I hope you can do better than
complaining about a few bugs. Demonstrate that Linux would be
better off long-term if Linus had dropped 2.4 after 2.4.0. I
strongly doubt you can make that case.
Andrew
[1] Not that it matters in the end, because it's his kernel. But at
least you should make a respectable argument.
Oh, and I forgot to mention, its usually (imho) the maintainer's job to write.. *gasp* documentation. I know we all hate to do it, but someone has to. And the kernel docs are... enemic, at best.
On 25-Nov-2001, Patrick McFarland wrote:
> Anyhow, back to the original problem, it seems that everyone thinks you can devlope code and not have to maintain it at the same time. If linus doesnt maintain the 2.5 tree while he develops it, it will turn into an unweildly bloated mess. Now, from what I understand, linus doesnt wanna maintain the code, and thats why I think he should have someone to help him maintain the 2.5 tree while he develops it. As a project gets bigger, no matter if its the stable tree or development tree, it needs to be constantly trimmed and pruned like a real tree.
>
>
> On 25-Nov-2001, Patrick McFarland wrote:
> > I have an eepro100 in my box, but I dont use it, I dont have a network. =)
> > Im actually wondering if it works.
> >
> > On 25-Nov-2001, J Sloan wrote:
> > > Patrick McFarland wrote:
> > >
> > > > So your saying I should actually trust my distro to build a kernel right?
> > >
> > > Depends on how paranoid you are - I find the
> > > red hat kernels to be a safe, if boring choice.
> > >
> > > > I build my own kernels, I have since day one.
> > >
> > > Sounds like you would have done better to use
> > > the vendor suppplied kernel in this case -
> > >
> > > > But, heres a semi-key point, what happens to vendor patches? Do they ever get folded back into the main tree?
> > >
> > > Many do, some don't.
> > >
> > > Actual bug fixes get folded into the main tree,
> > > but things like the e100 driver, the dell perc
> > > raid drivers, the tux webserver, the linux
> > > vertual server etc that are all in the red hat
> > > kernel may never be in mainstream.
> > >
> > > I would sure like to see tux in main kernel,
> > > since it's superior to the khttpd that's part
> > > of the mainline tree.
> > >
> > > But things like the e100 driver I could live
> > > without if eepro100 gets to the point where
> > > it works just as well.
> > >
> > > cu
> > >
> > > jjs
> > >
> > >
> >
> > --
> > Patrick "Diablo-D3" McFarland || [email protected]
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> Patrick "Diablo-D3" McFarland || [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
On Sun, Nov 25, 2001 at 07:31:55PM -0500, Patrick McFarland wrote:
> Oh, and I forgot to mention, its usually (imho) the maintainer's
> job to write.. *gasp* documentation. I know we all hate to do it,
> but someone has to. And the kernel docs are... enemic, at best.
Sweet. You volunteering to be Documentation maintainer then?
(As well as QA)
--
CaT "As you can expect it's really affecting my sex life. I can't help
it. Each time my wife initiates sex, these ejaculating hippos keep
floating through my mind."
- Mohd. Binatang bin Goncang, Singapore Zoological Gardens
"H. Peter Anvin" <[email protected]> said:
[...]
> To summarize:
>
> I'll expect v2.5 prepatches in v2.5/testing; v2.4 prepatches in
> v2.4/testing, and nothing else...
How about 2.2, and 2.0? I understand they are still being maintained...
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Horst von Brand wrote:
> "H. Peter Anvin" <[email protected]> said:
>
> [...]
>
>
>>To summarize:
>>
>>I'll expect v2.5 prepatches in v2.5/testing; v2.4 prepatches in
>>v2.4/testing, and nothing else...
>>
>
> How about 2.2, and 2.0? I understand they are still being maintained...
>
That's up to the 2.2 and 2.0 maintainers.
-hpa
David Weinehall wrote:
> On Sun, Nov 25, 2001 at 09:49:46PM -0300, Horst von Brand wrote:
>
>>"H. Peter Anvin" <[email protected]> said:
>>
>>[...]
>>
>>
>>>To summarize:
>>>
>>>I'll expect v2.5 prepatches in v2.5/testing; v2.4 prepatches in
>>>v2.4/testing, and nothing else...
>>>
>>How about 2.2, and 2.0? I understand they are still being maintained...
>>
>
> Well, if people want me to, I can put my prepatches in v2.0/testing.
>
That would be a Good Thing[TM] I think.
-hpa
On Sun, Nov 25, 2001 at 09:49:46PM -0300, Horst von Brand wrote:
> "H. Peter Anvin" <[email protected]> said:
>
> [...]
>
> > To summarize:
> >
> > I'll expect v2.5 prepatches in v2.5/testing; v2.4 prepatches in
> > v2.4/testing, and nothing else...
>
> How about 2.2, and 2.0? I understand they are still being maintained...
Well, if people want me to, I can put my prepatches in v2.0/testing.
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
For the 52 and a half time, Im not trying to nock Linus. I think hes possibly the best coder we have. (if not the best, atleast in the top 3) But he isnt the best choice of maintainer. And yeah, he did pretty well with 2.4, but it wasnt as good as it could have been. And also, ive been noticing, alot of people disagree with me on this, that the head developer shouldnt be the head maintainer. But how many projects that are this large can you name? Like, i dunno, xfree? That has questionable maintainability. Gnome? KDE? They are fairing okay, but It could be better. And I like the kernel qa group idea, but where would we get the people to be on it? ac and lt are usually too busy, tho, atleast with ac (in top 3 of coders, best linux maintainer we have ever had) 2.5 would get maintained well so linus can focus on coding like I belive he should be. Im a coder myself, so I know how hard it is to maintain a project when it gets big. (I kinda get bored of it like linus does)
Also, alot of people have been saying that I dont know about the section maintainers, like that dave m guy is a maintainer for the network stuff, im talking more of a kernel wide maintainer. Which brings another point. We have per section maintainers, but no real dedicated development tree kernel wide maintainer.
On 25-Nov-2001, Andrew Pimlott wrote:
> On Sun, Nov 25, 2001 at 05:07:01PM -0500, Patrick McFarland wrote:
> > Then quit being maintainer.
>
> I for one believe that Linus was the best person to lead Linux
> through the 2.4 series stabilization. It was bumpy, but who else
> could have pulled off the rather deep changes that put 2.4 on firmer
> footing? On the down side, he released some kernels with small but
> annoying bugs. A small price, in my estimation. Hardly grounds for
> disqualification.
>
> If this is such a concern for you, form a post-Linus QA group that
> certifies Linus kernels after testing them and applying small
> bug-fixes. Then, you get the benefits of Linus's judgement without
> the brown paper bags. Sounds like a win all around.
>
> If you want to knock Linus[1], I hope you can do better than
> complaining about a few bugs. Demonstrate that Linux would be
> better off long-term if Linus had dropped 2.4 after 2.4.0. I
> strongly doubt you can make that case.
>
> Andrew
>
> [1] Not that it matters in the end, because it's his kernel. But at
> least you should make a respectable argument.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
On Sunday, November 25, 2001, at 05:18 , Patrick McFarland wrote:
> To clarify, I was talking about the 2.5 tree. Linus is technically
> still (a) maintainer for it.
ok, now i think you're just being a dick. he's developing 2.5 .. not
maintaining.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Developer/Project Lead
Don't drink and derive." --Unknown http://www.themes.org/
[email protected]
=====================================================================
hmm...killfile just got one more entry...
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Patrick
McFarland
Sent: Sunday, November 25, 2001 4:57 PM
To: Andrew Pimlott
Cc: [email protected]
Subject: Re: Linux 2.4.16-pre1
For the 52 and a half time, Im not trying to nock Linus. I think hes
possibly the best coder we have. (if not the best, atleast in the top 3)
But he isnt the best choice of maintainer. And yeah, he did pretty well
with 2.4, but it wasnt as good as it could have been. And also, ive been
noticing, alot of people disagree with me on this, that the head
developer shouldnt be the head maintainer. But how many projects that
are this large can you name? Like, i dunno, xfree? That has questionable
maintainability. Gnome? KDE? They are fairing okay, but It could be
better. And I like the kernel qa group idea, but where would we get the
people to be on it? ac and lt are usually too busy, tho, atleast with ac
(in top 3 of coders, best linux maintainer we have ever had) 2.5 would
get maintained well so linus can focus on coding like I belive he should
be. Im a coder myself, so I know how hard it is to maintain a project
when it gets big. (I kinda get bored of it like linus does)
Also, alot of people have been saying that I dont know about the section
maintainers, like that dave m guy is a maintainer for the network stuff,
im talking more of a kernel wide maintainer. Which brings another point.
We have per section maintainers, but no real dedicated development tree
kernel wide maintainer.
No, you are. Sorry to say that but you are. Im probably maybe one of 10 people on this whole planet that would like to see the kernel become more than it is, and would actually help doing it. Obviously, the whole damn community is having problems with me disagreeing with it, so screw it. You guys blew it.
On 25-Nov-2001, Mohammad A. Haque wrote:
> On Sunday, November 25, 2001, at 05:18 , Patrick McFarland wrote:
>
> >To clarify, I was talking about the 2.5 tree. Linus is technically
> >still (a) maintainer for it.
>
> ok, now i think you're just being a dick. he's developing 2.5 .. not
> maintaining.
> --
>
> =====================================================================
> Mohammad A. Haque http://www.haque.net/
> [email protected]
>
> "Alcohol and calculus don't mix. Developer/Project Lead
> Don't drink and derive." --Unknown http://www.themes.org/
> [email protected]
> =====================================================================
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
On Sunday, November 25, 2001, at 08:33 , Patrick McFarland wrote:
> No, you are. Sorry to say that but you are. Im probably maybe one of 10
> people on
I know I am. No new news here. =)
> this whole planet that would like to see the kernel become more than it
> is, and would actually help doing it. Obviously, the whole damn
> community is having problems with me disagreeing with it, so screw it.
> You guys blew it.
Well, the fact that you lashed out saying Linus shouldn't be maintainer
for 2.5 is just completely ludicrous.
For one, it's the developmental tree. There's nothing to maintain. No
one should be using it on productions boxes. No distribution should be
including it with any of their released product.
Second, where do you draw the line between development and maintenance
on a dev tree?
def. maintenance: The work of keeping something in proper
condition; upkeep.
* Linus develops new driver model.
* Linus updates basic drivers to work with new driver model so
kernel can at least compile so he can see if driver model is good.
*slap on Linus' wrist* You're not supposed to be doing maintenance.
I also don't see how you propose that these two tasks be split up for
2.5. You don't provide any backing and you're surprised the whole group
is disagreeing with you?
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Developer/Project Lead
Don't drink and derive." --Unknown http://www.themes.org/
[email protected]
=====================================================================
On Sun, 25 Nov 2001, Mike Fedyk wrote:
>
> Personally, I think that 2.4 was released too early. It was when the
> Internet hype was going full force, and nobody (including myself) could be
> faulted for getting swept up in the wave that it was.
That's not the problem, I think.
2.4.0 was appropriate for the time. The problem with _any_ big release is
that the people you _really_ want to test it won't test it until it is
stable, and you cannot make it stable before you have lots of testers. A
basic chicken-and-egg problem, in short.
You find the same thing (to a smaller degree) with the pre-patches, where
a lot more people end up testing the non-pre-patches, and inevitably there
are more percieved problems with the "real" version than with the
pre-patch. Just statistically you should realize that that is not actually
true ;)
> 1) Develop 2.5 until it is ready to be 2.6 and immediately give it over to
> a maintainer, and start 2.7.
I'd love to do that, but it doesn't really work very well. Simply because
whenever the "stable" fork happens, there are going to be issues that the
bleeding-edge guard didn't notice, or didn't realize how they bite people
in the real world.
So I could throw a 2.6 directly over the fence, and start a 2.7 series,
but that would have two really killer problems
(a) I really don't like giving something bad to whoever gets to be
maintainer of the stable kernel. It just doesn't work that way:
whoever would be willing to maintain such a stable kernel would be a
real sucker and a glutton for punishment.
(b) Even if I found a glutton for punishment that was intelligent enough
in other ways to be a good maintainer, the _development_ tree too
needs to start off from a "known reasonably good" point. It doesn't
have to be perfect, but it needs to be _known_.
For good of for bad, we actually have that now with 2.4.x - the system
does look fairly stable, with just some silly problems that have known
solutions and aren't a major pain to handle. So the 2.5.x release is off
to a good start, which it simply wouldn't have had if I had just cut over
from 2.4.0.
The _real_ solution is to make fewer fundamental changes between stable
kernels, and that's a real solution that I expect to become more and more
realistic as the kernel stabilizes. I already expect 2.5 to have a _lot_
less fundamental changes than the 2.3.x tree ever had - the SMP
scaliability efforts and page-cachification between 2.2.x and 2.4.x is
really quite a big change.
But you also have to realize that "fewer fundamental changes" is a mark of
a system that isn't evolving as quickly, and that is reaching middle age.
We are probably not quite there yet ;)
Linus
On Sun, Nov 25, 2001 at 07:58:41PM -0800, Linus Torvalds wrote:
>
> On Sun, 25 Nov 2001, Mike Fedyk wrote:
> >
> > Personally, I think that 2.4 was released too early. It was when the
> > Internet hype was going full force, and nobody (including myself) could be
> > faulted for getting swept up in the wave that it was.
>
> That's not the problem, I think.
>
> 2.4.0 was appropriate for the time. The problem with _any_ big release is
> that the people you _really_ want to test it won't test it until it is
> stable, and you cannot make it stable before you have lots of testers. A
> basic chicken-and-egg problem, in short.
>
True.
> You find the same thing (to a smaller degree) with the pre-patches, where
> a lot more people end up testing the non-pre-patches, and inevitably there
> are more percieved problems with the "real" version than with the
> pre-patch. Just statistically you should realize that that is not actually
> true ;)
>
Unless you look at the *very* small amount of time between 2.4.15-pre9 and
-final. As noted by Rusty (first one to come to mind)... But what is done
is history.
> > 1) Develop 2.5 until it is ready to be 2.6 and immediately give it over to
> > a maintainer, and start 2.7.
>
> I'd love to do that, but it doesn't really work very well. Simply because
> whenever the "stable" fork happens, there are going to be issues that the
> bleeding-edge guard didn't notice, or didn't realize how they bite people
> in the real world.
>
> So I could throw a 2.6 directly over the fence, and start a 2.7 series,
> but that would have two really killer problems
>
> (a) I really don't like giving something bad to whoever gets to be
> maintainer of the stable kernel. It just doesn't work that way:
> whoever would be willing to maintain such a stable kernel would be a
> real sucker and a glutton for punishment.
>
> (b) Even if I found a glutton for punishment that was intelligent enough
> in other ways to be a good maintainer, the _development_ tree too
> needs to start off from a "known reasonably good" point. It doesn't
> have to be perfect, but it needs to be _known_.
>
> For good of for bad, we actually have that now with 2.4.x - the system
> does look fairly stable, with just some silly problems that have known
> solutions and aren't a major pain to handle. So the 2.5.x release is off
> to a good start, which it simply wouldn't have had if I had just cut over
> from 2.4.0.
>
> The _real_ solution is to make fewer fundamental changes between stable
> kernels, and that's a real solution that I expect to become more and more
> realistic as the kernel stabilizes. I already expect 2.5 to have a _lot_
> less fundamental changes than the 2.3.x tree ever had - the SMP
> scaliability efforts and page-cachification between 2.2.x and 2.4.x is
> really quite a big change.
>
Thank you.
Now all we need is a road map for the next ten or so dev kernels and many of
the questions will be answered... What patches will go in what version, and
in what order?
> But you also have to realize that "fewer fundamental changes" is a mark of
> a system that isn't evolving as quickly, and that is reaching middle age.
> We are probably not quite there yet ;)
>
Yep. It looks like there are some rather large changes in the works for 2.5
though. Time will tell, and a LWN news story in about 1-2 years will be very
insteresting indeed.
MF
----- Original Message -----
From: "Arnaldo Carvalho de Melo" <[email protected]>
To: "Linus Torvalds" <[email protected]>;
<[email protected]>
Sent: Sunday, November 25, 2001 11:13 PM
Subject: Re: Linux 2.4.16-pre1
> Em Sun, Nov 25, 2001 at 05:07:01PM -0500, Patrick McFarland escreveu:
>
> > Then quit being maintainer.
>
> Read the message again, he did that for 2.2 with Alan and now with Marcelo
> for 2.4.
Yup.. and the 2.5 tree really is a "toy" tree, so if Linus' impatience
shines through on that one, it's no big deal. I'm looking forward to 2.5, as
I plan to take a more active role in Linux developement now, and not just
sitting here reading lkml.
Btw, anyone having some cool stuff to donate to me? I'll start with a
Porsche (to _accelerate_ my developement).
_____________________________________________________
| Martin Eriksson <[email protected]>
| MSc CSE student, department of Computing Science
| Ume? University, Sweden
On Sun, 25 Nov 2001 15:53:23 -0800, Mike Fedyk <[email protected]>
wrote:
>On Sun, Nov 25, 2001 at 10:17:15AM -0800, Linus Torvalds wrote:
>>
>> On Sun, 25 Nov 2001, Stephan von Krawczynski wrote:
>> >
>> > The "problem" effectively arises from _fast_ releasing "stable" versions.
>>
>> Actually, I think that is just the _symptom_ of the basic issue: I do not
>> like being a maintainer.
>>
>
>Ok, here's *another* suggestion for future working of stable and development
>kernels...
>
>Linus,
>
>You admit that you do not like to maintain. We have seen that, and
>unfortunately for 2.4 it is true.
>
>Personally, I think that 2.4 was released too early. It was when the
>Internet hype was going full force, and nobody (including myself) could be
>faulted for getting swept up in the wave that it was.
"Internet" crashed very hard in March-April 2000. 2.4.0 was out in
early 2001... no connection I suspect.
john
On Sun, 25 Nov 2001, Patrick McFarland wrote:
> No, you are. Sorry to say that but you are. Im probably maybe one of
> 10 people on this whole planet that would like to see the kernel
> become more than it is, and would actually help doing it.
So tell us, for which task are _you_ volunteering ?
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
On Sun, 25 Nov 2001, Linus Torvalds wrote:
> The _real_ solution is to make fewer fundamental changes between
> stable kernels, and that's a real solution that I expect to become
> more and more realistic as the kernel stabilizes.
Agreed, this would make a _lot_ of difference in the time it
takes to get a new stable kernel really stable.
> But you also have to realize that "fewer fundamental changes" is a
> mark of a system that isn't evolving as quickly, and that is reaching
> middle age. We are probably not quite there yet ;)
Doesn't mean we need to get _all_ our TODO items done in
2.5. I really don't see what's wrong with doing only a
few in 2.5 and delaying the rest for 2.7, especially not
when both 2.5 and 2.7 happen quickly ;)
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
>>>>> On Sat, 24 Nov 2001 22:05:27 -0500, [email protected] ("Mohammad A. Haque") said:
Mohammad> On Saturday, November 24, 2001, at 09:41 , Patrick
Mohammad> McFarland wrote:
>> Okay, so it was 14 that had the file loopback bug, and 12 that
>> had the ieee bug.Those bugs shouldnt have been in there in the
>> first place! Those are very major potentially show stopping
>> bugs. What If I get up one day, and I cant print? Or build
>> isos? That sounds minor to you, but thats a big thing if say,
>> the linux box is a network print server, or, its the
>> workstation for the guy in the company who builds the iso. And,
>> no, "use the previous kernel" isnt a good excuse. Because what
>> if you get hit with bugs back to back? You'll have to go back
>> to some kernel way way back. Like 2.4.2. The Kernel needs
>> Quality Assurance.
Mohammad> Yes, this is a QA problem. But also .. if you're a smart
Mohammad> net/system admin, you don't go out installing a just
Mohammad> released kernel without letting others bang on it or run
Mohammad> it on some test servers. Where I work, I insist the
Mohammad> admins wait at least 1-2 weeks before going to the
Mohammad> latest release unless there's some huge security fix.
I must say I'm seriously annoyed with the 2.4-tree so far. As far as
I'm concerned, 2.4 were obviously released too eary (or maybe the
2.5-tree should have been opened earlier so we wouldn't had this
VM-mess in the "stable" release). I'm not so annoyed for my own part
(I've mainly stayed on the 2.2 and will stay there until 2.4 looks
sane), but for a friend of mine.
Let me explain: I've had a few discussions with him that he should try
Linux for his needs, but it's always been "It looks complicated" and
"I can't play my games" that has stopped him. Now, a few weeks ago
lokigames released his favourite game and he ordered it, fully decided
to ditch Windows once and for all, like I did back in the summer if
-96 and so far I haven't regretted it. But then, 2.0 or 2.2 never felt
as shaky and unpredictable as 2.4 does right now.
So, off he went, installing RedHat only to find that his soundcard
didn't work reliable under the pre-built kernel. He decided not to
give up too fast and compiled his own kernel, several kernels in fact.
I don't remember how many, but I know that his attempt to try
2.4.15preX worked very well, except that his RAID-card refused to
work, so after much experimenting he found out that
2.4.13ac(something) could handle his soundcard and his RAID-card, but
only one of his CD-ROMs worked. Then the whole kernel finally blew up
on a VM-bug...
I must say that he really tried. He forsaked much of his spare time to
learn Linux and he learned a lot rather fast, but when a deadline on
one of his projects crept too close and he still didn't have a working
computer, he finally despaired and we lost him back to Windows XP.
It's obvious that stories like this really won't improve the
reputation of Linux...
> The _real_ solution is to make fewer fundamental
changes
> between stable kernels, and that's a real solution
that I
> expect to become more and more realistic as the
kernel
> stabilizes. I already expect 2.5 to have a _lot_
less
> fundamental changes than the 2.3.x tree ever had -
the
> SMP scaliability efforts and page-cachification
between
> 2.2.x and 2.4.x is really quite a big change.
Well, I know this has been discussed several times,
but why
not having 2 stable trees : one for the average "joe"
user
which would include fixes and new features, and one
for
prod servers which will have only bugfixes, and quite
old,
tested features, with less risks of regression. I
think that all
in all, current 2.4 kernels are fairly stable except,
perhaps
for a few, not so common, features. There are still
lots of
people who don't upgrade their 2.2 to 2.4 (or even old
2.4 to
newer 2.4) because of a "well known bug" in a feature
they
might even never use.
I'm myself used to build kernels from Alan's tree, on
which
I add several features (ipsec...), and backport
bugfixes from
more recent kernels (as far as my understanding can
go, of
course). When 2.4.14 went out, I was still using a
2.4.10ac12
+many fixes, but without any feature upgrade. I have
several
friends using my kernels because they find them more
stable
although I couldn't judge because they don't always
report
bugs as people do on LKML.
A very conservative branch could be maintained with
not
much effort since we would only have to include new
fixes
(ok, sometimes you can't keep up and have to make the
step, that's why I jumped from 2.4.10ac to 2.4.13ac).
We
could even count failure and success reports for some
features to help those parano?d to decide which kernel
to
use.
Perhaps it's what distro makers do, but at least they
don't
announce their kernels on LKML as you, Alan, or Andrea
actually do.
I even may participate in this, given my very limited
time (ie,
if people are ready to wait 3 weeks without news, and
accept sometimes completely broken kernels when I jump
from one major release to one other), but honnestly,
that's
not my primary goal.
Just my 2 euro-cents here,
Willy
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran?ais !
Yahoo! Courrier : http://courrier.yahoo.fr
Linus Torvalds <[email protected]> said:
[...]
> The _real_ solution is to make fewer fundamental changes between stable
> kernels, and that's a real solution that I expect to become more and more
> realistic as the kernel stabilizes. I already expect 2.5 to have a _lot_
> less fundamental changes than the 2.3.x tree ever had - the SMP
> scaliability efforts and page-cachification between 2.2.x and 2.4.x is
> really quite a big change.
As a (mostly) bystander to kernel development here in lkml I see that there
are largeish areas in the kernel where ancient legacy, old, and new
mechanisms coexist. How about going _just_ for a big spring cleanup (Yep,
it _is_ spring around here ;-) (including kbuild, CML2, cutting everything
over to tasklets, getting rid of legacy timers, go after the results of the
Stanford checker, make the kernel-janitors work overtime, ...), going for
2.6 in a short(ish) time, and leave 2.7 for really new stuff? It should be
easier to do new development on a more uniform base (besides, having to
remember several ways to do things and the ugliness of it all does detract
from the fun of kernel development, which is the central objective AFAIU).
It should also naturally cut down the time between new stable releases.
Just too bad Halloween is now past, the moaning here would have added to
the spirit ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Saturday 24 November 2001 16:39, Marcelo Tosatti wrote:
> Hi,
>
> So here it goes 2.4.16-pre1. Obviously the most important fix is the
> iput() one, which probably fixes the filesystem corruption problem people
> have been seeing.
This is quite annoying to have non-pre kernels with simple bugs like
recent loop device bug etc.
Maybe this can be prevented by adopting a rule that non-pre kernel is made
from last pre/ac/... which was good enough by changing version # _only_,
without even single buglet squashing?
This way we will not disappoint those people who download non-pres in hope
they are more stable.
Just my 2 cents.
--
vda
what you don't seem to realize is that it was the VM problems that made
the 2.4 stabilization problems in the first place.
if the VM system had been as stable as the kernel developers thought it
was in 2.4.0 we would probably have branched the 2.5 series by 2.4.5 or
so, but instead there were attempts to fix the existing Vm until 2.4.9 and
then Linus gave up on it and put in the new VM in 2.4.10 which took a
couple releases to find all the problems in it (pretty good if you
consider how fundamental a change this was)
it wasn't a case of just deciding to use a different VM beecouse it was
newer, it was switched becouse the old one was broken and had proven
unfixable to date.
so all complaints about how the VM change should have waited until 2.5/2.6
ignore the fact that the existing VM system was broken.
more testing is good, but one thing the 2.4 problems have definantly shown
is that there were a LOT of loads/configurations that did not get tested
in the 2.3 series. people waited for a 'stable' kernel to try their loads
on and as such they discovered problems that hadn't been tested in the
development kernels.
if you want to help then figure out how to test the development kernels
more, don't gripe about the stable kernels not being perfect. It doesn't
matter how many -rc kernels there are if most people wait until -final
before doing their testing.
David Lang
On 26 Nov 2001, Martin Persson wrote:
> Date: 26 Nov 2001 13:06:50 +0100
> From: Martin Persson <[email protected]>
> To: [email protected]
> Subject: Re: Linux 2.4.16-pre1
>
> >>>>> On Sat, 24 Nov 2001 22:05:27 -0500, [email protected] ("Mohammad A. Haque") said:
>
> Mohammad> On Saturday, November 24, 2001, at 09:41 , Patrick
> Mohammad> McFarland wrote:
> >> Okay, so it was 14 that had the file loopback bug, and 12 that
> >> had the ieee bug.Those bugs shouldnt have been in there in the
> >> first place! Those are very major potentially show stopping
> >> bugs. What If I get up one day, and I cant print? Or build
> >> isos? That sounds minor to you, but thats a big thing if say,
> >> the linux box is a network print server, or, its the
> >> workstation for the guy in the company who builds the iso. And,
> >> no, "use the previous kernel" isnt a good excuse. Because what
> >> if you get hit with bugs back to back? You'll have to go back
> >> to some kernel way way back. Like 2.4.2. The Kernel needs
> >> Quality Assurance.
>
> Mohammad> Yes, this is a QA problem. But also .. if you're a smart
> Mohammad> net/system admin, you don't go out installing a just
> Mohammad> released kernel without letting others bang on it or run
> Mohammad> it on some test servers. Where I work, I insist the
> Mohammad> admins wait at least 1-2 weeks before going to the
> Mohammad> latest release unless there's some huge security fix.
>
> I must say I'm seriously annoyed with the 2.4-tree so far. As far as
> I'm concerned, 2.4 were obviously released too eary (or maybe the
> 2.5-tree should have been opened earlier so we wouldn't had this
> VM-mess in the "stable" release). I'm not so annoyed for my own part
> (I've mainly stayed on the 2.2 and will stay there until 2.4 looks
> sane), but for a friend of mine.
>
> Let me explain: I've had a few discussions with him that he should try
> Linux for his needs, but it's always been "It looks complicated" and
> "I can't play my games" that has stopped him. Now, a few weeks ago
> lokigames released his favourite game and he ordered it, fully decided
> to ditch Windows once and for all, like I did back in the summer if
> -96 and so far I haven't regretted it. But then, 2.0 or 2.2 never felt
> as shaky and unpredictable as 2.4 does right now.
>
> So, off he went, installing RedHat only to find that his soundcard
> didn't work reliable under the pre-built kernel. He decided not to
> give up too fast and compiled his own kernel, several kernels in fact.
> I don't remember how many, but I know that his attempt to try
> 2.4.15preX worked very well, except that his RAID-card refused to
> work, so after much experimenting he found out that
> 2.4.13ac(something) could handle his soundcard and his RAID-card, but
> only one of his CD-ROMs worked. Then the whole kernel finally blew up
> on a VM-bug...
>
> I must say that he really tried. He forsaked much of his spare time to
> learn Linux and he learned a lot rather fast, but when a deadline on
> one of his projects crept too close and he still didn't have a working
> computer, he finally despaired and we lost him back to Windows XP.
>
> It's obvious that stories like this really won't improve the
> reputation of Linux...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
=?iso-8859-1?q?willy=20tarreau?= <[email protected]> said:
> Well, I know this has been discussed several times, but why not having 2
> stable trees : one for the average "joe" user which would include fixes
> and new features, and one for prod servers which will have only bugfixes,
> and quite old, tested features, with less risks of regression.
Think distributions, think 2.2.x (still actively maintained), think 2.4.x
(just now declared stable, ready for "just bugfixes"), and think 2.5.x +
assorted unofficial patches.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Mon, Nov 26, 2001 at 08:59:01AM -0200, Rik van Riel wrote:
> On Sun, 25 Nov 2001, Linus Torvalds wrote:
> > But you also have to realize that "fewer fundamental changes" is a
> > mark of a system that isn't evolving as quickly, and that is reaching
> > middle age. We are probably not quite there yet ;)
>
> Doesn't mean we need to get _all_ our TODO items done in
> 2.5. I really don't see what's wrong with doing only a
> few in 2.5 and delaying the rest for 2.7, especially not
> when both 2.5 and 2.7 happen quickly ;)
On the other hand, I dont think you want major number releases of stable
kernels happening too quickly either. For people who really care about
stability, moving from 2.2 to 2.4 is a big deal. I dont think we really
want people to think that they need to do that kind of thing once a year
even if we could manage to get our development cycle shortened that much.
Thanks,
Jim
On 26 Nov 2001, Martin Persson wrote:
> I must say I'm seriously annoyed with the 2.4-tree so far. As far as
> I'm concerned, 2.4 were obviously released too eary (or maybe the
> 2.5-tree should have been opened earlier so we wouldn't had this
> VM-mess in the "stable" release). I'm not so annoyed for my own part
> (I've mainly stayed on the 2.2 and will stay there until 2.4 looks
> sane), but for a friend of mine.
[snip]
> I must say that he really tried. He forsaked much of his spare time to
> learn Linux and he learned a lot rather fast, but when a deadline on
> one of his projects crept too close and he still didn't have a working
> computer, he finally despaired and we lost him back to Windows XP.
Yes. I bought an Athlon with top-of-the-line video and sound cards for
multimedia work. I *still* don't have a Linux driver for either the 3D or
the sound card, so I'm dual-booting with Windows 2000. Alsa is garbage -- they
"have a driver" for my sound card but the documentation -- what little there
is -- is incomprehensible. I even bought the OSS/Linux drivers, but they are
closed source and the documentation isn't much better. I sent e-mail to the
vendor who told me RTFM. I haven't even tried to deal with the video issues.
--
[email protected] (M. Edward Borasky) http://www.meta-trading-coach.com
Relax! Run Your Own Brain with Neuro-Semantics!
How to Stop A Folksinger Cold # 4
"Tie me kangaroo down, sport..."
Tie your own kangaroo down -- and stop calling me "sport"!
vda wrote:
>
> On Saturday 24 November 2001 16:39, Marcelo Tosatti wrote:
> > Hi,
> >
> > So here it goes 2.4.16-pre1. Obviously the most important fix is the
> > iput() one, which probably fixes the filesystem corruption problem people
> > have been seeing.
>
> This is quite annoying to have non-pre kernels with simple bugs like
> recent loop device bug etc.
>
> Maybe this can be prevented by adopting a rule that non-pre kernel is made
> from last pre/ac/... which was good enough by changing version # _only_,
> without even single buglet squashing?
>
> This way we will not disappoint those people who download non-pres in hope
> they are more stable.
>
> Just my 2 cents.
> --
> vda
I agree.
--Charles
/"\ |
\ / ASCII Ribbon Campaign |
X Against HTML Mail |--Charles Marslett
/ \ | http://www.wordmark.org
> so all complaints about how the VM change should have waited until 2.5/2.6
> ignore the fact that the existing VM system was broken.
Not paticularly. The original VM was fixable enough to branch 2.5, then
put the new VM in 2.5 and backport it without shipping two releases that
100% didnt actually work.
> more, don't gripe about the stable kernels not being perfect. It doesn't
> matter how many -rc kernels there are if most people wait until -final
> before doing their testing.
Thats why vendor kernels are generally a good idea for production setups.
Most vendors kernel trees have been beaten solidly for days with stress
testing and coverage test tools before they get put out
On Mon, Nov 26, 2001 at 04:55:17PM +0000, Alan Cox wrote:
>
> Thats why vendor kernels are generally a good idea for production setups.
> Most vendors kernel trees have been beaten solidly for days with stress
> testing and coverage test tools before they get put out
Makes one wonder whether or not we need regression tests included
in the kernel...
Dominik Kubla
--
ScioByte GmbH Zum Schiersteiner Grund 2 55127 Mainz (Germany)
Phone: +49 700 724 629 83 Fax: +49 700 724 629 84
1024D/717F16BB A384 F5F1 F566 5716 5485 27EF 3B00 C007 717F 16BB
Alan Cox wrote:
>>That's up to the 2.2 and 2.0 maintainers.
>
> 2.2 is for fixes only
>
No question about that... the point was, would you be willing to put 2.2
prepatches in v2.2/testing as opposed to people/alan/linux-2.2/...
-hpa
Alan Cox wrote:
>>pre-patches show up on kernel.org automatically), or preferably just do
>>the same thing, and make the v2.4 test patches in v2.4/testing (which will
>>also require support from the site admin, who is probably overworked as-is
>>with the RAID failures ;)
>
> I'll start using v2.2/testing if I remember when I finall get around to
> 2.2.21pre1
>
Please let me know when you do. I'll probably be able to track the 2.2
and 2.0 trees automatically if that gets done...
-hpa
Followup to: <[email protected]>
By author: Rik van Riel <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Sun, 25 Nov 2001, Linus Torvalds wrote:
>
> > The _real_ solution is to make fewer fundamental changes between
> > stable kernels, and that's a real solution that I expect to become
> > more and more realistic as the kernel stabilizes.
>
> Agreed, this would make a _lot_ of difference in the time it
> takes to get a new stable kernel really stable.
>
I would REALLY like to see this policy. I have been harping on this
for some time now -- we have been having 2-3 times too long cycles
between stable kernels, which results in an unacceptable level of
pressure to "get your features in" instead of the proper answer "you
missed the boat, wait for the next one."
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Martin Persson wrote:
> I must say I'm seriously annoyed with the 2.4-tree so far. As far as
> I'm concerned, 2.4 were obviously released too eary (or maybe the
> 2.5-tree should have been opened earlier so we wouldn't had this
> VM-mess in the "stable" release).
Actually it's a good thing it wasn't released
before the vm "mess" was fixed!
> It's obvious that stories like this really won't improve the
> reputation of Linux...
That's a tough one - perhaps if he had a Linux
savvy buddy to guide him through the tough
parts... I have been doing all gaming on Linux,
and would not consider going back to windows.
cu
jjs
> pre-patches show up on kernel.org automatically), or preferably just do
> the same thing, and make the v2.4 test patches in v2.4/testing (which will
> also require support from the site admin, who is probably overworked as-is
> with the RAID failures ;)
I'll start using v2.2/testing if I remember when I finall get around to
2.2.21pre1
Horst von Brand wrote:
>
> LHow about going _just_ for a big spring cleanup
Awesome idea. So 2.6 has no new features. Just dung-removal
and documentation.
It won't happen :-(
-
On Sunday 25 November 2001 22:58, Linus Torvalds wrote:
> > 1) Develop 2.5 until it is ready to be 2.6 and immediately give it over
> > to a maintainer, and start 2.7.
>
> I'd love to do that, but it doesn't really work very well. Simply because
> whenever the "stable" fork happens, there are going to be issues that the
> bleeding-edge guard didn't notice, or didn't realize how they bite people
> in the real world.
>
> So I could throw a 2.6 directly over the fence, and start a 2.7 series,
> but that would have two really killer problems
>
> (a) I really don't like giving something bad to whoever gets to be
> maintainer of the stable kernel. It just doesn't work that way:
> whoever would be willing to maintain such a stable kernel would be a
> real sucker and a glutton for punishment.
>
> (b) Even if I found a glutton for punishment that was intelligent enough
> in other ways to be a good maintainer, the _development_ tree too
> needs to start off from a "known reasonably good" point. It doesn't
> have to be perfect, but it needs to be _known_.
Think in terms of the concept of "patch pressure". Lots of patches out
there, trying to get into the tree. They WILL have an effect on development.
Way back when, Linux got off the ground so fast in large part because it
grounded out Minix's patch pressure. Andrew Tanenbaum wouldn't integrate
patches into his codebase, so the pressure built up and up until it found
some place to leak out: your term program. (The GNU project had a similar
problem because RMS insists copyrights be signed over to him on paper, and
that creates a lot of friction which makes integration hardware and increases
patch pressure. Linux was an outlet for the frustrations of the developers
of TWO unix clone development projects. And even a couple of people fed up
with Bill Jolitz' inertia on BSD...)
A "stable" series with no development branch seems to work well for about
three months. All the developers are focused on bug fixing and stabilization
due to lack of options. But beyond that, the "herding cats" aspect of
development builds up, developers get bored, they've implemented new ideas
anyway which aren't being integrated and are taking up more and more of their
attention, private trees diverge...
Patch pressure.
I submit that if the stable tree hasn't calmed down after three or four
months, opening a development branch may in fact HELP the situation, and
stabilize things faster. You need to vent the patch pressure.
If you don't, you'll get megabytes of diffs in Alan Cox's tree that aren't in
yours, you'll get the Functionally Overloaded Linux Kernel (a clear symptom:
a kernel aimed at solely at doing the cleanup work integrating outside
patches into a single tree, whether they work or not...), you'll get more
trees like Andrea Arcangelli's becoming widely used... The end result is not
focusing development effort, it's scattering it more. Refusing to integrate
patches won't prevent them from being created, maintained, applied by system
vendors... It just means developers have to maintain more version state in
their heads.
Trying to confine people's attention to a single tree only works until the
patch pressure builds up to a certain point. Beyond that, it can't be
contained and if you don't give it an outlet it'll find one. The end result
will be MORE scattered, MORE chaotic, and less useful. On the other hand,
the presense of a development tree doesn't stop the "stable" tree from being
interesting. Bugs found in 2.2 are still fixed. 2.4 is still compared with
2.2 when things go strange. And code from the development fork is backported
to the last stable version all the time.
Point for consideration: for a while (just before the ric->andrea VM switch,
say 2.4.9), alan's tree was closer to stabilizing the VM than yours. Alan
had also integrated WAY more stuff than you had. People were ALREADY dealing
with two trees (Alan's and yours) which had fairly widely diverged. How
would having an active development branch with different development and
stable maintainers have been worse than what DID happen?
> For good of for bad, we actually have that now with 2.4.x - the system
> does look fairly stable, with just some silly problems that have known
> solutions and aren't a major pain to handle. So the 2.5.x release is off
> to a good start, which it simply wouldn't have had if I had just cut over
> from 2.4.0.
How is backporting stable code from 2.5->2.4 much different than forward
porting bug fixes and stabilizations from 2.4->2.5? As long as everybody
understands what got fixed and why...
> The _real_ solution is to make fewer fundamental changes between stable
> kernels, and that's a real solution that I expect to become more and more
> realistic as the kernel stabilizes. I already expect 2.5 to have a _lot_
> less fundamental changes than the 2.3.x tree ever had - the SMP
> scaliability efforts and page-cachification between 2.2.x and 2.4.x is
> really quite a big change.
That's the old argument for a faster release cycle again. It's still easier
said than done. In theory, if 2.5 had opened with the new andrea VM (instead
of 2.4.10), had proven itself superior in 3 months, it could have been closed
stabilizied and called 2.6 after 6 months. In the real world, that won't
happen, but the forces making that NOT happen still apply to the current
situation.
This is another chicken and egg problem. A temporary pause in development
(for stabilization) can indeed drop patch pressure by getting developers to
cross their legs and hold it. But only if developers believe it really is
temporary. Your development process has kind of FUDded itself on that front,
historically speaking...
If you don't let development and stabilization overlap, then pressure to
integrate new patches will never stop (something Alan is historically better
at saying no to than you are). The longer they're blocked, the greater they
get. At some point, giving them a known outlet makes more sense to me than
trying to put one more finger in the dike. Your mileage probably does vary...
> But you also have to realize that "fewer fundamental changes" is a mark of
> a system that isn't evolving as quickly, and that is reaching middle age.
> We are probably not quite there yet ;)
Slower development is not necessarily better development. If we wanted slow
and careful changes that were fully documented we'd be using the IBM software
development procedure manual from the 1980's. That simply doesn't work.
Getting developers to hold back with no development branch outlet (other than
FOLK, Alan's tree, or private CVS) didn't stop this stabilization cycle from
taking almost a full year. I'm not sure tightening the restrictions in this
area will actually improve matters...
> Linus
Rob
Patrick McFarland <[email protected]> said:
> No, you are. Sorry to say that but you are. Im probably maybe one of 10
> people on this whole planet that would like to see the kernel become more
> than it is,
Last time I knew, there were a few tens of _thousands_ of people lon
lkml...
> and would actually help doing it.
... and many of them did test new kernels, and reported bugs, and supplied
patches. You are way off base here.
> Obviously, the whole damn
> community is having problems with me disagreeing with it, so screw
> it. You guys blew it.
Either you work _in_ the community (and abide by its rules) or you get out.
Or you are just a troll that I feeding...
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
> I submit that if the stable tree hasn't calmed down after three or four
> months, opening a development branch may in fact HELP the situation, and
> stabilize things faster. You need to vent the patch pressure.
I'd tend to agree there. The new VM would have gone into 2.5.x and then back
into 2.4
In terms of release cycles there is a better method, that is simply to
codify what already happens. In truth we have yearly major releases
We went
1.2
1.3.59
2.0
2.0.30
2.2
2.2.14-18 merge cycle
2.4
What we possibly should do is admit the backport phases (2.0.30/2.2.14/...)
do in fact occur and go
2.5
2.5 seems kind of solid at some random point but not finished
2.6 (2.4 + 2.5 and useful bit driver backport)
2.7 (continued 2.5)
2.8 (actual release containing the grand changes 2.5 started)
On Monday 26 November 2001 16:08, Alan Cox wrote:
> > I submit that if the stable tree hasn't calmed down after three or four
> > months, opening a development branch may in fact HELP the situation, and
> > stabilize things faster. You need to vent the patch pressure.
>
> I'd tend to agree there. The new VM would have gone into 2.5.x and then
> back into 2.4
>
> In terms of release cycles there is a better method, that is simply to
> codify what already happens. In truth we have yearly major releases
I also can't think of a distribution that doesn't have at least a yearly
major release cycle.
I suspect part of the reason for the long gap between stabilizations is that
Linus hates maintenance. Of course it's like visiting the dentist: the
longer it takes the bigger a deal it is...
> We went
>
> 1.2
> 1.3.59
> 2.0
> 2.0.30
> 2.2
> 2.2.14-18 merge cycle
> 2.4
>
> What we possibly should do is admit the backport phases (2.0.30/2.2.14/...)
> do in fact occur and go
>
> 2.5
> 2.5 seems kind of solid at some random point but not finished
> 2.6 (2.4 + 2.5 and useful bit driver backport)
> 2.7 (continued 2.5)
> 2.8 (actual release containing the grand changes 2.5 started)
This gets back to the idea of "minor" development cycles (for example 2.5
already HAS enough pending patches for an entire development cycle) that take
6 months because we know what's going to go into them in the first month or
two, vs "major" anything-goes phases (3.0, which 2.2 probably should have
been...) that are a lot more experimental. Right now, everything's a major
cycle. Even though Linus has expressed a desire to do minor ones, it hasn't
happened yet.
The thing is, with a 6 month development cycle that people BELIEVE will only
take 6 months, it's ok to say "hold off until the next time". But asking
people to "hold it" for two years (even if they only THINK it will be two
years) doesn't work, they keep pushing to get it in and the patch pressure
stays high. So it's a stable 2 state feedback loop: if you can do it you can
do it, and if you can't you can't.
The "backport release" idea seems like a nice way to do the "short" cycle
ones. And the interesting thing about that is Linus doesn't have to be
directly involved in these intermediate stabilizations: there could be
another maintainer he could just give his blessing to. All they need is a
bit of holy penguin pee to make the number official, and the attention of
developers (like all those in Red Hat's employ) willing to spend their time
stabilizing rather than beating fresh trails into the jungle...
A backport release really isn't THAT much different than large changes from
your tree being merged into Linus's tree. Just a question of sequencing
(determining what depends on what), isolating, and porting...
Just a thought...
Rob
Thats just it, Im automatically called a troll because I disagree with the community. And in responce of what about 14 people said, yes, ive been using linux for a very long time, and Ive read the lkml for a very long time as well. Yet, somehow, people still want to say I dont know anything about the kernel. Well, those people, and you trolls know who you are, your mail is now automatically dumped into /dev/null. Now as the whole fact of me leaving, why should I? I have more than a right to stay here because I _dont_ agree with the major players. This is something that imho has gone on way too long. Linus and ac arnt gods. Or whatever the gnu church is calling deities now. I didnt speak up for a long while because I was afraid that this would act as some lighting rod for all the trolls, flamers, and the rest of the luser hordes. And, though I wish it didnt, it did. And, yes, there arnt that many people that disagree with the community and still want to help it. Its about 10 people. I dunno, maybe we need more of us. Especially if they show how petty most people can get. Im tired of alot of the stupid linux kiddies and gnu worshipers. But, I have to deal with them. Specifically, my /dev/null deals with them. Im tired of those people because they say the same thing over if they are right or wrong, "Linus/ac/$diety is right!" Linus and ac would agree with me, they havent been right 100% of the time, yet, if you listened to the (massive) group of cluebies, you would led to belive that these two geeks are superhuman in some way. This is far from the case. Now, if everyone still thinks that Im the troll here, I seriously think everyone needs to take a deep breath, may be two if the first one didnt work.
On 25-Nov-2001, Horst von Brand wrote:
> Patrick McFarland <[email protected]> said:
>
> > No, you are. Sorry to say that but you are. Im probably maybe one of 10
> > people on this whole planet that would like to see the kernel become more
> > than it is,
>
> Last time I knew, there were a few tens of _thousands_ of people lon
> lkml...
>
> > and would actually help doing it.
>
> ... and many of them did test new kernels, and reported bugs, and supplied
> patches. You are way off base here.
>
> > Obviously, the whole damn
> > community is having problems with me disagreeing with it, so screw
> > it. You guys blew it.
>
> Either you work _in_ the community (and abide by its rules) or you get out.
> Or you are just a troll that I feeding...
> --
> Horst von Brand [email protected]
> Casilla 9G, Vin~a del Mar, Chile +56 32 672616
>
--
Patrick "Diablo-D3" McFarland || [email protected]
On Mon, 26 Nov 2001, Patrick McFarland wrote:
> Thats just it, Im automatically called a troll because I disagree with
> the community.
No. People think you're a troll because all you've done up
till now is shout around some generic handwaving about how
other people should do stuff better.
Now if you showed us some of your work (patches, documentation,
tracing down bugs, etc...) you could convince us you're serious
about helping out improving the kernel.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/
Patrick,
Word of advise kind sir -- by asbestos or get thicker skin.
In the past I was one of the absolute worst BLOW-TORCH carries here,
so just learn to live and let live....
Also w/ an name like "Patrick McFarland" you should be an equal
opportunity asre kicker! Red-n-Green to make Black-n-Blue!
Cheers,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
Bah. If people think that way, then I could name a couple good physcologists. </troll>
Seriously, if people think that way, then they really need some help. And, Ill probably be able to show some code (which may or may not be directly kernel related, but very midi related) within the next month or so.
On 26-Nov-2001, Rik van Riel wrote:
> On Mon, 26 Nov 2001, Patrick McFarland wrote:
>
> > Thats just it, Im automatically called a troll because I disagree with
> > the community.
>
> No. People think you're a troll because all you've done up
> till now is shout around some generic handwaving about how
> other people should do stuff better.
>
> Now if you showed us some of your work (patches, documentation,
> tracing down bugs, etc...) you could convince us you're serious
> about helping out improving the kernel.
>
> regards,
>
> Rik
> --
> Shortwave goes a long way: irc.starchat.net #swl
>
> http://www.surriel.com/ http://distro.conectiva.com/
>
--
Patrick "Diablo-D3" McFarland || [email protected]
On Monday 26 November 2001 16:42, Rob Landley wrote:
> I also can't think of a distribution that doesn't have at least a yearly
> major release cycle.
Okay, Debian.
Rob
Rob Landley <[email protected]> writes:
> On Monday 26 November 2001 16:42, Rob Landley wrote:
>
> > I also can't think of a distribution that doesn't have at least a yearly
> > major release cycle.
>
> Okay, Debian.
what do you mean? it's at least a year between debian releases. ;->
--
J o h a n K u l l s t a m
[[email protected]]
On Mon, Nov 26, 2001 at 03:07:06PM -0200, vda wrote:
> On Saturday 24 November 2001 16:39, Marcelo Tosatti wrote:
> > Hi,
> >
> > So here it goes 2.4.16-pre1. Obviously the most important fix is the
> > iput() one, which probably fixes the filesystem corruption problem people
> > have been seeing.
>
> This is quite annoying to have non-pre kernels with simple bugs like
> recent loop device bug etc.
>
> Maybe this can be prevented by adopting a rule that non-pre kernel is made
> from last pre/ac/... which was good enough by changing version # _only_,
> without even single buglet squashing?
>
> This way we will not disappoint those people who download non-pres in hope
> they are more stable.
>
> Just my 2 cents.
Yep.
The oops fix was just for a driver, but who knows how much testing that
patch has received?
2.4.16 looks like it will be what 2.4.15 was intended to be.
Hopefully, future kernels that are under Marcello's control won't have the
need to release becasue the last releas was broken.
This may have been one of the smallest changes between the last -pre and
-final.
Let's hope $(test -z "`diff -u last-pre -final`") returns true for future
2.4 kernels.
MF
On Mon, 26 Nov 2001, Mike Fedyk wrote:
>...
> Let's hope $(test -z "`diff -u last-pre -final`") returns true for future
> 2.4 kernels.
This would mean that Marcelo has forgotten to change the version number in
the Makefile... ;-)
> MF
cu
Adrian
--
Get my GPG key: finger [email protected] | gpg --import
Fingerprint: B29C E71E FE19 6755 5C8A 84D4 99FC EA98 4F12 B400
* Patrick McFarland ([email protected]) [011125 19:00]:
> And I like the kernel qa group idea, but where would we get the
> people to be on it?
Start with yourself.
Build some basic QA functionality.
Propose plans for how a kernel version will be marked QA-OK.
Build a web site describing what people and resources you need.
If you build it, they will come.
Ciao!
--
"As a former philosophy major, it disturbs me to think that things disappear
when no one is looking at them, but that's exactly what happens in Python."
-- Mark Pilgrim (http://www.diveintopython.com, section 3.4)
The Doctor What: A Holtje Production http://docwhat.gerf.org/
[email protected] KF6VNC
On Tue, 4 Dec 2001, The Doctor What wrote:
> * Patrick McFarland ([email protected]) [011125 19:00]:
> > And I like the kernel qa group idea, but where would we get the
> > people to be on it?
>
> Start with yourself.
>
> Build some basic QA functionality.
> Propose plans for how a kernel version will be marked QA-OK.
> Build a web site describing what people and resources you need.
>
> If you build it, they will come.
I'd be willing to host such a thing on kernelnewbies.org,
if Patrick (or somebody else) is willing to implement and
maintain it.
cheers,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
http://www.surriel.com/ http://distro.conectiva.com/