On 26.07.2007 16:57, David Woodhouse wrote: > On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: >> Another issue I would like FESco to look at is the current somewhat grey state >> of kmod's I'm considering packaging kmod's for uvc (usb video class driver), >> lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in >> rawhide). But before I invest time in these I would first like to have the >> state of kmod's cleared up. I will try to work with there resp. upstreams to >> get them in the upstream kernel, and atleast for uvc and islsm upstream merger >> is planned already. > > I would still like to see kmod packages entirely deprecated in Fedora. I would like to see kmod packages entirely deprecated in the Everything spin of Fedora 8and thus updates-proper as well), but at the same time would like us to open a official testing area in the scope of the fedora project with a special repo for kmods and its deps to easen testing of that code, help getting it ready for upstream merge and semi-easy access for users. > If you want to maintain that kernel code and ship it with the 'Fedora' > brand on it, why don't we just give you commit access to the kernel > package? We can trust you to limit yourself to just those areas, and we > can trivially disable your patch(es) if it gets in the way of progress. > > We've done precisely that kind of thing before (including for bcm43xx > before that got merged). There's just no need for separate packages. I tend to say that approach is fine for you, Hans and some other developers that are familiar with kernel-coding as those people have shown to be able to get code upstream and know how to work with upstream. But the code in question IMHO should show potential for a nearby upstream merge before it's being added. But users and packagers want some modules that do not head upstream in the near future -- let's take the lirc kernel-modules as example, where the lirc-upstream afaik is not actively working on getting the code into linus kernel. Nobody else is doing that either. I'd prefer to not have stuff like that in fedora's kernel rpm, as that could soon and in a major maintenance nightmare, which we all want to avoid afaics. CU knurd -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
