[fab] Non-standard kernels in the Fedora Multiverse

[Jeremy Katz]

On Tue, 2006-05-09 at 09:47 -0500, Rex Dieter wrote:
> Jeremy Katz wrote:
> > On Tue, 2006-05-09 at 00:01 -0400, Greg DeKoenigsberg wrote:
> >> On Mon, 8 May 2006, Stephen John Smoogen wrote:
> >>> I think that this request may fit into more of an Alternatives project
> >>> where multiple kernels and other tools might be able to look at.
> >> Yeah.  We killed off Alternatives a while back -- not because it wasn't a 
> >> good idea, but because it wasn't a good idea at the time.
> > 
> > I'm still not convinced it's a good idea... it does little to encourage
> > actually getting things merged.  And lots of forks ==> more work.
> 
> Yeah, but it's not *your* work, it's someone else who *wants* to do it. 
>   I think we should foster an empowering environment, and not take a 
> stance of "you can't do that!".

Except that bugs inevitably get misfiled or misattributed and so it is a
significant chunk of work.

> >> Here's the fallback position: Fernando continues to maintain the CCRMA
> >> kernel in his own yum repo, and *everything else* gets pulled into Extras
> >> over time.  (To the best of my knowledge, none of the CCRMA apps *require*
> >> the CCRMA kernel -- it's just a huge help for getting any actual work
> >> done.)  That way, at least Fernando has a mechanism to spread the workload
> >> for maintaining CCRMA among several assistants, and can spend most of his
> >> time maintaining his own kernel as he sees fit.
> > 
> > While that can work, I think this puts users in the worst place as a
> > non-mainline kernel will inevitably lag in terms of security fixes, etc.
> > And any kernel modules that are built in Extras won't be able to be used
> > for that kernel.
> 
> Well, that should be their (the users') call to make, understanding the 
> risks/rewards for using bits from Alternatives (of CCRMA).

Explaining that clearly is not going to be easy, if it's even
possible.  

Jeremy