Re: Testing Kernel Releases Before Being Released (Was Re: Re: loop back broken in 2.2.14)

["François Cami" <stilgar2k@wanadoo.fr>]

I am wondering too... Anyone got ideas on this ?

I would like to avoid some specific problems... especially
bugs that show up when compiling a certain module / feature
of the kernel, like the loopback in 2.4.14.

Those should be very easy to get rid of
[it only takes some kernel testers to debug that early, if only
there actually were a feature freeze that last for one day...].

François


Sean Elble wrote:

> Can't argue with you on the respect that kernels should be tested, but I
> _can_ argue with you on your method. :-) The main problem that I see there
> is that you are then limiting yourself (well not you, but just making things
> hypothetical) to a certain number of test kernels. What if another problem
> is found after the freeze? Testing should be done any time Linus gets ready
> to release a kernel, though a feature freeze wouldn't be a bad idea. I'm
> still wondering what the best solution is though . . .
> 
> -----------------------------------------------
> Sean P. Elble
> Editor, Writer, Co-Webmaster
> ReactiveLinux.com (Formerly MaximumLinux.org)
> http://www.reactivelinux.com/
> elbles@reactivelinux.com
> -----------------------------------------------
> 
> ----- Original Message -----
> From: "François Cami" <stilgar2k@wanadoo.fr>
> To: "Sean Elble" <S_Elble@yahoo.com>
> Cc: <joeja@mindspring.com>; "John Alvord" <jalvo@mbay.net>;
> <linux-kernel@vger.kernel.org>
> Sent: Monday, November 12, 2001 7:37 PM
> Subject: Re: Testing Kernel Releases Before Being Released (Was Re: Re: loop
> back broken in 2.2.14)
> 
> 
> 
> I guess the way I'd do it would be to actually freeze [in which I mean
> no more 'testing' patch are applied] a pre something, say 2.4.XpreY for
> example, see if there are any obvious bugs in it (like the loopback in
> 2.4.14), correct them, test again, and if it's okay,
> release 2.4.X.
> 
> Of course, I've never done much kernel work except testing, so I'm not
> exactly the one who should talk about it.
> 
> Still, I think that from the user point of view (and there was a post in
> LKML yesterday, about Linux being used by UN*X experienced sysadmins
> only... or going mainstream instead) the releases should be tested a bit
> more thoroughly and actually *frozen* for some time (a day or two should
> suffice I guess) before being labelled 2.4.X.
> 
> Just the two cents from a newbie - I hope/mean to offense noone with that
> 
> François Cami
> 
> 
> 
> Sean Elble wrote:
> 
> 
>>Something definitely should be done to help "stabilize" the tree; it's not
>>really a big deal for most of us if something is broken, as you know there
>>will be a fix posted very soon after the release, _but_ bugs like these
>>don't exactly make Linux "look good" to the rest of the UNIX community. A
>>FreeBSD advocate might say "well, FreeBSD never does _that_". My
>>
> suggestion
> 
>>to help fix the problem would be to do what SGI does; have two seperate
>>trees that strive to stay as close to each other as possible, but one
>>becomes part of the "maintaince stream", where only bug fixes and the such
>>are added, and a "features stream", where actual new features are added
>>
> in.
> 
>>Take a look at some of the IRIX web pages at http://www.sgi.com/ for a
>>better idea of how that works, but believe me, it works. This would be in
>>addition to some sort of testing suite that each official kernel must pass
>>before it is released. With the growing number of (important/big) Linux
>>users, we must make sure each kernel is rock-solid before being released.
>>This is definitely more of a political topic than a technical one, but it
>>has to be addressed nonetheless.
>>
>>-----------------------------------------------
>>Sean P. Elble
>>Editor, Writer, Co-Webmaster
>>ReactiveLinux.com (Formerly MaximumLinux.org)
>>http://www.reactivelinux.com/
>>elbles@reactivelinux.com
>>-----------------------------------------------
>>