New testing kernel.

[Dave Jones]

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.

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