FESCo Meeting 2007-08-02

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
* tibbs here.
spot pongs
dwmw2fish
* c4chris here
bpeppleHi, everyone.
* notting is here
caillon!
f13echo reply
* nirik is here.
poelcat here
abadger1999 takes a seat in the peanut gallery
dgilmore is here
bpeppleOk, 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
bpeppleAny objections to the FPC proposal's from this week?
tibbsThe board requested some license tag changes, so here they are.
* spot will send out an email on how to adjust to license tag changes
nirikboth 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?
nottingmy concern on the user/group stuff is by making it non-fatal, it can hide the errors and potentially break systems
tibbsspot: When you do, please try to include something about determining whether you have an "or later" clause.
spotoh yeah.
thats definitely part of it. :)
dgilmoremy question on user/group is how things like ldap users/groups are handled
tibbsdgilmore: They're handled just fine.
spotnirik: i'll cover that with the email too. :)
tibbsYou create them ahead of time and things just work.
niriklicense change looks good to me... +1 on that.
dgilmoretibbs: ok  but the current way creates a local user/group also
though uid/gids differ
tibbsNo, it doesn't if the user already exists.
dgilmoredid for me
tibbsThen getent doesn't work on your system?
nirikon 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?
dgilmoretibbs: not the proposed system   but whats currently in use
tibbsHence the proposed system...
dgilmorei 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.
nottingmy 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
abadger1999nirik: Not sure.. We still have to figure out details of a static user addition.
spotnotting: this is for dynamic UID/GID only
static UID/GID assignment currently has no policy
abadger1999nirik: fedora-usermgmt is targeting that sector.
dgilmore+1 from me for both
bpepple+1 to user/group proposal.
bpeppleAre 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
niriklooks ok to me... would be good to generate a list of affected packages tho and mail maintainers directly.
bpepplepoelcat: do you want to lead this?
f13gah, I just clicked on that thinking it was a new feature for Fedora 8 that I hadn't read about.
poelcatyes
--- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Features/IcedTea
notting+1
tibbs+1
bpepple+1
nottingwell, should it be renamed sweettea?
nirik+1
c4chris+1
skvidalnotting: +1
f13+1
dwmw2+1
f13so my question is
though
what about ppc?
tibbsIs there any actual reference page for IcedTea?  The wiki links lead nowhere.
dwmw2we're not ditching gcj yet are we?
f13is this going to introduce a ton of rpm spec %ifing to use gcj on ppc but icetea elsewhere?
dwmw2gbenson has been working on the jvm on ppc; I'll check his status
f13dwmw2: /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.
tibbsOh, never mind, only some of the wiki links are broken.
f13: It isn't interesting already?
f13tibbs: 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
tibbsOh, we're abandoning native code?
dwmw2I thought we already shipped in both .jar and .so form?
f13that's a /lot/ of spec crud to work through and there are a shitton of java packages.
poelcathow about if folks add questions or things they want clarified to the wiki page?
dwmw2why would we abandon native code? I thought that was always going to be better?
poelcatotherwise it's going to get lost here
dwmw2I didn't interpret the feature that way
nirikperhaps we could add a "Open Questions:" section at the end?
f13dwmw2: well if you look at the jpackage packages, they have spec crud to go native on Fedora for gcj, but not anywhere else.
poelcatnirik: +1
f13I'm going to have to -1 this until I understand it more and how it impacts ppc
(-1 as something for F8 that is)
dwmw2f13: well, I understood it to be just _shipping_ icedtea, not rebuilding all the java packages to stop using gcj
bpeppleOK, I see six
'+1', and one '-1'-.
dgilmore+1
f13dwmw2: look at the contengency plan
f13dwmw2: it says to fall /back/ to gcj
bpepplemake that seven '+1', and one '-1'.
f13which makes me think that they want to replace gcj.
dwmw2f13: "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
f13This 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.
dwmw2f13: 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?
f13no  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
dwmw2I 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
caillonI think we should seek clarification
-1 for me on IcedTea as well
nirikyeah, lets add questions there and look at it again next week?
f13plus 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 :/
poelcatokay, can concerned parties please list questions/objection on wiki so we can move on?
bpepplecaillon: +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
poelcatVote on feature:  http://fedoraproject.org/wiki/Releases/FeatureLaptopImprovements
nirikyeah, what about ARM? :)
caillonpoelcat: +1
nottinglaptop +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
f13we can make the noise, perhaps we can do a dbus popup with the url
nottingnirik: that exists
bpeppleOk, that's seven '+1'.
caillonnirik: fairly certain you can
nirikoh 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. :)
caillonpoelcat: I'd like to remove this from voting this week
(NetworkManager)
poelcatcaillon: your wishe is granted :)
caillonyou weren't responding to my pings :(
dwmw2Can 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
tibbsThis seems a bit incomplete at this stage.
dgilmorecaillon: id like a firstboot module to promt for enableing NetworkManager
cailloni'd like a pony :)
just saying, is all
nirikyeah, lots of stuff on the todo there... but all sounds good.
dgilmorei think we need remote Virtualisation management
notting+1
f13+1
dgilmorewe should push to get it in and right
+!
tibbsYes, it's a good idea and good sense dictates that we want this.
+1
bpepple+1
c4chris+1
caillondwmw2: that's scheduled on the feature page
dwmw2caillon: cool.
qemu: 'TLS patches for VNC' ?
nirik+1
bpeppleOk, 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
nottingf13: certainly the contingency is 'ship the old unmaintained cruft'?
f13also 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
f13notting: I can assume this, but we'd want to have a plan to remove any half included implementation
dgilmore+1
tibbsI think two or three folks might want to work on a review of the main package.
bpepple+1
f13notting: and rebuild things if necessary for the old tatex
bpeppleOk, that's seven '+1'.  Any other comments on it?
warrensorry, back now.
dwmw2+1
--- poelcat has changed the topic to: Vote on feature: http://fedoraproject.org/wiki/Releases/NepaliLanguageSupport
caillon+1 nepali
warrenwhat exactly is needed to be done?
This isn't just a matter of adding packages?
bpepple+1
nottingfonts, translations, IM
warreneh
+1
nirikI think it needs more translating of other packages/modules.
caillonwarren: read the link :)
warrenI 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.
warrenIt didn't sound like something we made a big deal about in the past.
dwmw2firefox 'ongoing'
f13comps work
+1
* notting asks for details, but is +1 anyway
dgilmore+1
tibbsIs it really required for firefox to be translated before we say that we have language support?
f13tibbs: it's a pretty big peice.
dwmw2well, how much time does a 'normal' user spend running ff?
tibbsMany KDE users never run it.
So they'd see a full translation today.
caillontibbs: many do run it.
bpeppletibbs: it's probably the most popular piece of desktop software that Fedora ships, based just on the mugshot stats.
tibbsI don't dispute that.  But you're not answering my question.
nottingwe don't actively claim to support any particular language, fwiw
f13bpepple: wouldn't that automatically make mugshot the most popular piece of desktop software?
nottingunless you count the list in anaconda, which is driven solely by anaconda translations
caillontibbs: basd on bugs, I get more Firefox bugs by people running it on KDE than GNOME
bpepplef13: ;)
tibbscaillon: That's great, but it still doesn't anser my question.
caillonthat 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?"
f13tibbs: see notting
nirikI would think so, yes...
caillonyes
bpeppletibbs: I think it would.
tibbsI'm guessing the answer is yes.
warrenOne question
We can't claim to support a language if all apps aren't translated
nottingall's a pretty big number
warrenwell, all the main apps
nirikall apps? is that possible even?
caillonthen we can't claim to support any languages really other than english
warrenGiven 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
tibbsThat comes back to the question of why we're voting on these in the first place.
warrenI don't think it is worthwhile to vote for these.
unless it requires risk or a big change, this is neither.
caillonit is a big change
warrenhow?
caillonto many packages
bpepplenumber 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
caillonand translating firefox alone is itself a big change
+1
nirikdoes this go to a wiki page we control? or ?
nottingfwiw, there are 26 languages we support as an 'install language' in anaconda that we don't have firefox langpacks for
caillonassuming we're okay with the legal side (not sure if fesco decides that)
f13I'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?
bpepplecaillon: 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)
dwmw2I'm slightly concerned by the precedent
nirikf13: +1... we need to have flexability with this.
<-- cweyl has quit (Read error: 104 (Connection reset by peer))
caillonbpepple: it was a little long, and i don't remember it all.  i'd have to go back and look.
dwmw2what other non-free software do we point at?
f13*cough* firmware
dwmw2what are the criteria which make one 'OK' and another not?
f13but we include that.
caillonf13: no, it would be contrled by fedora
in case the third party ever turns evil
(not likely but just in case)
f13caillon: 'what' would be controlled?
warrendwmw2, I believe OK means, "Not FOSS, but doesn't violate any copyrights."
f13caillon: 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?
caillonin the webpage
dwmw2so that would include Oracle? :)
abadger1999We also have the game data downloader that Hans wrote and packaged.
warrendwmw2, we choose what we want, typically it would be things that the user wants.  Oracle doesn't fit that description. =)
caillonwarren: no, the fluendo mp3 plugin is FOSS, just patent encumbered
dwmw2warren: true :)
tibbsabadger1999: But that's for non-free content, not non-free software.
bpeppleI'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.
caillonthe implementation is going to point to a fedora controlled webpage
bpeppleah, missed that point.
cailloncgi script, or something like that
f13+1
c4chris+1
tibbs+1
dgilmorecaillon: 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
nirikso 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.
dgilmoreif it ponts to something fedora controlled im ok with it
f13caillon: should make that a bit clearer in the proposal, bastion
nottingnirik: i suspect 'board approval'
+1
dgilmore+1
nirikalso, is this really going to be ready for f8? it was proposed in f7 and never happened...
warrencaillon, can FESCo participate in the content definition?  (not binding)
nottingnirik: well, that's to be discussed at feature freeze time
caillonwarren: I'm not the person to ask, but I don't necessarily think that's in FESCo's charter.
niriksure. ok. +1 for now with the caveat that we look at the content/web page further.
dwmw2+1 likewise
poelcatmove on?
bpeppleok, 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
bpepplepoelcat: I really think it's in the art team's court.
we've given our approval.
warrenI informed mizmo of the approval.
f13yeah, it's in the Art realm
poelcatgot it
bpeppleI can poke mizmo for an answer.
poelcatsame question on Presto
http://fedoraproject.org/wiki/Releases/FeaturePresto
f13IIRC 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.
poelcatdid they get it ? :)
f13if we miss the freeze, we just don't have it for f8, no biggie
nirikyeah, I would like to see it in... hopefully there are no infrastructure issues with it that can't be overcome.
wwoodsF9 feature freeze is only 6 months away, after all
f13wow
nottingwwoods: AAAAAIYEEEEEEEEEEEEEE
wwoodsHA HA HA IT NEVER ENDS
* poelcat wonders if with slip of F8T1 the feature freeze date changes for F8?
f13drop down!  increase speed!  and reverse direction!
poelcat: no
bpepplepoelcat: anything else?
poelcatbpepple: that covers it :)
nottingwwoods: 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...
bpepplepoelcat: 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
f13Is there anybody here today that objected to the Presto feature last week?
* bpepple pauses.
nottingbbiamin
bpepplef13: I don't believe anyone objected last week.
f13hrm.
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
jwbi polled the kernel list with this a bit ago
f13I 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.
c4chrisany peep from the kernel maints about having stuff in the kernel package itself?
warrendwmw2, what are the qualifications of access to kernel?
dwmw2davej and cebbert say "ok"
to you and your code.
jwbcebbert stated that kmods were a necessary evil
dwmw2they can always disable it if it gets on their tits
or just say 'no' to certain individuals and/or certain drivers.
c4chrissounds good to me
nirikI'm leaning toward no kmods myself, but whatever is agreeable to davej/cebbert.
f13yeah, I'm perfectly happy with letting them be the gatekeepers to what kmods are acceptable in Fedora or not.
warrenHow do you decide what is of sufficient quality to get into our kernel?
And how does this encourage stuff to go upstream?
jwbwarren, you mean how do they decide
they being davej and cebbert
dwmw2f13: where you don't actually mean 'kmod packages' you mean kernel modules as part of our kernel package?
nirikyeah, no kmods would encourage people to go upstream. ;)
f13dwmw2: yes.
warrenNot if we include it in the Fedora kernel?
jwbnirik, not if we carry it around as a separate patch for eons
dwmw2having to maintain code in the kernel rpm certainly does encourage people to push their code upstream
warren(confused about what's being proposed)
f13dwmw2: gate keepers to what kernel modules we carry that are outside upstream.
dwmw2f13: yep
warren: ban all kmod packages. If it's good enough for Fedora to ship, just put it in the kernel package.
warrenhm
dwmw2davej and cebbert can, at their discretion, allow people to maintain a simple patch in the kernel package.
f13while allowing those that can maintain a module to have access to the kernel cvs to do it.
dwmw2they can always disable that patch if it becomes a problem
nirikjwb: no, I mean... if it's not upstream, we don't ship it... that would make people get in upstream first.
dwmw2I've been doing various drivers like that for years
bpeppledwmw2: how would folks propose new kernel modules for inclusion?
f13kernel rfe
jwbnirik, we don't do that today.  would be a regression from the current state of things
dwmw2bpepple: they'd show code on fedora-kernel-list and fedex beer to davej/cebbert to beg for their approval
jwbnirik, and there's also the fact that the kernel proper has stuff in it that isn't upstream
warrenI'm OK with this if the kernel developers are able to disable those add-ons from a build if it becomes a problem.
nirikjwb: true. There are 2 kmods now
warrenThose add-ons are understood to be second class citizens.
f13it 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!'
dwmw2warren: that's how it's always been with stuff like bcm43xx when I was adding that separately, various other examples before that.
cebbertproblem is, patches have interdependencies
bpeppleI'm fine with the idea also.
jwbf13, no we don't
f13, kmods have to be acked by fesco first today
f13jwb: true, forgot about that step
dwmw2cebbert: 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 :)
f13so, 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?)
warrenStrawman: kernel add-on's must 1) approved by FESCo 2) kernel maintainers must agree 3) they are understood to be second class citizens
f13warren: does FESCO really need to get involved?
warrenThis however doesn't seem like a strong enough incentive to get stuff upstream.
cebbertdwmw2: when a module gets added it changes a Kconfig and those changes tend to clash
f13warren: 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
warrenf13, hmm, I guess that's a good idea.
bpepplef13: It might lessen the load for the kernel guys if it's fed thru FESCo first.
f13bpepple: it's easy to say no.... (:
nirikcebbert: 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?
f13but *shrug*
warrennirik, bug #?
knurd_afknirik, both don't head upstream afaics
dwmw2cebbert: 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 :)
warrenDo we REALLY want to encourage stuff that will never go upstream?
knurd_afknirik, so do we really want them in our kernels? I'd say no
warrenWhat if someone wants AFS in the Fedora kernel?
bpepplef13: I'm fine with with FESCo not being involved.
jwbwait a second here
dwmw2warren: absolutely not. I would expect davej/cebbert to veto inclusion of anything which isn't on its way upstream
wwoodswell, I think you could make policy saying that you won't accept kernel patches that have no hope / plan for going upstream
jwbwwoods, careful
warrendwmw2, then this really isn't any different than today?
dwmw2warren: dude, we _ship_ afs support, and it's getting better all the time (should be writable now, at last) :)
nirikem8300-kmod sysprof-kmod in cvs
warrendwmw2, eh!?
* warren missed this =)
cebbert tries to figure out how squashfs got in there
dwmw2warren: proper AFS support. Not OpenAFS
jwbcebbert, yeah that's the one i'm thinking of
wwoodss/won't accept/reserve the right to reject/
jwbcebbert, got in because anaconda switched to using that for it's images due to better performance/compresion than cramfs
wwoods?
dwmw2warren: 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
warrenIf 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.
niriksysprof isn't going in upstream.
warrendwmw2, shippable by Fedora or not-heading-upstream?  what is the dividing line?
Or just let the kernel guys decide the dividing line by fiat?
dwmw2warren: anything not heading upstream isn't shippable by Fedora anyway.
warren(I'm OK with that.)
dwmw2by fiat.
it's the only way
jwbdwmw2, squashfs?
warrendwmw2, 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
dwmw2xen got merged!
warrenpart of it anyway
jwbf13, xen got merged
f13there likely isn't goign to be any hard/fast rules about what goes in/out
jwbf13, right
f13not nearly enouhg to be interesting
dwmw2warren: 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
f13we'll still continue to have to carry /large/ chunks of xen that isn't upstream in our kernels.
dwmw2no, never lots of patches
f13knurd_afk: our kernel guys won't let that happen
knurd_afk: when we make them the gatekeepers, they can prevent the rot
knurd_afkf13, hope so :)
dwmw2we've _often_ had a bunch of drivers which are not-quite-yet upstream
nirikfyi, sysprof... see comment 8: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191745
* dgilmore wants zaptel drivers in fedora kernels
dwmw2we 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
dgilmoredwmw2: damn ponies
dwmw2what 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.
f13it makes it a /ton/ better for end users
jwbi'm ok with this, providing there isn't some idiotic hard rules about what goes in or what stays out
dwmw2and we say 'no' to this kmod-package abomination
warrenWe 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
f13because dealing with kmod packages and all the hell associated is Not Fun.
dwmw2jwb: no rules. davej/cebbert get to say yes or no depending on how much beer you buy them
jwbdwmw2, k
libertyykmod-package abomination?
f13cebbert: you can play patch monkey for a bit...
nirikdwmw2: I like it... as long as cebbert and davej buy in
dwmw2cebbert: 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 :)
cebberttrue
warrenSo the dividing line has nothing to do with heading-to-upstream
dividing line is completely arbitrary
dwmw2warren: the dividing line is the same dividing line we've always had for kernel code.
jwbwhich means there is no dividing line
dwmw2right
it's mostly just taste.
warrenAdd to proposal: Have a registry somewhere that keeps track of every second class citizen part of the kernel.
nirikdividing 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
f13warren: it's now completely fair
dwmw2which is closely related to the chances of getting upstream
jwbwarren, like a section in the kernel spec
f13warren: 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.
nottingf13: so, have to apply for approval from the fedora steering committee - kernel?
f13notting: ha ha
warrenI'm not fully comfortable supporting this yet.  Can we have it written out formally and another week to think about the exact details first?
bpepplewarren: +1
* notting is +1 to asborbing or nuking all kmods
cebbertdavej 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.
jwbi want davej to ack it
* caillon takes off
warrenWill cebbert and davej be tough to encourage things to go upstream?
jwbbecause it hits him mostly
cebbertwarren: yes  :)
dwmw2warren: fuck yes. Of course they will.
warrenOK, who will write the written proposal with exact details?
This is far too fuzzy.
cebbertotherwise we have to maintain the damn thing forever
warrendwmw2, since you feel so strongly about getting rid of kmods, can you write the proposal?
dwmw2warren: simple form "no kmod packages ever" :)
cebbertanyone know if the Atheros wireless drivers are being worked on for upstream?
dwmw2cebbert: I've seen noise about the openhal being OK (again)
nottingcebbert: what, are you planning on stapling the xen example to all requester's foreheads?
warrencebbert, want a staple gun? =)
wwoodscebbert: I've heard rumors (on the internets) that there may be some in progress
cebbertnotting: hey, we took Xen out of the kernel package
wwoodsbut that was linville speculating before F7 release
jwbwwoods, SFCL cleared it again
that's the last i heard
warrenDoes Atheros have a firmware as well?
We have to move-on or end.
jwbare we voting or waiting?
nirikwait until next week, and discuss on lists
bpepplejwb: I think we should wait, but that's just me.
warrenwait
jwbi think we should wait for a sign off from davej and cebbert
nirikthat too.
bpeppleDoes anyone want to start on a proposal for this?
dwmw2I'll do it
bpeppledwmw2: thanks.
drago01what about kqemu ... seems not to be heading upstream :(
bpeppleAnything else, or should we wrap it up for this week?
c4chriswrap++
dwmw2I may not make the meeting next week. I'll be on UTC+8
jwbdrago01, you'd have to ask davej or cebbert ;)
dwmw2but 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
drago01jwb: ok ... cebbert ?
f13dwmw2: yes I will.
bpepple-- MARK -- Meeting End
cebbertyeah, I'd like to see something in writing
bpeppleThanks, everyone.
jwbdrago01, 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!