On Tue, 24 Jan 2006, Troy Dawson wrote:

> Jon Peatfield wrote:
<snip>
> That's a fair question.
> First, before I answer why, know that the kernel updates should be out today. 
> At least for S.L. 4x, and hopefully for S.L. 3.0.x
> Why does it take so long?
> The actual compiling takes a couple of hours.  But that's not the real 
> stickler.
> There are two things that slow things up.  Kernel testing, and kernel package 
> dependancies.
>
> We usually don't just roll out a kernel like everything else.  We usually 
> install it, make sure it works, and also listen to the various mailling lists 
> (RHEL, CentOS, Tau) to see if there is any immediate problems.
> In this case, there was a report of a very common network driver not working. 
> We have tried many way's, but simply cannot reproduce the problem, and have 
> concluded that the person who had the problem must have downloaded the driver 
> straight from the vendor and then forgot about that.
>
> The other problem is package dependancies.  It's nice that we have openafs 
> and the GFS cluster suite.  The problem is with the GFS cluster suite.  They 
> are always a few days (and in one case a week) behind the release of a 
> kernel.  They finally released it for this kernel right as I was starting to 
> hand redo the packages.
>
> For this kernel, we've also been a bit over-utilized because we were just 
> about to release S.L. Fermi 4.2.
>
> So, we do appreciate your offer to help.  In this case it has just been a 
> strange combination of things that has slowed things up.

We are also paranoid about kernel upgrades, and I prefer to have done our 
own sanity tests to ensure that nothing (obvious at least) breaks for a 
selection of hosts here before we roll it out.  I (probably foolishly) 
pre-announced the next general kernel upgrade will be next week (1st Feb), 
to coincide with a bunch of other (some local) upgrades we will be doing 
on the same day.

Of course I hope it was obvious that I wasn't meaning to critisize (any 
of) you.

Just in case there is any way we can help with any testing in future, we 
usually have a few boxes that we are running various test stuff on (at any 
given time), though we can't guarentee to have any partcular hardware (or 
unusual hardware), since our set of test boxes rotates over time...

After some upgrades over the next few weeks, we should be rid of most of 
our ancient RH systems (and Tru64/Irix probably as well), so I hope to be 
in a position to start moving to SL4 ready for the summer in which case we 
will (hopefully) have test SL4 systems too.

  -- Jon

-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/