On Fri, 03 Aug 2007 20:24:00 +0200 Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> 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?
Attachment:
signature.asc
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
