Re: Development tree, PLEASE?

[Dave Jones <davej@redhat.com>]

On Thu, Feb 02, 2006 at 11:25:24AM -0700, Michael Loftis wrote:

 > >o You want security fixes and only minor other fixes (done magically
 > >  by someone else as you're not willing to pay for it, nor are you
 > >  willing to help yourself), for at least 6 months, but you ignore
 > >  the existance of the 2.6.x.y kernel series, which does exactly
 > >  that -- check
 > 
 > There's noone out there that does that, I'd LOVE to be able to pay for it 
 > and not have to do it myself.  RedHat kernels don't work on most of our 
 > gear

Specifics?  The patches we carry in Fedora aren't very system-specific,
so any failure to boot there would likely be a problem on mainline.
The "but it works on $otherdistro" response that seems to be so popular
these days is time after time proven due to be because $otherdistro is
shipping an older kernel, and hasn't hit that particular bug yet.

 > , and RH, up to and including fedora core, and centos have some 'great' 
 > issues, like the listener processes for Apache and MySQL using up *ALL* of 
 > the system CPU when *NOTHING* is happening.

How did you determine this is a kernel bug?  Did you file a bugzilla report on this?

 > We've tried to track it down, 
 > it's gotten to where we just don't care and we just don't deploy RedHat 
 > anymore.  SuSE's kernels suffer the same problem of too many patches I 
 > mentioned before for totally unrelated, non-security things.

You can't complain about 'too many patches' in a distro kernel these days.
Any distro that ships a stock vanilla kernel is a distro that has
known oopsable drivers, features that don't work as expected, 
won't boot on certain hardware, and other general flakyness.

In the current FC4 2.6.15.2 based update..

- 47 bug fix patches. Shipping without these isn't an option.
- 24 'deviation' patches, where we add some not-yet-upstream feature
  or rh-specific feature. (Xen, Execshield, signed modules, restricted /dev/mem etc)
  [note, not 1 diff per feature, some features are multiple patches]
- 21 debugging patches. (Enabling extra output in certain bad situations etc)
- 3 convenient 'make the buildsys life easier' patches
- the remainder are other 'nice to haves' backported from 2.6.16rc

At the absolute minimum, we'd need to carry those 47 bugfixes.
Some of these get pushed to -stable, some aren't considered enough
of a problem, so they'll sit there until I rebase to a .16

We have this mentality in certain circles of "I don't want any
changes in my distro kernel, oh, except for ones that I want".
The problem is when >1 person wants patches to make their systems
run, the result is a pretty large collection of patches.

If you want a kernel with a limited set of patches, the only answer
is 'build your own', but don't complain about vendors doing the
only thing that they can do that they've been doing for the last
10-15 years -- Trying to make a single kernel image work on
as many platforms as possible with the smallest amount of pain.
(And 'new' development model hasn't changed a damn thing in this regard,
 it's always been a challenge).

		Dave