[fab] Non-standard kernels in the Fedora Multiverse

[Josh Boyer]

On Wed, 2006-05-10 at 10:56 -0400, Christopher Blizzard wrote:
> Tim Burke wrote:
> > Just to share some exposure into what it takes to keep a non-standard 
> > kernel working in the Fedora tree:
> > - Pretty much a full-time dedicated highly experienced kernel developer 
> > to spend the vast majority of their time playing patch monkey to keep up 
> > with the high rate of upstream change.  We have someone doing this role 
> > for Xen and its more than a fulltime job.  Same thing would have to 
> > happen for an OLPC kernel.  Certainly the amount of work is commensurate 
> > with the nature of the changes.  Having seen the RT patch set, that is 
> > invasive and would also require similar effort.
> 
> I've got Marcelo Tosatti and David Woodhouse to do this work for OLPC. 
> I'm hoping that they will be able to do most of their work upstream and 
> we pick up changes that way but I know that we're going to have local 
> changes both for the same of experimentation and because maybe we need 
> something that hasn't been taken.  In either case, we're going to have 
> to have a variant for OLPC.  I'm sure that RHEL doesn't care about the 
> things that we do and we don't care about 90% of the RHEL drivers. :)

Working upstream and in a fashion that is acceptable to upstream are two
things that David and Marcelo are exceptionally good at.  I don't think
you need to worry about that particularly.

> > - As was pointed out earlier, the path to the Fedora kernel leads from 
> > upstream.
> 
> It is but the idea that "one kernel is enough" doesn't fly when you're 
> supporting more than one product, certainly from the RHAT side of the 
> fence and even more so when we're trying to enable other people to use 
> Fedora to experiment and do other interesting things.  We need to get 
> creative and find a way to scale instead of just saying "it's hard."

Ok, I'm going to stumble here a bit because I think we're coming at this
from two totally different viewpoints.  Bear with me.

What products is Fedora supposed to be supporting?  If you look at it
from existing kernels today, I see: stock, Xen, GFS, cman, dlm and gnbd.
Then we're talking about others like OLPC, CCRMA, etc.

Now, take a step back and look at all that for a second.  How many of
those are really installed by the typical Fedora user?  I'd say probably
2, stock and Xen.  Why?  Because those two have the most value to the
majority of Fedora users.  (Yes, I'm completely ignoring the fact that
the other kernels have a large value to Red Hat as a _company_.
Hopefully you'll see why in a second.)

You bring up an excellent point in that there _are_ people that want to
do new and interesting things with Fedora.  And that if those people
_are_ interested in some of the other variants, they should be
accessible.  However, I don't think having all of those kernels being
officially pushed out by the buildsys is required.  In fact, it often
doesn't happen anyway because the patches don't apply or build at any
given moment.

So, how can we enable those that want to play with these other kernels?
I think it's going to come down to something along the lines of having
those kernels be projects in and of themselves.  And by project, I mean
projects like plague, mock, etc.  That's part of the reason I'm so
interested in getting a hosting system in place that works and works
well.  It would allow those that want to tinker with things to either
build the kernel themselves, or pull from a project specific repo.

Now, once those kernel projects become more stable, then you can take a
two pronged approach.  You start pushing stuff upstream, and you start
moving stuff into Core as Xen, GFS, etc are currently done.  But trying
to actually do _development_ of the kernels that way just doesn't scale
and causes the burnout that lots of people have talked about already.

So here are the questions that I see:

1) Who maintains kernel project X?

Depends on the project.  For something like OLPC, it would be David and
Marcelo obviously.  And if a project fizzles and dies, then it probably
wasn't going to have tons of value add anyway.

2) What about all the security issues?

My cynical approach on that is they happen anyway, even with today's
model so it's not really different.  Think about it.  A user has xen
kernel X installed from rawhide.  A new kernel is pushed out that fixes
a security issue, but Xen doesn't build so it doesn't get a kernel
update.  Does that user reboot into the new kernel even though Xen
doesn't work?  That choice is largely up to them and it still would be
with doing stuff in a project.  It's not ideal, but I don't think it's
any worse off.

3) What about the "bugs reported against the Fedora kernel incorrectly"
issue?

I'm naively hoping the ideas for the bug reporting tool that Will and
Greg and others are kicking around will help with that :).  I have no
good answer for this, mostly because when you talk about multiple
kernels there really is no golden bullet for this problem.

Is this all a crack-rock idea?  Maybe.  I got little sleep last night
and probably shouldn't be thinking too hard about anything important.
But I do think Chris is right.  One kernel isn't going to cut it for all
the "products" that are being played with and even all the users out
there.  At least with kernel projects the opportunity for external
people to dig in and help out becomes a bit easier to achieve.

josh

(And yes, having a bitbucket kernel project would be possible I suppose.
But I don't think it's sustainable in the long run and I don't think
you'll find anyone willing to maintain it.)