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

[Sean Elble]

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/
[e-mail]
-----------------------------------------------

----- Original Message -----
From: "François Cami" <[e-mail]>
To: "Sean Elble" <[e-mail]>
Cc: <[e-mail]>; "John Alvord" <[e-mail]>;
<[e-mail]>
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/
> > [e-mail]
> > -----------------------------------------------
> >
> > ----- Original Message -----
> > From: "François Cami" <[e-mail]>
> > To: "Sean Elble" <[e-mail]>
> > Cc: <[e-mail]>; "John Alvord" <[e-mail]>;
> > <[e-mail]>
> > 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/
> >>[e-mail]
> >>-----------------------------------------------
> >>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/