On Thu, Aug 02, 2007 at 08:20:26PM +0200, dragoran wrote: > On 6/16/07, Dave Jones <davej@xxxxxxxxxx> wrote: > > > > On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote: > > > > > I've started playing around with virtualization at work and the first > > thing > > > I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It > > was > > > GPL'd in February and although I realise Axel is packaging kmdl/kmods it > > > would be good to know if this is being queued up for mainline. > > > > not afaik.. I've not heard of anyone working on it since its initial > > opensource'ing, which seemed to be a reactionary thing in response to > > kvm's gaining popularity. > > > > > If not then can it be backported for Fedora kernels. > > > > It was fairly big (but not really invasive fwir), but it's still a delta > > that we'd perpetually have to carry vs upstream. Each patch adds a > > burden towards rebasing, and with no clear path for this to get > > upstream, it's questionable how long we'd have to carry it, so I'm > > not too enthusiastic to be honest. > > > well but kqemu seems not to break that often I just recompile it after each > kernel release and it just works. > the code might be big but it does not depend on (fast) changing interfaces. I'm really against merging more 'not upstream' things. We make a big deal about how close to upstream we are, and frankly in the last year or so, we've _sucked_ at keeping that statement true. Whilst some stuff is likely to end up in upstream at some point (utrace for eg), other stuff is perpetual baggage that is a pita when it comes to rebasing. Each release, we're getting closer though, as more and more old stuff gets thrown away. For eg, for F7, no-one cared enough about tux to really keep it maintained. Result - gone. Xen became such a hindrance it ended up having to go to its own package. The wireless stuff seems to be a sliding patchset, where the stuff it contains ends up upstream, but at the same time, a new batch of not yet upstream stuff arrives. I'm hoping eventually that too will settle down, but adding a driver here and a driver there is a path that I'd really rather we didn't travel due to the ongoing maintainence headache that it involves. A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there. Dave -- http://www.codemonkey.org.uk -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
