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.
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
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.
On 26.07.2007 17:26, David Woodhouse wrote:
On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: [...]
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.
I'd even say the nightmare is a bit bigger.
If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all.
Users want it and we have people wanting to package and maintain those drivers. So let's give them a playing area with a big fat warning sign. That's IMHO way better to leave them out in the cold.
Cu knurd
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: [...]
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.
I'd even say the nightmare is a bit bigger.
It's a lot bigger.
If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all.
Users want it and we have people wanting to package and maintain those drivers. So let's give them a playing area with a big fat warning sign. That's IMHO way better to leave them out in the cold.
Users want ponies too.
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.
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
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
Hans de Goede wrote:
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?
well this will cause problems for Dave and Chuck because when one of this modules does not build they either have to fix it or just disable it. 1) creates more work for the kernel maintainers 2) does not solve the problem at all
kernel@lists.fedoraproject.org
-
David Woodhouse -
drago01 -
Hans de Goede -
Thorsten Leemhuis