[fab] Non-standard kernels in the Fedora Multiverse

[Stephen John Smoogen]

On 5/8/06, Tim Burke <tburke at redhat.com> wrote:
> Tom 'spot' Callaway wrote:
> > On Mon, 2006-05-08 at 15:53 -0400, Greg DeKoenigsberg wrote:
> >
> >
> >> 1. If it's okay for RH to put nonstandard kernels into Fedora, then
> >> shouldn't it be okay for the community to put nonstandard kernels into
> >> Fedora?  If not, why not?
> >>
> >
> > I think the reasons why we don't want to do this have been made quite
> > clear. Its a maintenance nightmare. I already told the OpenVZ folks that
> > we couldn't have a "VZ enabled" kernel package in Fedora unless it went
> > into upstream (or they could convince Dave Jones to include it in his
> > SRPM).
> >
> >
> 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.
> - Above has to be done daily, virtually in realtime.  The minute that
> kernel build breaks (which will be frequently), it will be disabled in
> the build makefiles.  If it remains disabled for extended periods of
> time then end users in the community get disgruntled.
> - DaveJ is currently teetering on the edge of sanity, and doesn't need
> one more straw to break the camel's back.
> - As was pointed out earlier, the path to the Fedora kernel leads from
> upstream.
>
> In short, its generally hugely expensive in terms of ongoing manual
> labor/torture to keep another kernel afloat.  Not to mention that as
> Matt points out, any layered kernel modules (ie the dirty decoder/codec
> like stuff) won't work, or otherwise fragment the user base.
>
> _______________________________________________
> fedora-advisory-board mailing list
> fedora-advisory-board at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-advisory-board
>


--
Stephen J Smoogen.
CSIRT/Linux System Administrator