| bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| * f13 is here | ||
| nirik is here, going to go grab coffee. | ||
| c4chris is here, hi folks | ||
| jeremy is here (mostly at least) | ||
| * bpepple barely got here. Had to flee to a coffee shop, since the homestead is without power. | ||
| * tibbs here | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| caillon | o_O | |
| bpepple | Hi, everyone! | |
| f13 | spot will not be making it | |
| (think he's getting a new sun box) | ||
| tibbs | He needs more sun. | |
| nirik | warren is also gone (dr appt) | |
| * bpepple will wait another minute or so to see if anyone else shows up. | ||
| bpepple | ok, let's get started. | |
| --- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00567.html | ||
| bpepple | Anyone have any problems with the FPC's emac proposal? | |
| nirik | was this just changes to the existing guidelines? I thought we already had some for emacs. | |
| oh, I guess it was just a draft before. | ||
| tibbs | Sorry for being late with the summary; the campus network took a dump when all the students came back. | |
| Yes, the emacs stuff has been in draft stage for ages. | ||
| bpepple | np tibbs, stuff happens. | |
| tibbs | It was blocked on changes to the existing emacs packages which have now gone through. | |
| nirik | +1 from me. Might need existing packages to update to come into compliance... | |
| jeremy | fine by me | |
| * bpepple is fine with it also. | ||
| c4chris | +1 | |
| bpepple | ok, I don't see any objections, so I think we can move on. | |
| f13 | cool | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Package builds should fail on empty debuginfo packages - spot | ||
| bpepple | I figured I would move this up on the schedule, since it seems like a no-brainer to me. | |
| nirik | +1, sounds good to me. | |
| bpepple | +1 here also. | |
| jeremy | +1 | |
| c4chris | +1 | |
| nirik | we might ask mdomsch to do a quick 'find . -name '*.debuginfo' -size 0' and see how many packages this might affect, but if we make it fail they will find out soon enough. | |
| tibbs | +1 | |
| f13 | +1 | |
| caillon_ | hm, the other me has seem to lost connection in case someone was trying to reach me | |
| f13 | caillon_: we're on the topic of making zero size debuginfo files fail the build. | |
| bpepple | caillon_, no problem we're just voting on a proposal for package builds should fail on empty debuginfo packages. | |
| nirik | I assume we also mean "for all branches" ? | |
| tibbs | I doubt anyone would turn this on for FC6 at this point. | |
| f13 | this would be devel/ going forward | |
| IMHO | ||
| c4chris | devel sounds saner | |
| bpepple | f13: agreed. | |
| caillon_ | yeah, changing tools behavior in released branches doesn't make sense | |
| nirik | yeah, true... devel+ makes sense. | |
| bpepple | let | |
| d'oh stupid keyboard! | ||
| bpepple | I see six '+1' on this so far. | |
| c4chris | I think spot wanted it | |
| f13 | yeah, he did. | |
| caillon__ | f13: was there a link to more info? | |
| bpepple | c4chris: yeah, your right. I think we can safely assume he was a '+1'. | |
| f13 | caillon__: I don't think so, there isn't a wiki proposal, but the basic idea is that 0 size debuginfo files are worthless, and if yo'ure creating such a thing either there is a bug in your package, or you should turn off debuginfo packages for our package. | |
| bpepple | caillon__: any other questions, or should we move on? | |
| caillon__ | yeah that seems sane, but i wonder how we'd even produce 0 size debug packages | |
| caillon__ | is it really a packaging problem or a problem in the buildsys? | |
| nirik | it can happen if permissions are wrong on binaries, or the build strips the binaries, or several other reasons. | |
| caillon__ | or build stack, e.g. strip, etc | |
| drago01 | caillon__: binarys strippend @ install | |
| caillon__ | okay. if it can happen by dumb packaging, then +1 for me, too | |
| jeremy | caillon__: usually a packaging problem (or upstream makefile problem) | |
| bpepple | anything else, or should we move on? | |
| caillon | move on | |
| bpepple | topic FESCO-Meeting -- MISC -- obsoleting kmod proposal: http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 | |
| I don't see dwmw2, so f13 you want to take this? | ||
| seems f13 stepped away. | ||
| nirik | perhaps we should table this another week... I think drjeff has a dkms thing too, which would probibly be related... | |
| bpepple | I would like to see this proposal sent to the mailing list anyhow, so we can get some feedback. | |
| c4chris | did anyone hear an opinion from davej or chuck ? | |
| bpepple | c4chris: I believe we had from chuck, but I'm not sure about davej. | |
| drago01 | can we be more verbose than "should" | |
| tibbs | Earlier discussion about letting folks into the kernel package wasn't terribly positve, I think. | |
| c4chris | drago01: which "should" | |
| ? | ||
| bpepple | tibbs: you mean from the kernel devels? or from the community? | |
| drago01 | damn... can't reach the site right now | |
| tibbs | From davej, but that's just my poor recollection. | |
| f13 | I'm here. | |
| |DrJef| | nirik, you mean in here? | |
| f13 | sorry | |
| bpepple | f13: no worries. | |
| drago01 | can someone reach this page? | |
| c4chris | I could a minute ago | |
| drago01 | works again | |
| bpepple | drago01: yeah, just pulled it up. | |
| nirik | |DrJef|: yes. Can you perhaps talk with dwmw2 and f13 about how your dkms proposal would work with their kmod proposal? | |
| f13 | davej/cebbert are going to be rather strict about what goes in, a very heavy "should" be on it's way upstream. | |
| --- nirik has changed the topic to: FESCO-Meeting -- MISC -- obsoleting kmod proposal: http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13 | ||
| |DrJef| | nirik, is dwmw2's remove kmod proposal somewhere? | |
| drago01 | c4chris: was talking about this "...and it _should_ be only drivers which are acceptable upstream and are shortly to be merged" | |
| |DrJef| | here's my dkms payload proposal http://fedoraproject.org/wiki/JefSpaleta/DKMSProposal?highlight=%28JefSpaleta%29 | |
| c4chris | drago01: k, thx | |
| nirik | I vote we table this here, and let |DrJef| talk with dwmw2 and then have them both post to the devel list and then we can look at what we need to decide next week? | |
| f13 | |DrJef|: see topic. | |
| |DrJef| | nirik, this was written as a followup to a a list thread where jwb_gone asked me to write an actual proposal | |
| caillon | if we start rejecting kernel modules based on quality, why aren't we doing this for other packages? | |
| |DrJef| | caillon, the argument is... kernel modules need to be mainlined.. | |
| c4chris | caillon: a non-working kernel is a bit more troublesome than a non-working app | |
| |DrJef| | caillon, as the mainline kernel is the established upstream | |
| f13 | caillon: we've /always/ had the opportunity to reject kernel modules. It used to fall on FESCo to vette them. | |
| caillon | |DrJef|: is that a fedora rule? | |
| tibbs | We could theoretically run into the same issues with, say, openoffice plugins or something. | |
| caillon | or firefox extensions | |
| |DrJef| | caillon, there is a strong desire to see them mainlined | |
| caillon | or a multitude of things | |
| tibbs | If said plugins broke with each minor openoffice update and had the potential to make openoffice itself break horribly in an undebuggable manner. | |
| caillon | |DrJef|: I'm not arguing that, I agree we want things mainlined. but is it something that we should be actively enforcing? | |
| |DrJef| | caillon, i think dkms payloads provide a middle ground, to encourage mainlining | |
| caillon | if someone wants to package it separately, and can meet the packaging guidelines, should we reject them? | |
| if so (and i think we do) we need to start thinking about making a policy for what types of things we can reject | ||
| |DrJef| | caillon, hence my proposal to allow source only noarch packages for kernel modules for dkms to rebuild locally | |
| drago01 | I don't want to bring this up again but what if a module does work fine but upstream don't want to merge it for whatever reason | |
| |DrJef| | drago01, works fine..now | |
| |DrJef| | drago01, there's a high maintainence burden for kernel modules that fail to work..on the next kernel rev | |
| f13 | drago01: it's up to the kernel maintainer to decide. | |
| caillon | there's an equally high burden for apps that depend on firefox right now | |
| f13 | we're never going to have policy that will cover each and every situation. | |
| drago01 | f13: ok fair enough | |
| |DrJef| | caillon, apps are not hardware access | |
| dgilmore | |DrJef|: though there is alot of pain in firefox updates | |
| |DrJef| | dgilmore, i dont disagree | |
| f13 | there is some past precidence with this too, compat-python24 | |
| |DrJef| | dgilmore, but firefox based apps... not working doesn't have the same level of recovery pain | |
| f13 | I'm somewhat OK with allowing the maintainer of a package to have some say over what addons for said package are allowed in the distro | |
| dgilmore | |DrJef|: no its not as critical | |
| caillon | f13: then we need to propose and ratify _that_ | |
| f13 | *sigh* | |
| |DrJef| | caillon, no more gecko dependant apps :-> | |
| * bpepple thinks we're getting off-topic. | ||
| caillon | heh | |
| c4chris | can we maybe start with the kernel case, then widen it to addons ? | |
| dgilmore | f13: i think we need to have better communication channels for dependent packages | |
| caillon | c4chris: I think the kernel case is an addon case. it's just the most critical case. | |
| drago01 | we need some kind of automatic dep rebuilds | |
| f13 | yeah, I'm not trying to fix the world, I'm just trying to fix the kernel. | |
| c4chris | caillon: sure, but it seems simpler to start there | |
| caillon | c4chris: not if we end up changing what we do for the kernel | |
| in the course of other things | ||
| |DrJef| | f13, i think dkms source-only noarch packages for addon modules solves some issues | |
| mdomsch | fyi, of the packages successfully building on i386, none have zero-sized -debuginfo | |
| f13 | except that it introduces a secondary package database. | |
| bpepple | mdomsch: cool. thanks. | |
| f13 | and all the fun associated. | |
| caillon | (note that I do think we should do this, just arguing that we need a more generic policy here. i'm not a fan of package specific policies) | |
| |DrJef| | f13, ? | |
| f13 | |DrJef|: jeremy knows more. | |
| |DrJef| | f13, why do you have to track a second database? | |
| mdomsch | the complaint is that 'rpm -qa' doesn't tell you everything, you have to 'dkms status' | |
| f13 | caillon: consider it amending the current package specific policy while we work on a more global policy. | |
| mdomsch | to know what's really in /lib/modules/ | |
| |DrJef| | mdomsch, dear god | |
| mdomsch | that's been jeremy's beef since day 1 | |
| |DrJef| | mdomsch, can't dkms roll local rpm packages and update the rpmdb? | |
| mdomsch | well, they'll file-conflict | |
| drago01 | but its better than having users install them from sources (not tracked at all) | |
| caillon | f13: fair enough. but let's get it on the table then to fix up right. | |
| |DrJef| | mdomsch, jeremy's beef.. or people actually using dkms's beef? | |
| dgilmore | |DrJef|: it doesnt solve the case where the dkms module is for the systems storage | |
| abadger1999 | FWIW, I don't like the kernel module exclusion on its theoretical basis, only on its practical value. So I'd lobby against expanding it to a general rule. | |
| caillon | for a different week if not now | |
| mdomsch | I've not heard a user complain | |
| |DrJef| | mdomsch, well then.... | |
| mdomsch | and we put into the Red Hat 'sysinfo' tool to call dkms status, so their tech support knows | |
| * nirik thinks both these proposals need more cooking on the lists... we arent going to solve everything here on them and get to voting on anything I don't think. | ||
| |DrJef| | mdomsch, why does jeremy feel he needs to track what dkms knows? | |
| * c4chris thinks... what nirik said :) | ||
| f13 pokes jeremy for input | ||
| mdomsch | dgilmore, dkms can deal with storage if I get the kernel package hooks in, so when a new kernel package is installed, dkms can get invoked automatically | |
| which, I point out, Ubuntu/Debian are now doing | ||
| * mdomsch dons asbestos underware | ||
| |DrJef| | mdomsch, that's just in the post install scriptlet action in the kernel package right? | |
| mdomsch | right | |
| |DrJef| | mdomsch, like inside the script that ends up calling mkinitrd | |
| mdomsch | right | |
| |DrJef| | mdomsch, minor | |
| mdomsch | new-kernel-pkg | |
| or somesuch | ||
| mdomsch | well, I've asked for that for 5 years, and keep getting ignored/rejected, so, minor yes, but execution, no | |
| f13 | coudln't you do the same with %triggerin ? | |
| dgilmore | mdomsch: cool that would be my only concern | |
| mdomsch | f13, no, %triggerin doesn't tell me what version of the new package is being installed | |
| or uninstalled | ||
| f13 | ah hah. | |
| mdomsch | and, triggers are evil (per ewt and LSB) | |
| :-) | ||
| * f13 mutters something about how kernel modules are a pain in the ass to do packaging work on. | ||
| mdomsch | anyhow, that's all detail, is that what's holding up these proposals? | |
| |DrJef| | f13, from a packaging standpoint.. enabling dkms pretty much equivalent to dealing with mkinitrd isnt it? | |
| bpepple | ok, we've got a little less than 20 minutes left, and should probably move on. |DrJef| could you get with dwmw2 & f13, and work on a proposal. | |
| |DrJef| | bpepple, i'll attempt it | |
| f13 | |DrJef|: not really. | |
| bpepple | |DrJef|: cool, thanks. | |
| bpepple | moving on then...... | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- initscripts LSB compliant - howto ? from Hans - all | ||
| tibbs | Oh yes please. | |
| f13 | is there anybody here that can talk intelligently about it? | |
| nirik | who was it that filed all those bugs? | |
| * nirik goes to look. | ||
| tibbs | Harald Hoyer, wasn't it? | |
| nirik | yep. | |
| bpepple | tibbs: I think you're right. | |
| tibbs | It was; bugzilla's just being slow. | |
| nirik | I think we should ping him again and try and get answers? | |
| Really that should be something that gets through the packaging folks, right? | ||
| f13 | probably | |
| bpepple | nirik: yeah. | |
| tibbs | It should have gone that route, yes. | |
| But he took it upon himself to file a ticket against any package with an initscript. | ||
| nirik | so, we should ignore those bugs for now, and ask Harald to submit a real draft ? | |
| bpepple | maybe we could get Harold to show up at the next packaging meeting. | |
| tibbs | I've tried to follow the instructions and have ended up more confused than before. | |
| dgilmore | bpepple: that would be a good idea | |
| tibbs | So in the end I can only hope that what I'm using doesn't break anything. | |
| f13 | the #1 ultimate thing to keep in mind | |
| do /not/ make any changes that would lead to you requiring redhat-lsb | ||
| nirik | well, I think he needs a formal proposed guideline doc in the wiki to submit to packaging, and they can ask him to clarify it until it looks acceptable. | |
| dgilmore | f13: indeed redhat-lsb is so wrong in many situations | |
| tibbs | Hopefully just changes to the comment block at the top are OK. | |
| bpepple | Does someone from the packaging committee want to contact Harold? Otherwise, I will. | |
| nirik | and answering the 'Unanswered questions' section. | |
| wwoods | f13: requiring redhat-lsb Considered Harmful? | |
| jeremy | wwoods: yes | |
| f13 | wwoods: extremely. | |
| jeremy | wwoods: bloats the install quite a bit | |
| wwoods | good to know. | |
| bpepple | Ok, we should probably move on. I'll contact Harold, and see if he can go to the next packaging committee meeting. | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Review of new features status http://fedoraproject.org/wiki/Releases/8/FeatureList- poelcat, jwb | ||
| abadger1999 | bpepple: Have him write a draft under PackagingDrafts/<something> and post it to fedora-packaging for feedback as well. | |
| bpepple | poelcat & jwb wanted to review the status of some of the new features, but it seems neither of them are here. :( | |
| abadger1999: will do. | ||
| abadger1999 | Thanks :-) | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | ok, anything else people want to discuss? | |
| nirik | FYI, I looked in bodhi the other day... we have: | |
| jeremy | I want to talk about a specific feature -- presto | |
| nirik | 102 updates in 'pending' older than 2 weeks. | |
| 50 in 'testing' older than 2 weeks. | ||
| f13 | lets give jeremy the floor | |
| bpepple | f13: agreed. | |
| bpepple | jeremy: ? | |
| jeremy | so it doesn't look like the buildsys side is going to get done in time for the feature freeze | |
| so definitely pulling having presto enabled and installed by default from the table for f8 | ||
| but I do want to continue to move forward with hopefully getting the buildsys side done and even getting the -updates repo presto-enabled if we can for f8 | ||
| wwoods | buildsys is the only blocker? | |
| f13 | allow it to be opt-in for F8 users, and default for rawhide? | |
| jeremy | f13: basically, yeah | |
| f13 | sounds good to me. | |
| jeremy | wwoods: buildsys and then the follow-ups of testing, etc | |
| (plus some tool side to pull out of the buildsys I guess, but that's the simple side) | ||
| bpepple | jeremy: sounds reasonable to me. | |
| jeremy | okay. so then what do we do with the feature page? just move it to proposed since it's not really an f8 feature? | |
| c4chris | we can gloat about it for F9 | |
| * nirik thinks thats fine...too bad it won't be in sooner tho. ;( | ||
| bpepple | jeremy: yeah, I think moving it to proposed makes sense. | |
| c4chris: agreed. | ||
| jeremy | nirik: yeah. just time ran out due to some more pressing issues for the buildsys side :( | |
| bpepple | jeremy: anything else on Presto? | |
| jeremy | nope, that was it | |
| bpepple | jeremy: cool. | |
| any other items before calling it quits? | ||
| poelcat | bpepple: i'm back | |
| * c4chris has nothing | ||
| bpepple | poelcat: just getting ready to wrap up the meeting. :( | |
| poelcat | bpepple: okay | |
| poelcat | it was more jwb's item than mine | |
| wasn't sure if FESCo wanted to do anything to encourage feature owner feedback for features that aren't done | ||
| i've pinged peope as much as I can | ||
| bpepple | poelcat: yeah, we should probably poke people a bit. | |
| nirik | so, did we want to revisit expiring or auto-pushing updates after 2 weeks? I guess we can next week... | |
| bpepple | nirik: let's add it to the schedule for next week. | |
| since we're out of time. | ||
| nirik | bpepple: ok. | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
| Thanks, everyone! | ||
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!