F7 Plan (draft)

Jesse Keating jkeating at redhat.com
Wed Dec 20 16:30:43 UTC 2006


On Wednesday 20 December 2006 11:22, Tim Burke wrote:
> I don't think we are prepared to *responsibly* deliver the realtime
> kernel in FC7.  Consider that there have been infinite threads on the
> trauma Xen has introduced.  Such as a zillion patches, often out of
> sync, etc.  Well, currently the realtime kernel is also a zillion
> patches - many of which conflict with Xen.
>
> afaik, we were not intending to have someone on the realtime space who
> is constantly keeping up to date with the Fedora rebasing etc (like Juan
> does for Xen). Sure, Ingo frequently rebases to upstream, but not
> against the Fedora variants.  I just don't want realtime to slow down
> Fedora.  Now, when enough of realtime is in upstream that its a
> manageable patch set, thats a different story... but that may be FC8.
>
> Things like Xen which are a major integration challenge make much more
> sense in Fedora.  There are installer, system startup, networking, yada,
> yada to sort out.  In contrast, realtime is primarily "just a kernel".  
> So the same integration challenges do not exist (knock on wood).  There
> is already an existing upstream community around the -rt patchset.  
> Based on this, we may not want to fragment the audience.
>
> Mind you, I'm not trying to holdback RT from Fedora.  I just don't think
> its mainstreamed enough to fit responsibly.  I welcome opinions though.

I honestly think that we can no longer deliver _anything_ significant in the 
Fedora kernels that isn't upstream.

So "delivering RT in Fedora 7" would be equivalent to doing the work necessary 
to get the bits into the upstream kernel, which Fedora would pick up.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20061220/855df095/attachment.sig>


More information about the fedora-advisory-board mailing list