Plan for tomorrows (20070726) FESCO meeting

[Thorsten Leemhuis]

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