Messages in this thread |  | | From | "Sean Elble" <> | Subject | Re: Testing Kernel Releases Before Being Released (Was Re: Re: loop back broken in 2.2.14) | Date | Mon, 12 Nov 2001 21:32:19 -0500 |
| |
The feature freeze certainly seems to be an important part of things . . . now we just need to determine what we want to happen during and after the feature freeze. :-) I certainly think Linus' Linux should be in a CVS tree, and he should patch to that; in addition, other developers, like Alan Cox, should have commit access to the tree, but Linus has already shown that he doesn't want that. Either way, I say "testing, testing, testing!". :-)
----------------------------------------------- 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 8:03 PM Subject: Re: 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...]. > > 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 > >>----------------------------------------------- > >> > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |