New testing kernel.

[Thomas Taylor]

On Friday 03 December 2004 23:04, Richard Hally wrote:
> 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

Hi Dave (& all the development team):

Just adding my thanks to the others for a job well done.  Keep up the good 
work.

Thanks, Tom

-- 
Tom Taylor 
Registered linux user #263467