Re: Plan for tomorrows (20070726) FESCO meeting
On 26.07.2007 17:40, David Woodhouse wrote: On Thu, 2007-07-26 at 17:36 +0200, Thorsten Leemhuis wrote: On 26.07.2007 17:26, David Woodhouse wrote: On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: [...] People can go and implement kmod stuff in their own repositories -- we _really_ don't want to be putting the 'Fedora' name on it. If it's good enough for Fedora, it's good enough for the kernel RPM. If not, let them do it elsewhere. I see your point, nevertheless I think we should have kmods (and other experimental stuff) in a special testing repo For me the whole thing is connected to current target audience discussion on FAB. Fedora is trying to do lots stuff right, even if it's bad for Fedora (firefox.x86_64 by default, no kmods that don't head upstream, ...). That actually something I why I like Fedora and that's why I agree with you in the don't put the 'Fedora' name on it. Nevertheless a lot of users and maintainers often fail to understand our high standards. I'd like to give those users a solution and educate them while at it. And I want to get the maintainers involved in that testing ground as they might grow up and soon do other stuff in the project, which will help us growing. CU thl ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
David Woodhouse wrote: On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: 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. Yes, although I'd phrase it as that approach is fine for anyone who we'd actually want maintaining kernel code with the 'Fedora' name on it. But the code in question IMHO should show potential for a nearby upstream merge before it's being added. Absolutely. 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. It doesn't become any _less_ of a nightmare just because you ship it separately. If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all. I must say I like this approach, it avoids the whole problem of having to rebuild kmods all the time and of wether to delay kernel security updates until all kmods are fixetd etc. I do think however that this might cause some pain for Dave Jones, whose job already is hard. Maybe we should ask him what he thinks about this? Regards, Hans ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Who decides what drivers go on the install disk?
Chuck Ebbert ([EMAIL PROTECTED]) said: The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 Ditto for the uli526x network driver, network installs are impossible on systems using that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 The kernel has the drivers available, but people are reporting these as kernel bugs... module-info in the anaconda package. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
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-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Plan for tomorrows (20070726) FESCO meeting
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. 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. -- dwmw2 ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Who decides what drivers go on the install disk?
The arcmsr driver is in-kernel but you can't install to a system using it for the main disk controller: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249647 Ditto for the uli526x network driver, network installs are impossible on systems using that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246165 The kernel has the drivers available, but people are reporting these as kernel bugs... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
