[lkml]   [2001]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Testing Kernel Releases Before Being Released (Was Re: Re: loop back broken in 2.2.14)

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


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
> (Formerly
> -----------------------------------------------
> ----- Original Message -----
> From: "François Cami" <>
> To: "Sean Elble" <>
> Cc: <>; "John Alvord" <>;
> <>
> 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 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
>> (Formerly

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.061 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site