Hi,
Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org:
/topic FESCO-Meeting -- MISC -- elect FESCo Chair - all
/topic FESCO-Meeting -- MISC -- Feature Proposal Approval - http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat
/topic FESCO-Meeting -- Rebuilding Packages -- Needs to decide whether to always rebuild, or only when toolchain warrants it - all
/topic FESCo meeting -- Free discussion around Fedora
You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase.
If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing...
Thanks, /B
Brian Pepple wrote:
Hi,
Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org:
/topic FESCO-Meeting -- MISC -- elect FESCo Chair - all
/topic FESCO-Meeting -- MISC -- Feature Proposal Approval - http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat
/topic FESCO-Meeting -- Rebuilding Packages -- Needs to decide whether to always rebuild, or only when toolchain warrants it - all
/topic FESCo meeting -- Free discussion around Fedora
You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase.
If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing...
I've got a somewhat strange question for FESco to look at, I would like to have an exception to the rule that all packages must be reviewed for the following set of packages:
* arm-gp2x-linux-binutils Cross Compiling GNU binutils targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749
* arm-gp2x-linux-kernel-headers Kernel headers for Cross Compiling to arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203
* arm-gp2x-linux-gcc Cross Compiling GNU GCC targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242206
* arm-gp2x-linux-glibc Cross Compiled GNU C Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242207
* arm-gp2x-linux-SDL Cross Compiled SDL Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243147
* arm-gp2x-linux-zlib Cross Compiled zlib Library targeted at avr https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243254
I've been trying to find a reviewer for them for ages, but there seems to be no-one with both the expertise and the time to review them. You all know that I'm a very serious packager, and that I have near 0 bugs open against my 135+ packages, so I hope that you will trust me to deliver good quality even without a review.
---
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.
Regards,
Hans
Wow, still no reviewer for arm-gp2x-linux-*? I'll bite the bullet and review these if you promise you'll do the same for my tigcc cross-toolchain once I submit it (should be in a few weeks, I need to spin a tarball without the optional non-Free A68k assembler). (TIGCC is just one package, so you'll get away with less work than me in the deal. ;-) )
Oh, and in exchange you can also review kdegames3 and atlantikdesigner (part of the KDE 4 plan, those are the packages for the KDE 3 games not yet ported to KDE 4) for me if the KDE folks don't get at it first. :-)
Kevin Kofler
Kevin Kofler wrote:
Wow, still no reviewer for arm-gp2x-linux-*? I'll bite the bullet and review these if you promise you'll do the same for my tigcc cross-toolchain once I submit it (should be in a few weeks, I need to spin a tarball without the optional non-Free A68k assembler). (TIGCC is just one package, so you'll get away with less work than me in the deal. ;-) )
Oh, and in exchange you can also review kdegames3 and atlantikdesigner (part of the KDE 4 plan, those are the packages for the KDE 3 games not yet ported to KDE 4) for me if the KDE folks don't get at it first. :-)
Deal!
Can you mail me the BZ links for those 2 kde packages please?
Regards,
Hans
Hans de Goede <j.w.r.degoede <at> hhs.nl> writes:
Deal!
Can you mail me the BZ links for those 2 kde packages please?
kdegames3: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248647
atlantikdesigner: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248648
Kevin Kofler
Hi, On 7/26/07, Hans de Goede j.w.r.degoede@hhs.nl wrote:
Brian Pepple wrote:
Hi,
Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org:
/topic FESCO-Meeting -- MISC -- elect FESCo Chair - all
/topic FESCO-Meeting -- MISC -- Feature Proposal Approval - http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat
/topic FESCO-Meeting -- Rebuilding Packages -- Needs to decide whether to always rebuild, or only when toolchain warrants it - all
/topic FESCo meeting -- Free discussion around Fedora
You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase.
If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing...
I've got a somewhat strange question for FESco to look at, I would like to have an exception to the rule that all packages must be reviewed for the following set of packages:
arm-gp2x-linux-binutils Cross Compiling GNU binutils targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749
arm-gp2x-linux-kernel-headers Kernel headers for Cross Compiling to arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203
arm-gp2x-linux-gcc Cross Compiling GNU GCC targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242206
arm-gp2x-linux-glibc Cross Compiled GNU C Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242207
arm-gp2x-linux-SDL Cross Compiled SDL Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243147
arm-gp2x-linux-zlib Cross Compiled zlib Library targeted at avr https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243254
I've been trying to find a reviewer for them for ages, but there seems to be no-one with both the expertise and the time to review them. You all know that I'm a very serious packager, and that I have near 0 bugs open against my 135+ packages, so I hope that you will trust me to deliver good quality even without a review.
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.
Just FYI, kmod's got always low priority from FESCO. The usual answer for kmods reviews are "why not kmod is added in upstream kernel yet?" I struggled a lot to get first spca5xx kmod in Fedora but failed as no one dare to review it. Then after it got considered as unsuccessful attempt, I tried on submitting gspca kmod. After much struggle I got KMOD_APPROVED on gspca-kmod package review. But then no one dare to review it even after I showed my willingness to maintain it for each kernel release in rawhide and with such unfortunate happened things, I decided to CLOSE my own package reviews for gspca kmod. I feel really bad for that. I am sure many peoples like to have some of the under development kmods in Fedora. I often used to get request from peoples about what happened to webcam kmods like gspca I tried to add in Fedora. Today also I got query for available webcam drivers in Fedora and RHEL, but unfortunately people now need to compromise on webcams for available webcam kmods in kernel. There are few webcam kmods which are, though under development but working well and their upstream is prompt to release updates for newer kernels. These kmods supports most of new webcams. But still we are not having those kmods approved in Fedora atleast.
Regards, Parag.
Just FYI, kmod's got always low priority from FESCO. The usual answer for kmods reviews are "why not kmod is added in upstream kernel yet?" I struggled a lot to get first spca5xx kmod in Fedora but failed as no one dare to review it. Then after it got considered as unsuccessful attempt, I tried on submitting gspca kmod. After much struggle I got KMOD_APPROVED on gspca-kmod package review. But then no one dare to review it even after I showed my willingness to maintain it for each kernel release in rawhide and with such unfortunate happened things, I decided to CLOSE my own package reviews for gspca kmod. I feel really bad for that. I am sure many peoples like to have some of the under development kmods in Fedora. I often used to get request from peoples about what happened to webcam kmods like gspca I tried to add in Fedora. Today also I got query for available webcam drivers in Fedora and RHEL, but unfortunately people now need to compromise on webcams for available webcam kmods in kernel. There are few webcam kmods which are, though under development but working well and their upstream is prompt to release updates for newer kernels. These kmods supports most of new webcams. But still we are not having those kmods approved in Fedora atleast.
Is this in need to be reviewed by the board or more waiting for a package review? I'd love to see gspca upstream, but also a kmod rpm would be superb.
Also while kmods have many problems, I think we'll continue to see use cases for them, so getting through the pain of maintaining them does build up useful infrastructure.
Last time I checked, building kmod rpms needed too many additional requirements, so I decided to stay at "make; make install" for each new kernel for my own machine.
regards,
Florian La Roche
Hi, On 7/26/07, Florian La Roche laroche@redhat.com wrote:
Just FYI, kmod's got always low priority from FESCO. The usual answer for kmods reviews are "why not kmod is added in upstream kernel yet?" I struggled a lot to get first spca5xx kmod in Fedora but failed as no one dare to review it. Then after it got considered as unsuccessful attempt, I tried on submitting gspca kmod. After much struggle I got KMOD_APPROVED on gspca-kmod package review. But then no one dare to review it even after I showed my willingness to maintain it for each kernel release in rawhide and with such unfortunate happened things, I decided to CLOSE my own package reviews for gspca kmod. I feel really bad for that. I am sure many peoples like to have some of the under development kmods in Fedora. I often used to get request from peoples about what happened to webcam kmods like gspca I tried to add in Fedora. Today also I got query for available webcam drivers in Fedora and RHEL, but unfortunately people now need to compromise on webcams for available webcam kmods in kernel. There are few webcam kmods which are, though under development but working well and their upstream is prompt to release updates for newer kernels. These kmods supports most of new webcams. But still we are not having those kmods approved in Fedora atleast.
Is this in need to be reviewed by the board or more waiting for a package review? I'd love to see gspca upstream, but also a kmod rpm would be superb.
Feel free to resubmit gspca kmod packages. I am no longer interested to submit in Fedora. I tried to submit gspca kmod which I really meant to submit gspcav2 kmod. later on upstream forked tarball to gspcav1. So if you want my old packaged gspcav2 rpms, download if from http://people.redhat.com/pnemade/Deffered/gspca/ These contains gspcav2 kmod.
Also while kmods have many problems, I think we'll continue to see use cases for them, so getting through the pain of maintaining them does build up useful infrastructure.
Last time I checked, building kmod rpms needed too many additional requirements, so I decided to stay at "make; make install" for each new kernel for my own machine.
regards, Parag.
On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote:
I've been trying to find a reviewer for them for ages, but there seems to be no-one with both the expertise and the time to review them. You all know that I'm a very serious packager, and that I have near 0 bugs open against my 135+ packages, so I hope that you will trust me to deliver good quality even without a review.
Since it looks like Kevin has volunteered to help out, I'll keep this of the schedule for now.
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'll go ahead and add this to today's schedule for you.
Thanks, /B
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 Thu, 26 Jul 2007 16:26:25 +0100 David Woodhouse dwmw2@infradead.org wrote:
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.
+10. Most the problems with external mods surround the headaches that rpm / yum has to go through to support them, and having them on the system when bugs occur. Regardless of where they live, we'll still have these pains so long as they're external to the kernel rpm. If they're in the kernel, then the only problem we have is carrying them forward and perhaps having them unloaded to dupe a problem, and marshaling bugs to the right people (but we do that anyway).
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
On Thu, 26 Jul 2007 17:48:57 +0200 Hans de Goede j.w.r.degoede@hhs.nl 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, if the module doesn't build fine with an update, most likely what's going to happen is the module gets disabled, which could result in even more frequent kernel updates just for getting a single module to build again.
On Thu, 2007-07-26 at 11:59 -0400, Jesse Keating wrote:
On Thu, 26 Jul 2007 17:48:57 +0200 Hans de Goede j.w.r.degoede@hhs.nl 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, if the module doesn't build fine with an update, most likely what's going to happen is the module gets disabled, which could result in even more frequent kernel updates just for getting a single module to build again.
I assume you're thinking of updates, not rawhide. In rawhide, Dave or Chuck send you a mail saying "your $FOO patch broke; I turned it off". You fix it, and it appears again in rawhide in a day or two.
In updates, such things are actually much less likely to break, except when we rebase to a newer kernel -- and if you've kept your driver working in rawhide then it should work fine when we rebase the release to the newer kernel anyway. Even if not, we tend to be quite conservative about releasing new kernels anyway -- they end up in updates-testing for some time, and that gives you time to get it working. The urgent security fixes are usually relatively small and unlikely to break drivers.
It's not something that scales hugely, but we don't _want_ it to. We should be sticking close to upstream, and not shipping drivers which aren't getting merged.
David Woodhouse wrote:
On Thu, 2007-07-26 at 11:59 -0400, Jesse Keating wrote:
On Thu, 26 Jul 2007 17:48:57 +0200 Hans de Goede j.w.r.degoede@hhs.nl 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, if the module doesn't build fine with an update, most likely what's going to happen is the module gets disabled, which could result in even more frequent kernel updates just for getting a single module to build again.
I assume you're thinking of updates, not rawhide. In rawhide, Dave or Chuck send you a mail saying "your $FOO patch broke; I turned it off". You fix it, and it appears again in rawhide in a day or two.
In updates, such things are actually much less likely to break, except when we rebase to a newer kernel -- and if you've kept your driver working in rawhide then it should work fine when we rebase the release to the newer kernel anyway. Even if not, we tend to be quite conservative about releasing new kernels anyway -- they end up in updates-testing for some time, and that gives you time to get it working. The urgent security fixes are usually relatively small and unlikely to break drivers.
That sounds an excellent way of handling this, can I say +1
Regards,
Hans
On Thu, 26 Jul 2007 17:43:33 +0100 David Woodhouse dwmw2@infradead.org wrote:
In updates, such things are actually much less likely to break, except when we rebase to a newer kernel -- and if you've kept your driver working in rawhide then it should work fine when we rebase the release to the newer kernel anyway. Even if not, we tend to be quite conservative about releasing new kernels anyway -- they end up in updates-testing for some time, and that gives you time to get it working. The urgent security fixes are usually relatively small and unlikely to break drivers.
It's not something that scales hugely, but we don't _want_ it to. We should be sticking close to upstream, and not shipping drivers which aren't getting merged.
Yeah that sounds reasonable. Any chance we could get a peep from Davej and Cebbert on this?
On Thu, 2007-07-26 at 13:30 -0400, Jesse Keating wrote:
On Thu, 26 Jul 2007 17:43:33 +0100 David Woodhouse dwmw2@infradead.org wrote:
In updates, such things are actually much less likely to break, except when we rebase to a newer kernel -- and if you've kept your driver working in rawhide then it should work fine when we rebase the release to the newer kernel anyway. Even if not, we tend to be quite conservative about releasing new kernels anyway -- they end up in updates-testing for some time, and that gives you time to get it working. The urgent security fixes are usually relatively small and unlikely to break drivers.
It's not something that scales hugely, but we don't _want_ it to. We should be sticking close to upstream, and not shipping drivers which aren't getting merged.
Yeah that sounds reasonable. Any chance we could get a peep from Davej and Cebbert on this?
I think they should approve any individual driver or system which gets added.
If they want to express disapproval of the whole concept, they can feel free to use a procmail filter to say "nah, sod off" to _every_ such request. :)
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