| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| * tibbs here. | ||
| spot pongs | ||
| dwmw2 | fish | |
| * c4chris here | ||
| bpepple | Hi, everyone. | |
| * notting is here | ||
| caillon | ! | |
| f13 | echo reply | |
| * nirik is here. | ||
| poelcat here | ||
| abadger1999 takes a seat in the peanut gallery | ||
| dgilmore is here | ||
| bpepple | Ok, looks like most folks are here, so 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/msg00010.html | ||
| bpepple | Any objections to the FPC proposal's from this week? | |
| tibbs | The board requested some license tag changes, so here they are. | |
| * spot will send out an email on how to adjust to license tag changes | ||
| nirik | both these require a lot of package change... do we want to suggest a target time for the changes? should they be done in all branches? | |
| notting | my concern on the user/group stuff is by making it non-fatal, it can hide the errors and potentially break systems | |
| tibbs | spot: When you do, please try to include something about determining whether you have an "or later" clause. | |
| spot | oh yeah. | |
| thats definitely part of it. :) | ||
| dgilmore | my question on user/group is how things like ldap users/groups are handled | |
| tibbs | dgilmore: They're handled just fine. | |
| spot | nirik: i'll cover that with the email too. :) | |
| tibbs | You create them ahead of time and things just work. | |
| nirik | license change looks good to me... +1 on that. | |
| dgilmore | tibbs: ok but the current way creates a local user/group also | |
| though uid/gids differ | ||
| tibbs | No, it doesn't if the user already exists. | |
| dgilmore | did for me | |
| tibbs | Then getent doesn't work on your system? | |
| nirik | on the group/user thing... does that mean fedora-usermgmt should be replaced accross the board? Perhaps we could generate a list of affected packages with fedora-usermgmt and another with just useradd? | |
| dgilmore | tibbs: not the proposed system but whats currently in use | |
| tibbs | Hence the proposed system... | |
| dgilmore | i have systems with mockbuild in ldap and local | |
| * c4chris has no issues with FPC proposal, so +1 | ||
| * bpepple gives a +1 to the license tag proposal. | ||
| f13 | +1 to both. | |
| notting | my other concern is if we're going to talk to LANANARAMA and the LSB about extending the system static range, we may want to put this on hold | |
| abadger1999 | nirik: Not sure.. We still have to figure out details of a static user addition. | |
| spot | notting: this is for dynamic UID/GID only | |
| static UID/GID assignment currently has no policy | ||
| abadger1999 | nirik: fedora-usermgmt is targeting that sector. | |
| dgilmore | +1 from me for both | |
| bpepple | +1 to user/group proposal. | |
| bpepple | Are there any objections? Otherwise we can move on. | |
| Ok, moving on..... | ||
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Feature Proposal Approval - http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat | ||
| nirik | looks ok to me... would be good to generate a list of affected packages tho and mail maintainers directly. | |
| bpepple | poelcat: do you want to lead this? | |
| f13 | gah, I just clicked on that thinking it was a new feature for Fedora 8 that I hadn't read about. | |
| poelcat | yes | |
| --- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Features/IcedTea | ||
| notting | +1 | |
| tibbs | +1 | |
| bpepple | +1 | |
| notting | well, should it be renamed sweettea? | |
| nirik | +1 | |
| c4chris | +1 | |
| skvidal | notting: +1 | |
| f13 | +1 | |
| dwmw2 | +1 | |
| f13 | so my question is | |
| though | ||
| what about ppc? | ||
| tibbs | Is there any actual reference page for IcedTea? The wiki links lead nowhere. | |
| dwmw2 | we're not ditching gcj yet are we? | |
| f13 | is this going to introduce a ton of rpm spec %ifing to use gcj on ppc but icetea elsewhere? | |
| dwmw2 | gbenson has been working on the jvm on ppc; I'll check his status | |
| f13 | dwmw2: /using/ gcj is the contengency plan | |
| which makes me think that IceTea would be replacing gcj | ||
| which is going to make building java packages.... interesting. | ||
| tibbs | Oh, never mind, only some of the wiki links are broken. | |
| f13: It isn't interesting already? | ||
| f13 | tibbs: not really | |
| tibbs: this would mean that java packages on i386/x86_64 are noarch, but on ppc/ppc64 arch specific | ||
| and that they use IceTea on i386/x86_64, but compile with gcj on ppc/ppc64 | ||
| tibbs | Oh, we're abandoning native code? | |
| dwmw2 | I thought we already shipped in both .jar and .so form? | |
| f13 | that's a /lot/ of spec crud to work through and there are a shitton of java packages. | |
| poelcat | how about if folks add questions or things they want clarified to the wiki page? | |
| dwmw2 | why would we abandon native code? I thought that was always going to be better? | |
| poelcat | otherwise it's going to get lost here | |
| dwmw2 | I didn't interpret the feature that way | |
| nirik | perhaps we could add a "Open Questions:" section at the end? | |
| f13 | dwmw2: well if you look at the jpackage packages, they have spec crud to go native on Fedora for gcj, but not anywhere else. | |
| poelcat | nirik: +1 | |
| f13 | I'm going to have to -1 this until I understand it more and how it impacts ppc | |
| (-1 as something for F8 that is) | ||
| dwmw2 | f13: well, I understood it to be just _shipping_ icedtea, not rebuilding all the java packages to stop using gcj | |
| bpepple | OK, I see six | |
| '+1', and one '-1'-. | ||
| dgilmore | +1 | |
| f13 | dwmw2: look at the contengency plan | |
| f13 | dwmw2: it says to fall /back/ to gcj | |
| bpepple | make that seven '+1', and one '-1'. | |
| f13 | which makes me think that they want to replace gcj. | |
| dwmw2 | f13: "for JPackage environment" | |
| --- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Releases/FeatureLaptopImprovements | ||
| * dgilmore has started doing some work to get IcedTea built for sparc | ||
| f13 | This feature request is for IcedTea to be the default JPackage environment in Fedora 8. | |
| dwmw2: that's what most our java packages are. | ||
| dwmw2: they come directly from jpackage, they just get built through our build system. | ||
| dwmw2 | f13: and they don't use gcj to build to native code at all, then? The whole point of jpackage is that you can use any jvm, right? | |
| f13 | no no no | |
| dwmw2: jpackage packages upstream use native, the jpackage packages built in Fedora use gcj | ||
| and the specs are littlered with ugly to deal with this | ||
| dwmw2 | I really think this proposal is just about using icedtea for 'java' and 'javac' like it says. | |
| hm, ok. I'll go with your '-1' until that's clarified then | ||
| caillon | I think we should seek clarification | |
| -1 for me on IcedTea as well | ||
| nirik | yeah, lets add questions there and look at it again next week? | |
| f13 | plus this could mean a mass rebuild of the java packages, which we'd want to time with other mass builds. | |
| nirik: I'd be Ok with that. Would have been helpful if the feature owner was here :/ | ||
| poelcat | okay, can concerned parties please list questions/objection on wiki so we can move on? | |
| bpepple | caillon: +1, let's have them clarify what the status of ppc is. If ppc is a blocker, we just use the contingency plan. | |
| poelcat: +1 | ||
| notting | note that whatever they decide, there will eventually be secondary arches that have to make the gcj/icedtea decision anyways | |
| poelcat | Vote on feature: http://fedoraproject.org/wiki/Releases/FeatureLaptopImprovements | |
| nirik | yeah, what about ARM? :) | |
| caillon | poelcat: +1 | |
| notting | laptop +1 | |
| tibbs | +1 for laptop improvements. | |
| bpepple | +1 | |
| f13 | +1 | |
| nirik | +1, although it would be nice to have some clever way to automagically point people at the troubleshooting thing. Perhaps some way to detect a boot up where the last one was a crash and they did a suspend... | |
| dwmw2 | +1 | |
| f13 | we can make the noise, perhaps we can do a dbus popup with the url | |
| notting | nirik: that exists | |
| bpepple | Ok, that's seven '+1'. | |
| caillon | nirik: fairly certain you can | |
| nirik | oh yeah? excellent. ;) | |
| dgilmore | +1 | |
| --- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Releases/FeatureNetworkManager | ||
| * bpepple didn't really expect anyone to object to that proposal. :) | ||
| caillon | poelcat: I'd like to remove this from voting this week | |
| (NetworkManager) | ||
| poelcat | caillon: your wishe is granted :) | |
| caillon | you weren't responding to my pings :( | |
| dwmw2 | Can we _please_ fix NetworkManager to allow system-wide WEP keys again before we make it the default? | |
| --- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Releases/FeatureVirtSecurity | ||
| tibbs | This seems a bit incomplete at this stage. | |
| dgilmore | caillon: id like a firstboot module to promt for enableing NetworkManager | |
| caillon | i'd like a pony :) | |
| just saying, is all | ||
| nirik | yeah, lots of stuff on the todo there... but all sounds good. | |
| dgilmore | i think we need remote Virtualisation management | |
| notting | +1 | |
| f13 | +1 | |
| dgilmore | we should push to get it in and right | |
| +! | ||
| tibbs | Yes, it's a good idea and good sense dictates that we want this. | |
| +1 | ||
| bpepple | +1 | |
| c4chris | +1 | |
| caillon | dwmw2: that's scheduled on the feature page | |
| dwmw2 | caillon: cool. | |
| qemu: 'TLS patches for VNC' ? | ||
| nirik | +1 | |
| bpepple | Ok, that's seven '+1'. Any other comments on it? | |
| dwmw2 | +1 | |
| --- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Releases/FeatureTexLive | ||
| tibbs | +1 | |
| But needs package reviews.... | ||
| f13 | +1 but missing contengency plan | |
| notting | f13: certainly the contingency is 'ship the old unmaintained cruft'? | |
| f13 | also should have release notes for people with non-Fedora packaged Tex dependant stuff | |
| nirik | +1 here. I can try and review part of it at least... | |
| notting | +1 | |
| c4chris | +1 | |
| f13 | notting: I can assume this, but we'd want to have a plan to remove any half included implementation | |
| dgilmore | +1 | |
| tibbs | I think two or three folks might want to work on a review of the main package. | |
| bpepple | +1 | |
| f13 | notting: and rebuild things if necessary for the old tatex | |
| bpepple | Ok, that's seven '+1'. Any other comments on it? | |
| warren | sorry, back now. | |
| dwmw2 | +1 | |
| --- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Releases/NepaliLanguageSupport | ||
| caillon | +1 nepali | |
| warren | what exactly is needed to be done? | |
| This isn't just a matter of adding packages? | ||
| bpepple | +1 | |
| notting | fonts, translations, IM | |
| warren | eh | |
| +1 | ||
| nirik | I think it needs more translating of other packages/modules. | |
| caillon | warren: read the link :) | |
| warren | I did | |
| c4chris | +1 | |
| nirik | +1 tho if they can do it... I don't know how much work is involved in adding a new translation. | |
| warren | It didn't sound like something we made a big deal about in the past. | |
| dwmw2 | firefox 'ongoing' | |
| f13 | comps work | |
| +1 | ||
| * notting asks for details, but is +1 anyway | ||
| dgilmore | +1 | |
| tibbs | Is it really required for firefox to be translated before we say that we have language support? | |
| f13 | tibbs: it's a pretty big peice. | |
| dwmw2 | well, how much time does a 'normal' user spend running ff? | |
| tibbs | Many KDE users never run it. | |
| So they'd see a full translation today. | ||
| caillon | tibbs: many do run it. | |
| bpepple | tibbs: it's probably the most popular piece of desktop software that Fedora ships, based just on the mugshot stats. | |
| tibbs | I don't dispute that. But you're not answering my question. | |
| notting | we don't actively claim to support any particular language, fwiw | |
| f13 | bpepple: wouldn't that automatically make mugshot the most popular piece of desktop software? | |
| notting | unless you count the list in anaconda, which is driven solely by anaconda translations | |
| caillon | tibbs: basd on bugs, I get more Firefox bugs by people running it on KDE than GNOME | |
| bpepple | f13: ;) | |
| tibbs | caillon: That's great, but it still doesn't anser my question. | |
| caillon | that just might be because it's more broken on KDE | |
| tibbs | "Is it really required for firefox to be translated before we say that we have language support?" | |
| f13 | tibbs: see notting | |
| nirik | I would think so, yes... | |
| caillon | yes | |
| bpepple | tibbs: I think it would. | |
| tibbs | I'm guessing the answer is yes. | |
| warren | One question | |
| We can't claim to support a language if all apps aren't translated | ||
| notting | all's a pretty big number | |
| warren | well, all the main apps | |
| nirik | all apps? is that possible even? | |
| caillon | then we can't claim to support any languages really other than english | |
| warren | Given that we don't claim to support other languages, I'm not sure it is worthwhile to claim this. | |
| Just do it | ||
| I would be +1 to mention "Added some Nepali language support" | ||
| or something like that | ||
| tibbs | That comes back to the question of why we're voting on these in the first place. | |
| warren | I don't think it is worthwhile to vote for these. | |
| unless it requires risk or a big change, this is neither. | ||
| caillon | it is a big change | |
| warren | how? | |
| caillon | to many packages | |
| bpepple | number of apps touched by this. | |
| Ok, we've got more than seven '+1' on this. we can probably move on. | ||
| --- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy | ||
| caillon | and translating firefox alone is itself a big change | |
| +1 | ||
| nirik | does this go to a wiki page we control? or ? | |
| notting | fwiw, there are 26 languages we support as an 'install language' in anaconda that we don't have firefox langpacks for | |
| caillon | assuming we're okay with the legal side (not sure if fesco decides that) | |
| f13 | I'm still a bit concerned by what is being popped up | |
| it sounds like our popup will allow people to go directly to fluendo without passing a Fedora filter | ||
| or is the popup supposed to be our Fedora filter? | ||
| bpepple | caillon: wasn't there a discussion recently on the fedora board mailing list on this? | |
| f13 | (note that it's easier to change a website when things go sour with fluendo than it is to issue a package update and ensure everybody gets it) | |
| dwmw2 | I'm slightly concerned by the precedent | |
| nirik | f13: +1... we need to have flexability with this. | |
| <-- cweyl has quit (Read error: 104 (Connection reset by peer)) | ||
| caillon | bpepple: it was a little long, and i don't remember it all. i'd have to go back and look. | |
| dwmw2 | what other non-free software do we point at? | |
| f13 | *cough* firmware | |
| dwmw2 | what are the criteria which make one 'OK' and another not? | |
| f13 | but we include that. | |
| caillon | f13: no, it would be contrled by fedora | |
| in case the third party ever turns evil | ||
| (not likely but just in case) | ||
| f13 | caillon: 'what' would be controlled? | |
| warren | dwmw2, I believe OK means, "Not FOSS, but doesn't violate any copyrights." | |
| f13 | caillon: is the control in the package, or in soemthing like a webpage that we can change instantly for everybody instead of a package update that trickles out over time? | |
| caillon | in the webpage | |
| dwmw2 | so that would include Oracle? :) | |
| abadger1999 | We also have the game data downloader that Hans wrote and packaged. | |
| warren | dwmw2, we choose what we want, typically it would be things that the user wants. Oracle doesn't fit that description. =) | |
| caillon | warren: no, the fluendo mp3 plugin is FOSS, just patent encumbered | |
| dwmw2 | warren: true :) | |
| tibbs | abadger1999: But that's for non-free content, not non-free software. | |
| bpepple | I'm fine with the idea of the codec buddy, but there still seems to be a ongoing discussion on the implementation (pointing to fluendo, etc) which concerns me a little. | |
| caillon | the implementation is going to point to a fedora controlled webpage | |
| bpepple | ah, missed that point. | |
| caillon | cgi script, or something like that | |
| f13 | +1 | |
| c4chris | +1 | |
| tibbs | +1 | |
| dgilmore | caillon: i think thats a big distinction thats its FOSS we are pointing to somewhere that provided patent licensing rather than something closed | |
| warren | +1 with the condition that FESCo participates with content for that page | |
| nirik | so if someone else came along with a mp3 plugin, we would add them to the list people could download from? is there any criteria for adding something there? | |
| bpepple | +1, with caillon's clariification. | |
| dgilmore | if it ponts to something fedora controlled im ok with it | |
| f13 | caillon: should make that a bit clearer in the proposal, bastion | |
| notting | nirik: i suspect 'board approval' | |
| +1 | ||
| dgilmore | +1 | |
| nirik | also, is this really going to be ready for f8? it was proposed in f7 and never happened... | |
| warren | caillon, can FESCo participate in the content definition? (not binding) | |
| notting | nirik: well, that's to be discussed at feature freeze time | |
| caillon | warren: I'm not the person to ask, but I don't necessarily think that's in FESCo's charter. | |
| nirik | sure. ok. +1 for now with the caveat that we look at the content/web page further. | |
| dwmw2 | +1 likewise | |
| poelcat | move on? | |
| bpepple | ok, I count ten '+1'. | |
| --- poelcat has changed the topic to: Clarification on http://fedoraproject.org/wiki/Releases/Features/NodokaTheme -- approved or not? | ||
| * poelcat wasn't sure where this was left last week | ||
| bpepple | poelcat: I really think it's in the art team's court. | |
| we've given our approval. | ||
| warren | I informed mizmo of the approval. | |
| f13 | yeah, it's in the Art realm | |
| poelcat | got it | |
| bpepple | I can poke mizmo for an answer. | |
| poelcat | same question on Presto | |
| http://fedoraproject.org/wiki/Releases/FeaturePresto | ||
| f13 | IIRC fesco wanted more information from the infrastructure team on this | |
| however, I'm perfectly fine with +1ing it and giving it a chance to happen before the freeze. | ||
| poelcat | did they get it ? :) | |
| f13 | if we miss the freeze, we just don't have it for f8, no biggie | |
| nirik | yeah, I would like to see it in... hopefully there are no infrastructure issues with it that can't be overcome. | |
| wwoods | F9 feature freeze is only 6 months away, after all | |
| f13 | wow | |
| notting | wwoods: AAAAAIYEEEEEEEEEEEEEE | |
| wwoods | HA HA HA IT NEVER ENDS | |
| * poelcat wonders if with slip of F8T1 the feature freeze date changes for F8? | ||
| f13 | drop down! increase speed! and reverse direction! | |
| poelcat: no | ||
| bpepple | poelcat: anything else? | |
| poelcat | bpepple: that covers it :) | |
| notting | wwoods: the releases never end... they just go on and on my friends... f13 started spinning them not knowing what it was, and he'll just keep on spinning them forever just because... the releases never end... | |
| bpepple | poelcat: great, thanks. | |
| * jwb is back | ||
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Hans question about kmod requirements - https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01428.html | ||
| f13 | Is there anybody here today that objected to the Presto feature last week? | |
| * bpepple pauses. | ||
| notting | bbiamin | |
| bpepple | f13: I don't believe anyone objected last week. | |
| f13 | hrm. | |
| ok. | ||
| well. | ||
| for the kmod question. My standpoint has always been a firm 'no' on kmods. I think there are better ways of solving the problem that don't involve nasty hacks like kmods | ||
| jwb | i polled the kernel list with this a bit ago | |
| f13 | I particuarly like dwmw2's suggestion of opening the kernel a bit more for those that really want to and can maintain a kmod and have it in the kernel itself. | |
| c4chris | any peep from the kernel maints about having stuff in the kernel package itself? | |
| warren | dwmw2, what are the qualifications of access to kernel? | |
| dwmw2 | davej and cebbert say "ok" | |
| to you and your code. | ||
| jwb | cebbert stated that kmods were a necessary evil | |
| dwmw2 | they can always disable it if it gets on their tits | |
| or just say 'no' to certain individuals and/or certain drivers. | ||
| c4chris | sounds good to me | |
| nirik | I'm leaning toward no kmods myself, but whatever is agreeable to davej/cebbert. | |
| f13 | yeah, I'm perfectly happy with letting them be the gatekeepers to what kmods are acceptable in Fedora or not. | |
| warren | How do you decide what is of sufficient quality to get into our kernel? | |
| And how does this encourage stuff to go upstream? | ||
| jwb | warren, you mean how do they decide | |
| they being davej and cebbert | ||
| dwmw2 | f13: where you don't actually mean 'kmod packages' you mean kernel modules as part of our kernel package? | |
| nirik | yeah, no kmods would encourage people to go upstream. ;) | |
| f13 | dwmw2: yes. | |
| warren | Not if we include it in the Fedora kernel? | |
| jwb | nirik, not if we carry it around as a separate patch for eons | |
| dwmw2 | having to maintain code in the kernel rpm certainly does encourage people to push their code upstream | |
| warren | (confused about what's being proposed) | |
| f13 | dwmw2: gate keepers to what kernel modules we carry that are outside upstream. | |
| dwmw2 | f13: yep | |
| warren: ban all kmod packages. If it's good enough for Fedora to ship, just put it in the kernel package. | ||
| warren | hm | |
| dwmw2 | davej and cebbert can, at their discretion, allow people to maintain a simple patch in the kernel package. | |
| f13 | while allowing those that can maintain a module to have access to the kernel cvs to do it. | |
| dwmw2 | they can always disable that patch if it becomes a problem | |
| nirik | jwb: no, I mean... if it's not upstream, we don't ship it... that would make people get in upstream first. | |
| dwmw2 | I've been doing various drivers like that for years | |
| bpepple | dwmw2: how would folks propose new kernel modules for inclusion? | |
| f13 | kernel rfe | |
| jwb | nirik, we don't do that today. would be a regression from the current state of things | |
| dwmw2 | bpepple: they'd show code on fedora-kernel-list and fedex beer to davej/cebbert to beg for their approval | |
| jwb | nirik, and there's also the fact that the kernel proper has stuff in it that isn't upstream | |
| warren | I'm OK with this if the kernel developers are able to disable those add-ons from a build if it becomes a problem. | |
| nirik | jwb: true. There are 2 kmods now | |
| warren | Those add-ons are understood to be second class citizens. | |
| f13 | it raises the bar for what gets in, and for who will maintain it. Currently we just say 'if you can construct an rpm, you get to maintain kernel code!' | |
| dwmw2 | warren: that's how it's always been with stuff like bcm43xx when I was adding that separately, various other examples before that. | |
| cebbert | problem is, patches have interdependencies | |
| bpepple | I'm fine with the idea also. | |
| jwb | f13, no we don't | |
| f13, kmods have to be acked by fesco first today | ||
| f13 | jwb: true, forgot about that step | |
| dwmw2 | cebbert: the kind of patch we should be letting people ship shouldn't. The kind of thing that _can_ be shipped as a kmod doesn't. | |
| cebbert: you can just say 'no' to anything intrusive :) | ||
| f13 | so, the question I have to ask, is how will this effect the 3rd party packagers? Are they then free to use whatever kmod method they choose? (and if so, is this really a bad thing?) | |
| warren | Strawman: kernel add-on's must 1) approved by FESCo 2) kernel maintainers must agree 3) they are understood to be second class citizens | |
| f13 | warren: does FESCO really need to get involved? | |
| warren | This however doesn't seem like a strong enough incentive to get stuff upstream. | |
| cebbert | dwmw2: when a module gets added it changes a Kconfig and those changes tend to clash | |
| f13 | warren: I'm happy with granting the kernel folks the rights to say yay/nay | |
| warren: we don't ack/nack any other patch the kernel folks carry | ||
| warren | f13, hmm, I guess that's a good idea. | |
| bpepple | f13: It might lessen the load for the kernel guys if it's fed thru FESCo first. | |
| f13 | bpepple: it's easy to say no.... (: | |
| nirik | cebbert: perhaps you could look at the 2 kmods we have now and see how intrusive they might be if they were put into the kernel cvs? | |
| f13 | but *shrug* | |
| warren | nirik, bug #? | |
| knurd_afk | nirik, both don't head upstream afaics | |
| dwmw2 | cebbert: true, but that's simple enough to deal with, and you can even just _disable_ the patch when there's a conflict like that, forcing the 'owner' to fix the one-line conflict. If you're not feeling helpful :) | |
| warren | Do we REALLY want to encourage stuff that will never go upstream? | |
| knurd_afk | nirik, so do we really want them in our kernels? I'd say no | |
| warren | What if someone wants AFS in the Fedora kernel? | |
| bpepple | f13: I'm fine with with FESCo not being involved. | |
| jwb | wait a second here | |
| dwmw2 | warren: absolutely not. I would expect davej/cebbert to veto inclusion of anything which isn't on its way upstream | |
| wwoods | well, I think you could make policy saying that you won't accept kernel patches that have no hope / plan for going upstream | |
| jwb | wwoods, careful | |
| warren | dwmw2, then this really isn't any different than today? | |
| dwmw2 | warren: dude, we _ship_ afs support, and it's getting better all the time (should be writable now, at last) :) | |
| nirik | em8300-kmod sysprof-kmod in cvs | |
| warren | dwmw2, eh!? | |
| * warren missed this =) | ||
| cebbert tries to figure out how squashfs got in there | ||
| dwmw2 | warren: proper AFS support. Not OpenAFS | |
| jwb | cebbert, yeah that's the one i'm thinking of | |
| wwoods | s/won't accept/reserve the right to reject/ | |
| jwb | cebbert, got in because anaconda switched to using that for it's images due to better performance/compresion than cramfs | |
| wwoods | ? | |
| dwmw2 | warren: currently we tolerate kmod packages. I suggest we should not tolerate them. | |
| if it's shippable by Fedora, it can go into the kernel proper | ||
| warren | If we accept this proposal, then it really wouldn't be any different than today, because we wouldn't allow stuff not heading for upstream into the kernel. | |
| nirik | sysprof isn't going in upstream. | |
| warren | dwmw2, shippable by Fedora or not-heading-upstream? what is the dividing line? | |
| Or just let the kernel guys decide the dividing line by fiat? | ||
| dwmw2 | warren: anything not heading upstream isn't shippable by Fedora anyway. | |
| warren | (I'm OK with that.) | |
| dwmw2 | by fiat. | |
| it's the only way | ||
| jwb | dwmw2, squashfs? | |
| warren | dwmw2, what about one of those Asterisk hardware drivers. GPL, but the company who makes it refuses to submit it upstream. Thus Fedora has never shipped it. | |
| * f13 coughs about xen | ||
| dwmw2 | xen got merged! | |
| warren | part of it anyway | |
| jwb | f13, xen got merged | |
| f13 | there likely isn't goign to be any hard/fast rules about what goes in/out | |
| jwb | f13, right | |
| f13 | not nearly enouhg to be interesting | |
| dwmw2 | warren: we don't ship Asterisk either. We do ship Callweaver thought, which forked and then started using POSIX timers instead of the zaptel crap | |
| * knurd_afk fears a ubuntu-like/ fc1 kernel package with lots of patches | ||
| f13 | we'll still continue to have to carry /large/ chunks of xen that isn't upstream in our kernels. | |
| dwmw2 | no, never lots of patches | |
| f13 | knurd_afk: our kernel guys won't let that happen | |
| knurd_afk: when we make them the gatekeepers, they can prevent the rot | ||
| knurd_afk | f13, hope so :) | |
| dwmw2 | we've _often_ had a bunch of drivers which are not-quite-yet upstream | |
| nirik | fyi, sysprof... see comment 8: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191745 | |
| * dgilmore wants zaptel drivers in fedora kernels | ||
| dwmw2 | we had USB DSL stuff. We had bcm43xx. We currently have wireless-dev. | |
| * dwmw2 wants mISDN. | ||
| dwmw2 doesn't want any more fucking ponies. Bloody woman has two horses already | ||
| dgilmore | dwmw2: damn ponies | |
| dwmw2 | what I'm proposing isn't really much of a different on the kernel side from what we've been doing for years | |
| it's just that _anyone_ who's actually going to do a good job of looking after such patches can ask if they may do so, rather than just insiders. | ||
| f13 | it makes it a /ton/ better for end users | |
| jwb | i'm ok with this, providing there isn't some idiotic hard rules about what goes in or what stays out | |
| dwmw2 | and we say 'no' to this kmod-package abomination | |
| warren | We decide everything, you don't have an option of making add-ons. End of story? | |
| * cebbert isn't so sure about giving commit access to a bunch of new people, though | ||
| f13 | because dealing with kmod packages and all the hell associated is Not Fun. | |
| dwmw2 | jwb: no rules. davej/cebbert get to say yes or no depending on how much beer you buy them | |
| jwb | dwmw2, k | |
| libertyy | kmod-package abomination? | |
| f13 | cebbert: you can play patch monkey for a bit... | |
| nirik | dwmw2: I like it... as long as cebbert and davej buy in | |
| dwmw2 | cebbert: you can throw rocks at them from a great height if they touch anything but their own driver, and revoke their access. | |
| nirik: they don't have to buy in. They only have to say 'no' to every person who asks :) | ||
| cebbert | true | |
| warren | So the dividing line has nothing to do with heading-to-upstream | |
| dividing line is completely arbitrary | ||
| dwmw2 | warren: the dividing line is the same dividing line we've always had for kernel code. | |
| jwb | which means there is no dividing line | |
| dwmw2 | right | |
| it's mostly just taste. | ||
| warren | Add to proposal: Have a registry somewhere that keeps track of every second class citizen part of the kernel. | |
| nirik | dividing line is the people who maintain the package and know about it seeing it something is unsupportable. | |
| * knurd_afk still votes for a unsupported "fedora testing area" with kmods | ||
| f13 | warren: it's now completely fair | |
| dwmw2 | which is closely related to the chances of getting upstream | |
| jwb | warren, like a section in the kernel spec | |
| f13 | warren: the rules that Fedora kernel develpers use to decide what goes into the kernel are now the same rules that everybody uses to determine what external modules we ship | |
| * bpepple see that we are already past our meeting end time. | ||
| notting | f13: so, have to apply for approval from the fedora steering committee - kernel? | |
| f13 | notting: ha ha | |
| warren | I'm not fully comfortable supporting this yet. Can we have it written out formally and another week to think about the exact details first? | |
| bpepple | warren: +1 | |
| * notting is +1 to asborbing or nuking all kmods | ||
| cebbert | davej hasn't weighed in yet either | |
| * c4chris likes the no-kmod, push-to-kernel, have-kernel-maints-as-gatekeeper approach | ||
| dwmw2 | +1 to that, obviously. | |
| jwb | i want davej to ack it | |
| * caillon takes off | ||
| warren | Will cebbert and davej be tough to encourage things to go upstream? | |
| jwb | because it hits him mostly | |
| cebbert | warren: yes :) | |
| dwmw2 | warren: fuck yes. Of course they will. | |
| warren | OK, who will write the written proposal with exact details? | |
| This is far too fuzzy. | ||
| cebbert | otherwise we have to maintain the damn thing forever | |
| warren | dwmw2, since you feel so strongly about getting rid of kmods, can you write the proposal? | |
| dwmw2 | warren: simple form "no kmod packages ever" :) | |
| cebbert | anyone know if the Atheros wireless drivers are being worked on for upstream? | |
| dwmw2 | cebbert: I've seen noise about the openhal being OK (again) | |
| notting | cebbert: what, are you planning on stapling the xen example to all requester's foreheads? | |
| warren | cebbert, want a staple gun? =) | |
| wwoods | cebbert: I've heard rumors (on the internets) that there may be some in progress | |
| cebbert | notting: hey, we took Xen out of the kernel package | |
| wwoods | but that was linville speculating before F7 release | |
| jwb | wwoods, SFCL cleared it again | |
| that's the last i heard | ||
| warren | Does Atheros have a firmware as well? | |
| We have to move-on or end. | ||
| jwb | are we voting or waiting? | |
| nirik | wait until next week, and discuss on lists | |
| bpepple | jwb: I think we should wait, but that's just me. | |
| warren | wait | |
| jwb | i think we should wait for a sign off from davej and cebbert | |
| nirik | that too. | |
| bpepple | Does anyone want to start on a proposal for this? | |
| dwmw2 | I'll do it | |
| bpepple | dwmw2: thanks. | |
| drago01 | what about kqemu ... seems not to be heading upstream :( | |
| bpepple | Anything else, or should we wrap it up for this week? | |
| c4chris | wrap++ | |
| dwmw2 | I may not make the meeting next week. I'll be on UTC+8 | |
| jwb | drago01, you'd have to ask davej or cebbert ;) | |
| dwmw2 | but if I come up with a proposal I'm sure f13 will be happy to push it next week :) | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| drago01 | jwb: ok ... cebbert ? | |
| f13 | dwmw2: yes I will. | |
| bpepple | -- MARK -- Meeting End | |
| cebbert | yeah, I'd like to see something in writing | |
| bpepple | Thanks, everyone. | |
| jwb | drago01, best to ask on fedora-kernel. you'll get both at the same time then | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!