Kernel Modules in Fedora -x

[Jesse Keating]

On Fri, 03 Aug 2007 20:24:00 +0200
Thorsten Leemhuis <fedora at leemhuis.info> wrote:

> There are lot's of cases and situations in the world where
> kernel-module packages are needed -- updated or new open-source
> drivers for testing are a valid area IMHO. I think we should not
> ignore those and other cases completely.

And every single one of those cases has lead to very difficult to
manage user situations or lots of really really ugly hacks to make rpm
and yum handle this bad situation.  You could make the same argument
for any big package.  Why should oo.org-writer users have to consume an
oo.org update just to fix something in oo.org-impress?  Surely we
should just make all these external srpms that we can build at will
right?  It's not like we don't update the kernel often, and I think
we'd all benefit from making kernel changes at the same time rather
than having it happen at random, whenever each of the modules decide to
rebuild.

> 
> But well, your statement IMHO shows nicely how Fedora sometimes acts.
> For heavens sake we at least got firefox.i386 due to the multilib mess
> (and firefox-32 thx to warren) -- otherwise we'd still would leave
> people out in the cold just do encourage 3rd-party plugin-writers to
> port their stuff to x86_64. Side not one the current "thinking about
> the Fedora brand" thread on FAB-list: maybe we should just say
> "Fedora only gives you what it thinks is good for you, even if it
> creates trouble and headaches for you".

Don't confuse "how Fedora acts" with my opinions and wishes.  I don't
have the authority to make new blanket policy and define new rules.
All I can do is suggest then and put them up for vote (and in a few
places I have the right to vote).  All decisions like this are voted on
by a panel of your duly elected representatives.

> 
> >> I'm just wondering in general about the current happenings -- some
> >> months ago the Board issued a statement to allow kmods but now a
> >> new FESCo shoots it down again. Well, not my business as well.  
> > We're not saying no to non-upstream kernel modules, which is at the
> > heart of what the board wants (at least from my understanding of the
> > topic).  All we're doing is trying to redefine the delivery
> > mechanism so that it is easier for all parties involved.  
> 
> And davej indicated that he does not want more out-of-kernel modules.
> 
> That fact and the "at least from my understanding of the topic" IMHO
> makes it worth to ask the Board for its opinion.

Having just had a conversation with Davej on irc, I can offer these
tidbits:

<davej> f13/j-rod: so, my stance on not-upstream modules in the fedora
kernel... 

<davej> if we have someone actually working towards getting
that stuff upstream, I have *no* objection to it being included. (well,
with some caveats, like some mods are clearly crack)


He then reviewed the two current kmods:

<davej> this doesn't look like it'd need huge amounts of work to get
into an upstreamable state 

<davej> it'd need to lose crap like devfs
support though 

<davej> and all the #ifdef KERNEL_VERSION < 2.5.x junk


<davej> but the key blocker is, is someone going to do the work to get
it into that state? 

<jwb> davej, ok... so given that if the maintainer
was willing to work on that would you let them carry it in the main
kernel as a patch? 

<davej> jwb: if someone was working on it, sure.


<davej> so.. moving on to systrace..  just needs a champion to work on
upstream merge really, otherwise it'll just sit there.

So it looks like Dave is absolutely willing to let out of tree kernel
modules in, so long as they have a hope of going upstream, or a really
really really good reason why we should continue carrying it forward.

He even spoke of perhaps a timeout, where you get one Fedora release to
beat it into shape and get it upstream or we re-review it and perhaps
toss it out at the next Feature Freeze.  Could be doable.  But this
tells me that a draft to allow this isn't dead in the water on
insta-kernel-nack.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20070803/ad9c3cb4/attachment-0002.bin