[fab] Non-standard kernels in the Fedora Multiverse

[Christopher Blizzard]

Josh Boyer wrote:
> 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.

I need to worry about the fact that I need a kernel that has wildly 
different preferences and possibly patches than the stock fedora kernel. 
  We will not be using the stock i686/i586 kernel.  We know we do most 
of that work upstream, but what about the stuff that doesn't?  And the 
fact that it has a different config?

> 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.

I think you're right.  So I will create a dichotomy here.  I think that 
the two things we're talking about here are 1. people who want to 
experiment and play and 2. people who want to drive something to product 
status.  Both of them are valid and both of them need to have Fedora as 
the center point for the code and the effort.

> 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.

This is the one that I think we're going to have the most problems with. 
  Even in the "play" case above, people still want reasonable security 
updates.  And the farther that you fork from the main kernel the harder 
it is to come back and apply security updates.

I'm not sure what to do about this case, but we need some creative 
thinking.  We want people to be able to follow, modify and keep updates. 
  From our tree (think productize, as OLPC does) our outside of our tree 
(think audio projects/realtime patches.)  How do we enable that and 
create the best incentives to keep updated as closely as possible?

--Chris