New testing kernel.

[Richard Hally]

Dave Jones wrote:

>On Sat, Dec 04, 2004 at 01:16:07AM -0500, Richard Hally wrote:
> > Dave Jones wrote:
> > 
> > >I just made a 2.6.9-1.698_FC3 set of kernels which fix
> > >a number of bugs (Full changelog below), including some
> > >of the more popular ones that were introduced during the
> > >last update (namely, smbfs should work again, and hopefully
> > >the palm/visor oopses should be gone too).
> > >
> > > 
> > >
> > Hi Dave,
> >    I'm a little confused as to how this kernel relates to the latest 
> > kernel (kernel-2.6.9-1.1009_FC4) in the /development tree ("rawhide") . 
> > Does the rawhide kernel have all these changes?
>
>Tomorrows snapshot will. (2.6.9-1.1014_FC4)
>The FC3 kernels appeared first as updates appear as soon as I ask
>someone to sign & push them, the rawhide push is automated once daily.
>
> > A little more generally, as you go forward what will be the progression 
> > as relates to the /development tree, testing, updates? Will /development 
> > be "the latest and greatest" as it has been in the past? Then move the 
> > same kernel into testing for a wider audience, then the same kernel to 
> > updates for the rest?
>
>I'm trying to get a staircase effect going on, where a new kernel appears
>in rawhide, then in FC3, if that works out, a little later it goes into FC2 too etc.
>(Though last time around, FC2 went out in parallel with FC3 as it'd
> gone without updates for so long).
>
>RHEL4 changes also factor into the equation here, its sort of hard
>to explain the 'model', but basically all 4 'current' trees are being
>kept up to date in parallel, and usually lag each other by at most
>a few days -- The RHEL kernels typically differ only in which CONFIG_ options
>are set.
>  
>
Thank you very much  for the (more than I expected) explanation  and 
also the status report below!
This kind of excellent communication really helps people keep "in tune" 
with the project.
Thanks again,
Richard Hally
 

>We're now at ~200 patches on top of mainline.  I used to be quite
>proud of being only 40 csets away from mainline, however, that was
>when we were tracking upstream on a daily basis. As we're not
>doing that right now, we're essentially pulling in selective parts
>of the upstream snapshots, so I don't feel its quite so bad as
>having 200 or so 'feature' patches that aren't upstream.
>
>There's not a lot of stuff on the plate for FC4 kernel-wise right now.
>I considered rebasing to 2.6.10rc, but its a few days work, and as
>its still a moving target, stabilising 2.6.9 for FC3 and pushing that
>into FC4 (with some extra bits like Xen) seems to be the way we're
>going forward. As well as Xen, the only other real difference is
>rawhide also has slab_debugging on, so we take a slight performance
>hit (this is always enabled during FCx-test phases, and then
>disabled for the production builds), but we do get to see any
>memory corruption bugs really quickly. The plus side of this hit
>is that any bugs found and fixed will also be relevant for FC2/FC3/RHEL4.
>
>I'm not sure of the timeline for FC4test1 yet, so its possible things
>could change by the time we get there, but right now, 2.6.10rc hasn't
>been anywhere near as stable as 2.6.9-ac in my testing.
>I'm sure this will change in time, but jumping onboard now isn't
>really going to buy us much (other than lowering the patchcount again ;-)
>
>I'll reassess the situation in the new year.
>
>		Dave
>
>  
>