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...

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. :-)

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. 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.

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 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.

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.

If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all.

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 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?

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(a)hhs.nl&gt; 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.

On Thu, 26 Jul 2007 17:43:33 +0100 David Woodhouse <dwmw2(a)infradead.org&gt; 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?