Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-17/fedora-meeting.2009-07-17-17.01.log.html ---- 17:01:35 <jds2001> #startmeeting FESCo meeting - 2009-07-17 17:02:07 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:02:16 <jds2001> sorry, phone call 17:02:24 * j-rod here 17:02:25 * sharkcz is here 17:02:25 <jwb> here 17:02:26 <jds2001> full agenda :) 17:02:30 * Kevin_Kofler is here. 17:02:31 * nirik is present. 17:02:35 * notting is here 17:02:57 <jds2001> alright, without further ado 17:03:11 <jds2001> #topic Sponsor nomination - ianweller 17:03:18 <jds2001> .fesco 190 17:03:29 * jds2001 saw no objections on the list, but little feedback 17:03:40 <jds2001> +1 17:04:15 <notting> +1 17:04:15 <Kevin_Kofler> The request is not very high on specifics. 17:04:30 <jds2001> though the reviews are a little light, he's helped new packagers in numerous ways. 17:04:31 * skvidal is here but may not be in a moment 17:04:36 <Kevin_Kofler> But whatever, I saw no objections either, so +1 from me. 17:04:56 <sharkcz> +1 17:05:13 * j-rod has no strong feeling one way or the other 17:05:14 <nirik> +1 here. I think it's good he wants to help sponsor people at that POSEE thing perhaps? 17:05:31 <jds2001> yeah, that's pretty much the reason. 17:05:40 <jds2001> and teaching open source is a great thing. 17:05:45 <j-rod> +1 17:05:52 <jds2001> #agreed ianweller sponsor nomination is approved 17:06:06 <jds2001> #topic provenpackager request - jsteffan 17:06:18 <jds2001> .fesco 189 17:06:59 <nirik> I think it's important that packages with non responsive maintainers get responsive ones... 17:07:06 <jds2001> yeah, me too. 17:07:17 <nirik> that said, it's sometimes also good to fix them when they are broken in a more timely manner. 17:07:24 <Kevin_Kofler> As long as somebody fixes them, who cares whether they're officially the maintainers? 17:07:47 <jds2001> well, they dont directly get bug reports, for one. 17:07:49 <nirik> Kevin_Kofler: because then bugs go unanswered, no one is watching upstream for updates or fixes, or in general being a maintainer. 17:07:49 <jwb> urgh. phone. need to drop off for a minute 17:08:25 <nirik> drive by fixes are great if the problem needs fixing, but long term we need maintainers, not a bunch of people driving around tweaking things as they notice them. at least IMHO. 17:08:33 <nirik> in any case +1 to this request for me. 17:08:50 <Kevin_Kofler> +1 to the request from me as well. 17:08:54 <j-rod> +1 17:09:00 <jds2001> +1 here too, but get responsive maintainers :) 17:09:11 <jds2001> request comaintainership if you have to. 17:09:16 * nirik was just trying to note that lots of provenpackager requests seem to say 'I want to fix unresponsive packages' which is fine, but we should urge people to get them responsive maintainers also. 17:09:31 <jds2001> yeah, they need good TLC :) 17:09:35 <Kevin_Kofler> jds2001: The problem is that the nonresponsive or lazy maintainers usually don't react to ACL requests either. 17:09:46 <notting> +1 17:09:49 <sharkcz> +1 17:10:05 <jds2001> #agreed jsteffan provenpackager request is approved 17:10:14 <nirik> Kevin_Kofler: yeah. Need to run the non responsive process, but it's sometimes a lot of hassle. ;( 17:10:21 <jds2001> #topic provenpackager request - oget 17:10:29 <j-rod> +1 17:10:33 <sharkcz> +1 17:10:34 <jds2001> +1 17:10:43 <notting> +1 17:10:48 <nirik> +1 17:10:49 <Kevin_Kofler> +1 17:10:57 <jds2001> #agreed oget provenpackager request is approved. 17:11:38 <jds2001> #topic volume_key bundled cryptsetup 17:11:58 <jds2001> so we know a little more than last week 17:12:14 <nirik> I think with the additional info and the fact that this is going to be temp and upstream knows whats going on, I'd be ok with approving it. 17:12:26 <jds2001> do I take the comments in the ticket to mean the API won't change? 17:12:30 <jds2001> do we know if the new upstream release will be in time for F12? 17:12:42 <notting> ticket #? 17:12:50 <jds2001> oops 17:12:51 <Kevin_Kofler> https://fedorahosted.org/fesco/ticket/175 17:12:55 <jds2001> .fesco 175 17:13:41 <notting> so, it implies the api/abi of the 'upstream' version might change 17:14:02 <nirik> but volume_key will be the only user (internal) of the api from now. 17:14:04 <notting> but no ETA 17:14:17 <abadger1999> Eh... knowing that mitr and mbroz are working from the same office and that cryptsetup can update in mid-Fedora release despite having API/ABI changes makes the bundling a bit more acceptable. 17:14:34 * nirik nods. 17:14:37 <Kevin_Kofler> I believe it will be fairly easy to fix volume_key to use the final API if it has to change (and it might not even have to change). 17:14:40 * sharkcz also nods 17:15:21 <jds2001> +1 here 17:15:32 * jds2001 wants to see it gone by f13, though. 17:15:35 <sharkcz> +1 17:15:39 <abadger1999> I don't like mitr's original reasoning but these later reasons are better. I think we need to track these libraries better but I'll talk to spot about what we could setup. 17:15:39 <notting> +1 17:15:40 <jds2001> which i dont think is a problem 17:15:42 <nirik> yeah, so a reluctant +1 here... but perhaps we should file a followup ticket to make sure it's gone? 17:15:53 <Kevin_Kofler> +1 from me too (as already said last week). 17:16:02 <jds2001> nirik: we can just leave this one open 17:16:04 <j-rod> reluctant +1 here too 17:16:09 <f13> jds2001: I'm not doing it. 17:16:14 <abadger1999> For now, we need to make sure there's an open bug against volume_key that is blocking the bundled libraries tracker 17:16:20 <jds2001> f13: :D 17:16:38 <jds2001> f13: I think you need to change your nick now :) 17:16:44 <nirik> abadger1999: can you file that? or I guess it needs to have cvs done on the new package first? 17:17:00 <jds2001> nirik: what's the problem with leaving this ticket open? 17:17:01 <abadger1999> nirik: Right. First the package has to be approved and added to bz. 17:17:16 <jds2001> oh, you mean a bz :) 17:17:19 <nirik> jds2001: thats ok, as long as we don't forget it's there. 17:17:47 <jds2001> yeah, i take a look at all of em every week to see if any are relevant 17:18:01 <jds2001> anyhow 17:18:21 <jds2001> #agreed volume_key can temporarily bundle a newer cryptsetup 17:18:49 <jds2001> #topic drop F12 features not updated 17:19:09 <Kevin_Kofler> The list given in the ticket is not up to date. 17:19:14 <jds2001> debuginfofs i suspect was -ENOTIME 17:19:17 <Kevin_Kofler> XZRpmPayloads and F12X86Support got updated today. 17:19:26 <jds2001> Kevin_Kofler: im well aware of that. 17:19:38 <nirik> can we do them one at a time please? 17:19:42 <jds2001> yes 17:19:49 * dgilmore is here 17:20:05 <Kevin_Kofler> And we have some feedback from the owner of SystemtapStaticProbes, he's requesting a small subset of the feature to be approved instead and he's moving the main feature to Fedora 13. 17:20:05 <jds2001> so like i just said, debuginfofs i think was -ENOTIME with the autoqa stuff 17:20:14 <j-rod> yes, debuginfofs is -ENOTIME 17:20:15 <jds2001> wwoods is only one person. 17:20:26 <j-rod> Kevin_Kofler: one at a time 17:20:45 <Kevin_Kofler> So we're at debuginfofs now? 17:20:45 <jds2001> Multiseat 17:20:51 <nirik> ok, so move debuginfofs to next release? 17:20:55 <jds2001> we're done with that, dropped. 17:21:32 <jds2001> multiseat next 17:21:41 <notting> although we may want to see what's left with debuginfofs - if it's at 85%, maybe it can be helped even in a non-Feature status 17:21:41 <Kevin_Kofler> Are we sure debuginfofs won't be ready by F12? It's supposedly already 85% done. 17:21:49 <jds2001> ctyler not around? 17:22:04 <Kevin_Kofler> I think the important question to ask is whether the feature can be done by F12 or not. 17:22:20 <Kevin_Kofler> It doesn't make sense to drop a feature as a "Feature" when it actually lands anyway. 17:22:28 <jds2001> done by F12 == done in the next two weeks. 17:22:48 <jds2001> actually less 17:22:52 <dgilmore> Kevin_Kofler: if it partially lands it may not be worth advertising 17:22:56 <j-rod> jlaska: ping ^^^ 17:23:08 <j-rod> (and/or wwoods) 17:23:08 <Kevin_Kofler> jds2001: Except for freeze exemptions, slips etc. 17:23:45 <j-rod> I already know jlaska has said elsewhere that there just aren't resources to finish debuginfofs soon enough 17:23:57 <jds2001> Kevin_Kofler: we have never slipped feature freeze to my knowledge. 17:23:57 <jlaska> j-rod: yeah, it's not currently a focus on the QA radar 17:24:36 <Kevin_Kofler> jds2001: But there are exemptions, and the more the release slips, the more exemptions get requested and granted. 17:24:43 <j-rod> jlaska: so we good with punt-to-fedora-13 on this Feature? 17:24:48 <jds2001> very very few for features 17:25:09 <j-rod> and maybe it gets done by the time F12 is out, and can be used in F12, but we won't market it 'til F13 17:25:19 <Kevin_Kofler> jds2001: That's kinda the problem, the stuff goes in anyway, it just doesn't get listed as a feature. 17:25:21 <jds2001> yeah, that's fine. 17:25:39 <notting> <wwoods> long story short: I'm not proposing debuginfofs for F12, drop it from the list 17:25:39 <notting> the PoC implementation is 85% complete but it's 85% of The Wrong Way To Do It 17:26:01 <jlaska> j-rod: yeah ... and notting confirmed w/ wwoods 17:26:02 <pjones> 100% of the wrong way is better than 0% of nothing. 17:26:14 <dgilmore> Kevin_Kofler: it can be listed as a feature in the next release when its feature complete 17:26:16 <wwoods> I also don't have time to finish it 17:26:26 <wwoods> working on autoqa / israwhidebroken / etc. 17:26:30 <pjones> and I don't agree that it's entirely the wrong way -- it's organized enough that chunks can be swapped out for The Right Way piecemeal. 17:26:35 <nirik> ok, so punt that and next feature? (since we have about a zillion can we move on) 17:26:35 <jds2001> anyhow, we have much to get to, let's not beat a dead horse. 17:26:40 <pjones> (but yes, "I don't have time" is fair.) 17:26:45 <Kevin_Kofler> OK, based on the feedback from wwoods and jlaska, I'd say we just punt the debuginfofs feature to F13. 17:26:51 <wwoods> pjones: let's talk about it outside this meeting 17:26:54 <pjones> wwoods: fair. 17:26:56 <jds2001> done 17:26:59 <jds2001> NEXT! 17:27:15 <jds2001> #agreed debuginfofs is deferred to F13 17:27:32 <jds2001> Multiseat. 17:27:35 <Kevin_Kofler> Multiseat looks like it's going pretty much nowhere, unfortunately. 17:27:47 * dgilmore thinks punt multiseat 17:27:52 <jds2001> me too. 17:27:53 * nirik nods. 17:27:56 <j-rod> yup 17:27:58 <Kevin_Kofler> +1, punt. 17:28:00 <nirik> Best of luck for next release. 17:28:00 <sharkcz> +1 17:28:06 <jds2001> i just pinged ctyler, just in case he's got something to add 17:28:13 <Kevin_Kofler> Last updated more than 5 months ago, 10%, looks pretty dead. 17:28:26 <j-rod> Xi2 just getting merged should make it easier next go 'round 17:28:36 <j-rod> or so I'd think 17:28:39 <jds2001> #agreed multiseat feature is deferred to F13 17:28:56 <jds2001> Systemtap Static probes 17:29:01 <jds2001> owner wants this deferred 17:29:14 <jds2001> another feature page will be needed for the other parrt 17:29:25 <j-rod> ain't gonna force 'em 17:29:29 <Kevin_Kofler> It's already there: https://fedoraproject.org/wiki/Features/SystemtapTracingRefresh 17:29:30 <j-rod> defer it, next 17:29:41 <Kevin_Kofler> But we don't have it on the meeting agenda so far. 17:29:46 <jds2001> ok, not in my queue at the moment, probably will be next week. 17:30:03 <nirik> it's still pending wrangling. 17:30:10 <jds2001> not in the right state to be on my radar. 17:30:15 <Kevin_Kofler> OK. 17:30:23 <Kevin_Kofler> We'll have that one next week, hopefully. 17:30:34 <jds2001> #agreed systemtap static probes feature is deferred to F13 17:30:53 <jds2001> XZ RPM payloads 17:31:03 <Kevin_Kofler> Got updated today, keep. 17:31:09 <jds2001> there's been some movement on this. 17:31:13 <j-rod> yep 17:31:14 * nirik nods. The review shoudl be pretty close to done. 17:31:20 <jds2001> ok, great 17:31:43 <jds2001> #agreed XZ RPM payloads remains an F12 feature 17:31:51 <jds2001> and finally, the F12X86 support 17:31:52 <notting> jds2001: with this and the next, there's still a large 'mass rebuild' elephant in the room 17:31:59 <jds2001> we're running out of them for the rebuild. 17:32:01 <j-rod> was blocking on xz, keep 17:32:06 <jds2001> er, time. 17:32:15 <Kevin_Kofler> That one also got updated today, keep +1. 17:32:41 <notting> i think i'm going to do the x86 support bits today, it can start before the mass rebuild and be done piecemeal until we get one 17:32:54 <jds2001> ok, cool 17:33:10 <jds2001> #agreed F12 x86 support remains a feature 17:33:11 <jds2001> NEXT 17:33:29 <dgilmore> notting: what changes are we doing? 17:33:30 <jds2001> #topic yum langpack plugin 17:33:42 <dgilmore> notting: ill take it offline with you 17:33:42 <jds2001> #topic F12 X86 support changes 17:33:44 <notting> dgilmore: see scope on the feature page, can discuss outside of meeting? 17:33:46 <jds2001> ok 17:34:04 <jds2001> #topic yum langpack plugin 17:34:09 <jds2001> alrighty 17:34:17 <jds2001> .fesci 186 17:34:21 <jds2001> .fesco 186 17:34:29 <notting> no update, defer again? 17:34:38 <jds2001> worksforme 17:34:46 * notting realizes he's probably part of the update-providing team that fell down on this 17:35:05 <jds2001> #agreed deferred until updates received 17:35:19 <jds2001> #topic Feature - FedoraStudio 17:35:23 <jds2001> .fesco 191 17:35:54 <jds2001> i just conglomerated this filed proposal into the feature. 17:36:33 <jds2001> +1 to the feature 17:36:39 <notting> Multimedia / Sound & Video -> Creation -> Jack ?? 17:36:54 <notting> +1 to having a *-menus package. i don't think this needs to be in the default menu/spin 17:36:55 <jds2001> I think the question was whether to integrate this into redhat-menus or have a separate package 17:37:06 <Kevin_Kofler> This one is always tough: one big "Multimedia" or "Sound & Video" menu is crazy, but tons of levels can quickly be annoying too. 17:37:36 <Kevin_Kofler> notting: But should the optional menu be required by some packages or not? 17:37:42 * dgilmore thinks it might be confusing to some 17:37:58 <Kevin_Kofler> In other words, should users be allowed/forced to choose between one big menu or many subcategories or should the apps request their subcategories? 17:38:21 <Kevin_Kofler> I also think that those subcategories are probably too many. 17:38:33 <nirik> next? 17:38:38 <notting> Kevin_Kofler: ... maybe? but i think either the desktop or kde installs, by default, don't install so many things that it would be needed. looking at the menus now, the sound&video is shorter than other ones 17:38:48 <notting> nirik: well, it hasn't gotten enough votes one way or another yet :) 17:38:53 <Kevin_Kofler> notting: Indeed. 17:39:03 <Kevin_Kofler> So having those subcategories by default would just be annoying. 17:39:07 <jds2001> notting: it's sort of like the games menu 17:39:11 <nirik> sorry, my connection died... I was nexting something a while back. 17:39:27 <sharkcz> or the Electronics Lab one 17:39:29 * jds2001 is in favor of it being a separate package, just like the games menus are today 17:39:49 <Kevin_Kofler> The FEL menu is just a single Electronics menu. 17:39:56 <Kevin_Kofler> Not a whole hierarchy. 17:40:04 <notting> jds2001: right. i don't object to the package, i just don't think it's needed by default out-of-the-box 17:40:10 <jds2001> notting: +1 17:40:11 <notting> it's the sort of thing for a special spin (are they doing one?) 17:40:41 <Kevin_Kofler> The electronics-menu package is required by several electronics packages, which is why I brought that issue up. 17:41:00 <jds2001> yeah, I wouldn't require it. 17:41:06 <Kevin_Kofler> It makes sense for that menu, but for this one? 17:41:30 <jds2001> no, it already has someplace to go. 17:41:47 <jds2001> the electronics one is a new top-level menu, correct? 17:41:51 <dgilmore> notting: i could go with that 17:41:52 <Kevin_Kofler> Correct. 17:42:16 <jds2001> yeah, we can already put stuff in the sound & video menu 17:42:34 <Kevin_Kofler> So we're approving this feature as long as it's implemented in an optional package which is not required by any other package? 17:42:48 <jds2001> sure. 17:43:04 <Kevin_Kofler> Let's vote for that proposal? 17:43:07 <jds2001> +1 17:43:09 <Kevin_Kofler> +1 from me, obviously. 17:43:10 <notting> +1 17:43:12 <nirik> +1 to that... 17:43:13 <sharkcz> +1 17:43:14 <dgilmore> +1 17:43:41 <jds2001> #agreed FedoraStudio menus are approved, as long as the package is optional and required by no other package. 17:43:58 <jds2001> #topic anaconda mdraid 17:44:01 <jds2001> .fesco 193 17:44:17 <jds2001> +1, seems good. 17:44:27 <notting> well it's not like it didn't support mdraid before ;) 17:44:32 <notting> but +1 to mdraid for imsm 17:44:34 <nirik> +1 except the fixme stuff needs fixed. ;) 17:44:44 <sharkcz> +1 17:44:50 <Kevin_Kofler> +1 17:44:50 <notting> in the short term, copy relnotes to docs 17:44:52 <jds2001> no, this is some dmraid stuff becoming mdraid :) 17:45:04 <nirik> (anything making less fakeraid is good) 17:45:07 <j-rod> +1 17:45:15 <jds2001> indeed, fakeraid sucks 17:45:23 <Kevin_Kofler> nirik: Well, it's still as fake as before. 17:45:29 <notting> it's still the same raid. just a different assembling tool 17:45:32 <Kevin_Kofler> Just implemented differently in software. 17:45:37 <jds2001> #agreed Anaconda mdraid feature is approved. 17:45:41 <nirik> yeah, I suppose. 17:45:45 <jds2001> oh, well then it still sucks :) 17:46:11 <jds2001> i would approve a feature for anaconda to throw up a dialog "go buy some real hardware" :D 17:46:16 <jds2001> anyhow, i digress 17:46:28 <jds2001> #topic ABRT F12 17:46:33 <jds2001> .fesco 194 17:47:19 <Kevin_Kofler> +1 17:47:22 <notting> +1 17:47:25 <sharkcz> +1 17:47:28 <nirik> +1 17:47:30 <jds2001> +1 17:47:41 <jds2001> #agreed ABRT F12 feature is accepted 17:47:56 <jds2001> #topic Gnome 2.28 17:48:01 <jds2001> .fesco 195 17:48:05 <notting> +1 17:48:08 * jds2001 is concerned about the timing 17:48:09 <jds2001> but +1 17:48:13 <sharkcz> +1 17:48:22 <Kevin_Kofler> Isn't it somehow redundant to list both the new GNOME and individual GNOME features as features? 17:48:51 <nirik> is this going to land in time? 17:49:02 <Kevin_Kofler> jds2001: I'm fairly sure GNOME 2.28 won't be out later than September - Early October due to that distribution with a 'U'. 17:49:07 <nirik> +1 if so... but from the schedule it's not clear to me that it will. 17:49:35 <dgilmore> Sep 23 GNOME 2.28.0 stable release 17:49:36 <nirik> sep 23rd it looks like on their schedule currently. 17:49:52 <jds2001> yeah, and sep 22 freeze 17:50:00 <jds2001> does not compute 17:50:12 <Kevin_Kofler> I think they can pull this off. 17:50:13 <dgilmore> Sep 21 GNOME 2.28.0 stable tarballs due 17:50:28 <nirik> yeah, they often get them hot off the presses... 17:50:32 <j-rod> +1 17:50:32 <nirik> it's very tight tho. ;( 17:50:33 <Kevin_Kofler> If it's just 2-3 days late, an exemption is certainly possible. 17:50:37 <Kevin_Kofler> It has been done for KDE too. 17:50:43 <dgilmore> assuming that they can get the tarballs soon after there done they could pull it off 17:50:45 <Kevin_Kofler> And also for GNOME in the past. 17:50:56 <nirik> yeah, but thats assuming no slips in their schedule... 17:50:59 <dgilmore> i think +1 17:51:09 <nirik> anyhow, we can deal with it when/if it happens.... +1 here. 17:51:09 <notting> emapthy i suppose is special because it's a switch of a distro default that wasn't part of the official gnome stack before 17:51:11 <Kevin_Kofler> nirik: There's that big distro with a 'U' which is releasing in October. 17:51:15 <Kevin_Kofler> They can't afford any slips. 17:51:19 <j-rod> if we have rc12 instead of the release version, so be it 17:51:20 <dgilmore> but any slips then we would need to evaluate things 17:51:26 <notting> Kevin_Kofler: opensUse? 17:51:31 <Kevin_Kofler> notting: LOL 17:51:33 <Kevin_Kofler> +1 to GNOME 2.28 from me. 17:51:35 <notting> linpUs? 17:52:02 <jds2001> #agreed GNOME 2.28 feature is accpeted 17:52:12 <jds2001> #topic KVM NIC hotplug 17:52:17 <dgilmore> notting: i thought empathy was default upstream 17:52:20 <jds2001> .fesco 196 17:52:22 <dgilmore> we dirverged from it 17:52:27 <jds2001> dgilmore: it is 17:52:31 * notting suspects upstream gnome and kde are historically better at keeping their schedules than we are :/ 17:52:32 <jds2001> dgilmore: has been for awhile 17:52:41 <dgilmore> +1 for KVM_NIC_Hotplug 17:52:47 <nirik> +1 17:52:50 <jds2001> +1 17:52:57 <Kevin_Kofler> +1 17:53:01 <sharkcz> +1 17:53:02 <j-rod> +1 17:53:12 <notting> +1. although there are a couple of refs to F11 in the page that could be fixed 17:53:20 <jds2001> #agreed KVM NIC hotplug feature is approved. 17:53:31 <jds2001> #topic noarch subpackages 17:53:37 <jds2001> .fesco 197 17:53:44 <Kevin_Kofler> As I wrote in the ticket: I don't see how this is a Fedora 12 feature. This is available already now and has been before F11 got released, and some packages in F10 updates and F11 are already noarch subpackages. 17:53:47 * jds2001 is unsure this is a feature 17:54:05 <jds2001> this is more an FPC proposal than a feature 17:54:36 <nirik> well, I think they want to tout it, but not sure most people will care. ;) 17:54:39 <notting> -1; the technical bits were in prior releases, and the per-package bits should be packager discretion 17:55:15 <Kevin_Kofler> -1 too, same as notting, plus if anything is to be done for the per-package bits, that's something for FPC. 17:55:19 <jds2001> nirik: if i read it correctly, there were changes to guidelines to require noarch subpackages in here. 17:55:28 <dgilmore> -1 not a feature this time 17:55:35 <jds2001> -1 17:55:35 <sharkcz> -1 17:55:53 <Kevin_Kofler> Guideline changes need to go through FPC, not FESCo (unless you're trying to appeal FPC's decision). 17:55:55 <nirik> yeah, -1... but might suggest going to FPC to add a suggestion on it. 17:56:17 <jds2001> #agreed noarch subpackages feature is rejected, the technical bits were in previous releases, and the per-package bits are an FPC matter. 17:56:35 <jds2001> #topic rebootless installer 17:56:43 <jds2001> .fesco 198 17:56:48 <dmc414> feature owner here: note, inclusion in spins is desired, not mandatory (user can install from network) 17:57:11 <nirik> dmc414: is your package under review yet? or not yet? 17:57:18 <dmc414> notyet 17:57:34 <Kevin_Kofler> dmc414: But you're advertising it as included in the spins. 17:57:34 * jds2001 is also wondering why this couldn't be integrated into anaconda 17:57:43 <notting> -1 to having multiple installers on the live cds 17:57:48 <dmc414> Kevin_Kofler: ? 17:58:06 <Kevin_Kofler> "An experimental new rebootless installer has been included with the LiveCD/USB." 17:58:16 <dmc414> I can change the feature page to reflect that, if needed to get acceptance 17:58:45 <jds2001> dmc414: did you try to work with the anaconda guys to get this feature integrated into anaconda? 17:58:48 <dmc414> jds2001: time would be the reason for no anaconda integ for f12 17:59:02 <dmc414> jds2001: anaconda people have known about this for years, no interest 17:59:31 <Kevin_Kofler> I can try to get some feedback on this from Sebastian Vahl (the KDE Live CD maintainer) if wanted. 17:59:52 <dmc414> can I get it approved as network-only, then revise to in-spin if buyin? 18:00:03 <nirik> also, do we have feedback from desktop folks? 18:00:21 <dgilmore> dmc414: i think id rather see it integrated into anaconda 18:00:38 <dmc414> there is a unionfs issue that may preclude it from f13, see the dependenies 18:00:53 <notting> my concern is that touting a feature of an installer that would require the user respin their own livecd first (if it's just in-repo) is likely to confuseusers 18:00:59 <ajax> i'm only kind of authoritative for desktop, but: seriously, no. 18:01:00 <dmc414> dgilmore: no time for anaconda integration for f12 18:01:15 <dmc414> notting: no, you just need to yum install the package 18:01:27 <nirik> (if you have network) 18:01:50 <dmc414> ajax: ? 18:01:53 <dgilmore> dmc414: then id advocate waiting till it can be done right 18:02:02 <ajax> we already have too much skew between what gets installed between live image and dvd media. more seems like a really bad idea. 18:02:26 <dmc414> I'm not going to advocate any further, I think you are passing up something really cool 18:02:51 <jds2001> dmc414: you can defintely get the package reviewed and have it available. 18:03:04 <jds2001> Not being a feature doesn't mean we're outright rejecting the idea. 18:03:14 <nirik> I would also like to see it in anaconda. Failing that I would like to see it in as a package and tested and such. 18:03:54 <dmc414> nirik: anaconda people have had the opportunity to show interest for 2 years 18:04:17 <nirik> dmc414: did you provide a patch? was there a bug for this? 18:04:20 <dmc414> I'd like to run with this on my own, for a purely experimental demonstration in f12 18:04:32 <Kevin_Kofler> I'm sorry, but I think the lack of interest from Anaconda people says something about the usefulness (or lack thereof) of the feature. 18:04:34 <dmc414> nirik: I don't need a patch, I have a complete implementation 18:04:44 <dmc414> Kevin_Kofler: or politics 18:04:46 <jds2001> dmc414: you're more than welcome to, like I said, I don't think that's a feature, though. 18:04:58 <dmc414> fair enough 18:05:51 <nirik> dmc414: I think it's cool... but having 2 installers seems like a bad idea... 2x the testing, having to ask everyone how they installed, more docs, more confusion. 18:06:05 <dmc414> nirik: marked as *experimental* 18:06:26 <jds2001> right, but surely it goes beyond experimental at some stage. 18:06:27 <nirik> but if the package is in and popular, perhaps you can get the anaconda folks interested in adding that functionality? espcially if it's popular and tests well? 18:06:31 <dgilmore> dmc414: its still confusing to people 18:06:43 <dmc414> the main benefit of inclusion in f12, is to guage feedback, to possibly prevent a unionfs liveos architecture that precludes it from f13+ 18:07:03 <nirik> dmc414: can you expand on the unionfs issue? 18:07:21 <f13> From releng side, I'd prefer that the package got in, but not listed as a feature. We aren't ready to promote this as a supported install method 18:07:23 <dmc414> nirik: I don't think this is the place for that discussion 18:07:43 <notting> nirik: it works by using device-mapper to pull in current changes. unionfs would break that 18:07:45 <notting> (short answer) 18:08:10 <Kevin_Kofler> In other words, the design is not future proof and may become obsolete as soon as the next release of Fedora. 18:08:14 <dgilmore> f13: agreed. i see no issue with having it in the repos 18:08:23 <dgilmore> though id prefer anaconda integration 18:08:34 <nirik> ok, but I don't think thats very nice... trying to get in a feature to prevent a change that might otherwise be good from a technical standpoint. 18:08:42 <dmc414> dgilmore: as said, anaconda integration is the f12+ plan, if people like it 18:08:44 <dgilmore> and would prefer to wait to tout it as a feature until its in anaconda 18:08:46 <Kevin_Kofler> nirik: Right. 18:09:17 <dmc414> nirik: it's only 'trying' if people like it so much that it outweighs the tradeoffs of that other decision 18:09:21 <nirik> -1 to feature now, but I would encourage dmc414 to add the package and get feedback and try and get anaconda folks interested in adding the feature down the road. 18:09:29 <Kevin_Kofler> unionfs for live CDs could provide better support for persistence. 18:09:52 <notting> and make the readonly root support in rc.sysinit actually sane 18:09:52 <Kevin_Kofler> I think that's much more valuable than saving a single reboot at installation time (which is probably something you do exactly once, as you can't upgrade from a live CD). 18:09:55 <dmc414> Kevin_Kofler: true, but thats more argument to include it in f12 to see if there are counter-tradeoffs against unionfs 18:09:59 <jds2001> -1 to the feature, +1 to the package (but that doens't need FESCo approval) 18:10:56 <dgilmore> jds2001: agreed -1 as a feature, but do get the package in 18:11:30 * notting agrees with jds2001 18:11:44 * sharkcz laos agrees with jds2001 18:11:57 <dmc414> I think its cool enough that with the experimental tag, it would generate good press 18:12:06 <dmc414> but I'm biased :) 18:12:17 <dmc414> your loss... 18:12:25 <Kevin_Kofler> We don't want an experimental feature to generate press. 18:12:31 <dmc414> ext4 in f9? 18:12:35 <jds2001> #agreed Rebootless installer is rejected as a feature, however, the package is encouraged to go in the repos 18:12:39 <Kevin_Kofler> The more press it generates, the more people will want to use it and complain if it doesn't work. 18:12:55 <jds2001> anyhow, we have much to get to. 18:12:57 <Kevin_Kofler> For the record, -1 to the feature from me too. 18:13:04 <jds2001> #topic SR-IOV 18:13:10 <jds2001> .fesco 199 18:13:51 <nirik> only one controller supported? 18:14:00 <jds2001> seems that way 18:14:33 <Kevin_Kofler> Looks like most hardware doesn't support this at all. 18:15:02 <Kevin_Kofler> And the driver side is implemented only for that one. 18:15:17 <Kevin_Kofler> But I don't know how much hardware could support it given an appropriate driver. 18:15:54 <jds2001> /msg zodbot fasinfo chrisw 18:15:58 <jds2001> bah 18:16:15 <notting> cdub, usually. don't see him. 18:16:22 <Kevin_Kofler> I think the big question here is whether this is worth advertising as a Fedora feature. 18:16:23 <nirik> it seems odd to tout this as a feature with only one device supported. 18:16:27 <notting> but... meh, +1 18:16:29 <jds2001> me too. 18:16:44 <nirik> (although those cards are pretty common) 18:16:53 <Kevin_Kofler> It's definitely good to have this kernel feature, but there are more important features which don't have feature pages. 18:16:58 <j-rod> and will only get more common 18:17:04 <j-rod> and more hardware will start to support this 18:17:06 <j-rod> +0 18:17:07 <rwmjones> I just pinged cdub and he's going to turn up in a mo 18:17:11 <j-rod> +1, I mean 18:17:14 <sharkcz> +1 18:17:18 <jds2001> rwmjones: cool 18:18:19 * dgilmore wonders what this gives us over virtual nics etc 18:18:35 <nirik> yeah. increased performance? 18:18:35 <jds2001> dgilmore: presumably talking directly to the PCI device 18:19:02 <rwmjones> ask cdub :-) 18:19:05 <Kevin_Kofler> Is SR-IOV something inherently specific to Ethernet controllers or could it also be used in other hardware? 18:19:15 <dgilmore> jds2001: but you have multiple vms accessing it so there is some control overhead 18:19:30 <cdub> it's not sepcific to Ethernet controllers 18:19:39 <jds2001> dgilmore: one per VF, iiuc 18:19:44 <rwmjones> cdub, there was also a question earlier about the amount of hardware which supports this ... only one piece of hardware is mentioned on the feat page 18:19:52 <cdub> Kevin_Kofler: it's also not available in any hardware other than NICs right now 18:19:56 * jds2001 not a kernel guy, so im not sure 18:19:57 <dgilmore> cdub: what does it mean to us? the feature really doesnt let me knwo whats so great about it 18:20:16 <cdub> rwmjones: there are now two devices 18:20:50 <cdub> dgilmore: it means one can allocate resources from a PCI device to assign to a Virtual Machine 18:20:52 <jds2001> ok, does this take advantage of multiple hardware queues on the card, and basically allocate a queue per VM? 18:21:05 <jds2001> or am i misunderstanding entirely? 18:21:06 <cdub> jds2001: essentially, yes 18:21:11 <dgilmore> cdub: and? that doesnt seem like a big deal to me 18:21:35 <j-rod> virtualized nics have a performance penalty to them 18:21:39 <cdub> dgilmore: right now, if you want to assign a PCI device to a VM (typically for performance reasons) 18:21:40 <j-rod> direct access to the hardware is better 18:21:53 <cdub> dgilmore: you have to have X number of physical devices in the box 18:22:16 <cdub> dgilmore: w/ SR-IOV, you need only 1 physical device which is capable for multiple virtual devices 18:22:31 <cdub> dgilmore: so you can get bare metal I/O performance in a VM 18:22:50 <dgilmore> cdub: and the overhead is less than vitualising the devices for each host? 18:23:03 <cdub> dgilmore: yes, it is 18:23:27 <j-rod> perhaps adding something to the feature page about why its a big win would help educate folks why this is a Good Thing 18:23:28 <cdub> dgilmore: the device is driven directly by the guest OS 18:23:35 <dgilmore> cdub: so this needs hardware support, which right now is mostly lacking in the wide world 18:23:52 <j-rod> network perf numbers for virt nic vs. sr-iov nic 18:23:56 <dgilmore> j-rod: indeed because it doesnt really explain much 18:24:22 <cdub> dgilmore: yes, there are few devices that support this mode (2 to be exact) 18:24:50 <notting> cdub: is it ever going to grow beyond intel gigabit/10gb device <foo>? 18:24:53 * j-rod already knew what it was, but yeah, looking at the feature page again, could stand to explain a bit more for the average reader 18:24:57 <dgilmore> cdub: which makes me wonder if we should do a big job of touting it 18:25:00 <cdub> j-rod: yes, i can add that to the feature page 18:25:05 * nirik is +1 , but the page could be pimped up and such. 18:25:07 <cdub> notting: yes 18:25:23 <cdub> dgilmore: it's a huge buzz in the virt world 18:25:30 * dgilmore thinsg the feature page is lacking and needs more detail 18:25:40 <cdub> dgilmore: for the rest of the normal world...not a big deal ;-) 18:25:51 * jds2001 steps away for a minute, but +1 18:25:58 <cdub> it's my fault for not adding better details to the page 18:26:03 <j-rod> +1 here, definitely 18:26:34 <notting> that's jds, j-rod, nirik, notting, sharkcz 18:26:39 <dgilmore> im 0 for now. i think it could be intresting but its something that we are going to need more info to educate people 18:26:51 <notting> #approved SR-IOV is approved as a feature. Please clarify the feature page with more details. 18:27:11 <Kevin_Kofler> 0 from me too, I really don't care either way. 18:27:30 <cdub> i will update the page w/ better details 18:27:53 <Kevin_Kofler> I'm noticing that the virt folks are currently the most effective at touting their features. 18:28:03 <Kevin_Kofler> A lot of the listed Fedora features are virtualization-related. 18:28:19 <cdub> specifically, which cards support SR-IOV, and clearer description of benefits 18:28:33 <jds2001> #agreed SR-IOV is approved as a feature. Please clarify the feature page with more details. 18:28:48 <jds2001> notting: wrong command :) 18:28:56 <notting> heh 18:29:13 <jds2001> anyhow 18:29:26 <jds2001> #topic libguestfs 18:29:29 <jds2001> .fesco 200 18:29:43 <riel> Kevin_Kofler: that is probably because a lot of other features can be implemented upstream and just get inherited by Fedora, while virt needs distro integration 18:29:59 <nirik> +1 to libguestfs here. 18:30:02 <sharkcz> +1 18:30:04 <jds2001> +1 18:30:09 <Kevin_Kofler> +1 18:30:16 <j-rod> +1 18:30:26 <jds2001> #agreed libguestfs feature is accepted 18:30:33 <rwmjones> that was easy ... 18:30:34 <jds2001> #topic KVM Stable guest ABI 18:30:36 <jds2001> .fesco 202 18:30:36 <dgilmore> +1 could do with having more info 18:31:07 <jds2001> so this is basically so you dont have to reactivate windoze when you upgrade? 18:31:16 <Kevin_Kofler> A lot of work for the benefit of inferior operating systems not liking hardware changes. :-( 18:31:40 <jds2001> Kevin_Kofler: yeah, but lots of people use it :) 18:31:41 <rwmjones> it's also to prevent things like ethernet card renumbering 18:31:44 * nirik has never run into this with linux guests. 18:31:56 <nirik> so, it lists options there... which is going to be done? 18:32:04 <jds2001> option 2 18:32:05 <nirik> ah, #2 18:32:09 <jds2001> that's listed too :) 18:32:16 <dgilmore> -1 the feature page is way incomplete 18:32:22 <riel> the stable ABI may be necessary for live migration, too 18:32:36 <riel> otherwise you may not be able to live migrate a guest from Fedora 11 to Fedora 12, for example 18:32:47 <riel> (because the destination host emulates slightly different hardware) 18:33:07 <dgilmore> riel: right the feature page needs to ay what its going to do. not present options 18:33:24 <dgilmore> it looks like the feature is very immature and not ready to be considered 18:33:33 <nirik> yeah, I would say nuke or archive the options, present whats going to happen. 18:33:41 <dgilmore> i think it needs doing but its not close to ready yet 18:33:46 <rwmjones> it was in a kind of "upstream hell" for a long time (until recently) 18:33:59 <Kevin_Kofler> The patch got accepted upstream now. 18:34:06 <Kevin_Kofler> So it's not being done as a Fedora-specific hack. 18:34:32 <dgilmore> Kevin_Kofler: thats fine it doesnt excuse an immature feature page 18:34:32 <nirik> do you guys think this can land before feature freeze? 18:34:42 <Kevin_Kofler> The only thing one could possibly object to is the part where libvirt defaults to saving the ABI version. 18:35:51 <dgilmore> id like to see a way that guests can be upgraded to take advantage of new qemu abi features 18:35:52 * nirik suggests cleaning up the feature page and we can revisit it next week? 18:35:55 <jds2001> we're not saying the feature isobjectionable 18:36:03 <dgilmore> nirik: right 18:36:08 <jds2001> yeah, sounds good, we only have 25 minutes left 18:36:19 <rwmjones> dgilmore, that's a large, difficult problem 18:36:20 <Kevin_Kofler> dgilmore: Me too, but isn't that just a matter of changing the version in the virtualization GUI? 18:36:23 <dgilmore> because i dont run windows machines i dont care for the feature personally 18:36:40 <jds2001> dgilmore: as mentioned, there are other uses 18:36:47 <Kevin_Kofler> rwmjones: Huh? It's just a matter of bumping/removing the hardcoded version. 18:36:48 <dgilmore> rwmjones: it needs a solution, because for my uses this feature is a hinderance 18:37:48 <dgilmore> jds2001: sure. I just think this feature is very incomplete and needs to be revisited when its more definate 18:37:49 <rwmjones> windows guests are designed (because of "activation") to be hard to fix, they are designed to check if details of the hardware changes 18:37:53 <jds2001> anyhow, shall we defer to next week 18:38:23 <jds2001> #agreed this is deferred til next week, when the feature page is cleaned up more. 18:38:43 <jds2001> #topic KVM qcow2 performance 18:38:47 <jds2001> .fesco 203 18:39:40 <Kevin_Kofler> +1 18:39:56 <notting> -1! we should make performance worse! 18:39:59 <notting> oh wait. +1. 18:40:09 <sharkcz> +1 18:40:09 <nirik> +1 18:40:14 <Kevin_Kofler> notting: :-) 18:40:18 <jds2001> +1 18:40:36 <jds2001> #agreed KVM qcow2 performance feature is accepted 18:40:46 <dgilmore> +1 18:40:47 * jwb finally rejoins 18:40:50 <jds2001> #topic NFSv4 default 18:41:02 <jds2001> .fesco 204 18:41:15 <jds2001> +1, NFSv4 good. 18:41:24 <dgilmore> +1 18:41:28 <Kevin_Kofler> +1 18:41:28 <jds2001> (if one has to use NFS, which is bad :D) 18:41:43 <Kevin_Kofler> Can't stay with an ancient FS forever. 18:41:48 <sharkcz> +1 18:41:50 <Kevin_Kofler> v4 is at least merely old. ;-) 18:41:59 <j-rod> +1 18:42:00 <smooge> doesn't v4 need kerberos infrastrucutre? 18:42:06 <jds2001> smooge: nope 18:42:12 <nirik> +1 18:42:15 <notting> +1 18:42:16 <jwb> does it help the firewall issues? 18:42:21 <jds2001> jwb: yep 18:42:26 <jwb> well then +1 18:43:04 <jds2001> single tcp port :) 18:43:07 <jds2001> #agreed NFSv4 as default feature is accepted. 18:43:31 <jds2001> #topic NetBeans 6.7 18:43:38 <jds2001> .fesco 205 18:43:40 <Kevin_Kofler> Are we going to get a feature page for every single updated application now? 18:43:59 <jds2001> we've done netbeans before 18:44:12 <f13> Kevin_Kofler: if it requires a lot of coordination between package maintainers, yes. 18:44:23 <nirik> well, major ones where new features are added, or needs coordination. 18:44:24 <f13> and it's a significant change that users would care about 18:44:48 <jds2001> and had similar questions, iirc :) 18:44:48 <dgilmore> +1 18:44:48 <jds2001> +1 18:44:49 <notting> this one doesn't seem to require any coordination, though 18:44:54 <sharkcz> +1 18:45:04 <notting> it's updating two packages, and adding new dependencies of them 18:45:18 <notting> -1, it's just a rebase-to-upstream of a non-default IDE 18:45:26 <dgilmore> i think its helpful to advertise what developers/users can get from using fedora 18:45:55 <nirik> https://fedoraproject.org/wiki/Features/Policy/Definitions 18:46:19 <dgilmore> I think alot of developers might like it. we have done features for Eclipse upgrades in the past 18:46:39 <notting> hee. it adds support for sun's version of fedorahosted 18:47:35 <jds2001> anyhow, i see 3 +1's, one -1. Anyone else? 18:47:37 <Kevin_Kofler> Hmmm, OK, if this one is a feature, KDevelop 4 (most likely headed for Fedora 13) will be one too. 18:47:49 <jds2001> Kevin_Kofler: sure thing. 18:48:22 <dgilmore> hrrm 18:48:29 <dgilmore> http://www.netbeans.org/community/releases/67/relnotes.html has 18:48:33 <dgilmore> Ubuntu 9.04: 18:48:33 <dgilmore> Processor: 800MHz Intel Pentium III or equivalent 18:48:33 <dgilmore> Memory: 512 MB 18:48:34 <dgilmore> Disk space: 650 MB of free disk space 18:48:39 * jds2001 would like to dispense with this feature expeditiously :D 18:48:41 <dgilmore> as a minimum requirement 18:48:51 <jds2001> ok, that seems fine. 18:49:02 <Kevin_Kofler> +1 to the feature from me, I don't want to be the bad guy who blocks it. :-) 18:49:32 <dgilmore> i think that we should push the feature owners to get fedora included in the upstream os requirements list 18:49:37 <Kevin_Kofler> IDEs can be interesting to developers. 18:49:47 <Kevin_Kofler> dgilmore: It gives a minimum requirement, Fedora is better. :-p 18:49:51 <dgilmore> the only linux mentioned upstream is ubuntu :( 18:50:21 <sharkcz> and RHEL under "various other Linux distros" 18:50:26 <dgilmore> so without us touting it. people will look and think they need ubuntu to use it in linux 18:50:32 <jds2001> we cna push for that independently of the features. 18:50:58 <Kevin_Kofler> Yeah, that's an upstream issue, completely separate from the feature. 18:51:08 <dgilmore> sharkcz: i dont see that 18:51:18 <Kevin_Kofler> And actually, advertising NetBeans as a Fedora feature is the best way to fight that misconception. 18:51:57 <sharkcz> dgilmore: small letters below "big list of OSes" 18:51:57 <Kevin_Kofler> We have 4 +1 votes, we just need one more to be done with this. 18:52:16 <dgilmore> sharkcz: just found it 18:52:47 <j-rod> +1, sorry 18:52:52 <jds2001> #agreed NetBeans 6.7 feature is accepted 18:53:01 * j-rod distracted... 18:53:12 <jds2001> #topic Network Interface Management 18:53:16 <jds2001> .fesco 206 18:53:34 <Kevin_Kofler> +1 18:53:35 <jds2001> +1, looks awesome 18:53:44 <sharkcz> +1 18:53:58 * nirik nods. +1 here 18:54:07 <notting> +1. although i'm not sure why the configuration tool needs up/down commands 18:54:16 <jds2001> #agreed Network Interface Management feature is accepted 18:54:27 <lutter> didn't join a second too soon :) 18:54:29 <jds2001> #topic pk browser plugin 18:54:35 <dgilmore> +1 though id like to see NM and system-config-network support 18:54:46 <jds2001> lutter: :) 18:55:24 <dgilmore> lutter: is there plans to get this integrated with the resgular management tools? 18:55:43 <dgilmore> lutter: because NM blows chunks on bachines with bridges right now 18:55:56 <nirik> it does not... it just doesn't support them. ;) 18:55:59 <lutter> dgilmore: yes, definitely with NM .. we had a more ambitious feature written up efore, but I wrote this one up because it reflects what can be working in F12 18:56:17 <lutter> dgilmore: I know .. 18:56:25 <j-rod> +1 18:56:27 * notting suspects that NM might end up obsoleting s-c-n (from a writing-of-configs standpoint) before s-c-n gets ported to a new lib 18:56:27 <dgilmore> lutter: ok. i know people who want to use bridges with NM controlled boxes 18:56:46 <dgilmore> notting: :) thats ok 18:57:02 <lutter> dgilmore: yes, very common .. people who use their laptops for running VM's 18:57:25 <dgilmore> lutter: right. is there any chance to get this support for F-12? 18:57:27 <notting> +1 to pk-browser-plugin. although it leaves out the missing scope of "get the internet to put the metadata on their web page" 18:57:41 * nirik looks for the url here. 18:57:52 <lutter> dgilmore: from talking to dcbw, no .. he says he's busy with lots of higher-priority things in NM 18:58:33 <jds2001> +1 to pk-browser-plugin 18:58:37 <dgilmore> lutter: :( 18:58:39 <Kevin_Kofler> In what browsers has the browser plugin been tested yet? There are no details. 18:58:51 <jds2001> apparently epiphany and firefox. 18:58:53 <Kevin_Kofler> The README just says that there are some GTK+ calls in there. 18:59:10 <Kevin_Kofler> So I'm worried about what happens in Konqueror, Arora etc. 18:59:23 * nirik nods. I was wondering about that too. 18:59:34 <jds2001> worst case, the same thing that happens today, right? 18:59:38 <Kevin_Kofler> It also requires the GLib event loop, but that one's enabled by default in our Qt builds. 18:59:45 <drago01> there are a lot iof plugins that use gtk .. how do they behave theire? 18:59:54 <Kevin_Kofler> Worst case, the browser crashes and you have to disable or delete the plugin. 19:00:09 <Kevin_Kofler> drago01: It depends, some work, some don't work. 19:00:26 <Kevin_Kofler> Mozilla plugins are a fairly fragile ad-hoc interface, unfortunately. 19:00:47 <j-rod> so NEEDINFO? 19:00:55 <sharkcz> yes 19:01:05 <nirik> so, what about having a web page that says to install some known vulnerable thing (before a fedora security update happens). I guess thats pretty far fetched. 19:01:31 <jds2001> #agreed feature is deferred until more information on plugin compatibility with various browsers can be obtained, 19:01:53 <jds2001> #topic PK Command Not Found 19:01:57 <jds2001> .fesco 208 19:01:58 <j-rod> pk-cnf looks neat 19:02:02 <jds2001> it does 19:02:13 <j-rod> only concern is performance hit 19:02:22 <jds2001> +1 to that, but mether pointed out some performance concerns 19:02:32 <jds2001> but his example was pretty far fetched 19:02:33 <nirik> +1, and also what about other shells? :) 19:02:41 <j-rod> does the shell seem to freeze while waiting for yum/pk? 19:02:51 <jds2001> bash is the One True Shell :) 19:02:53 <dgilmore> +1 would like to make sure it works in bash and zsh 19:02:55 <Kevin_Kofler> I assume this one only works with gnome-packagekit? 19:02:58 <jds2001> j-rod: i believe so. 19:03:07 <jds2001> Kevin_Kofler: it's a commandline thing 19:03:14 <f13> j-rod: I had to turn off bash-completion for yum stuff because it would slaughter my system every time I tried to tab complete some yum thing 19:03:19 <jds2001> Kevin_Kofler: should work with anything 19:03:34 <drago01> Kevin_Kofler: that would be annoying as hell (don't want some fancy popups while working in a terminal) 19:03:36 <j-rod> f13: yeah, that's exactly the sort of thing I'm thinking of 19:03:37 <f13> j-rod: I would worry about the PK tool doing the same. 19:03:40 <dgilmore> f13: its ok here. but i have a mirror on my lan 19:03:50 <jds2001> same here 19:03:57 <f13> dgilmore: wasn't just getting of repodata, it was all the disk I/O to read it into memory and do the search 19:04:04 <Kevin_Kofler> OK, I'm looking at the screencast, it's indeed text only. 19:04:14 <Kevin_Kofler> Looks like a cool feature. 19:04:28 * nirik hopes it also doesn't do anything if there is no net enabled. ;) 19:04:31 <Kevin_Kofler> +1 to the feature from me. 19:04:32 <drago01> f13: yeah rpm -q a<tab> does the same (heavy disk io and blocked shell) 19:04:43 <jds2001> one more? 19:04:46 <sharkcz> +1 19:04:59 <j-rod> +1, but would like performance/blocking concerns addressed 19:05:07 <jds2001> #agreed packagekit command not found feature is approved. 19:05:13 <jds2001> j-rod: not sure that's possible :( 19:05:31 <jds2001> anyhow, anything else, or put a fork in it? 19:05:35 <drago01> jds2001: do the processing in a diferent process 19:05:40 <j-rod> well, "addressed" could be "documented and explained" 19:05:44 <nirik> jds2001: how much is left on the agenda? 19:05:50 <jds2001> nirik: none 19:05:54 <nirik> wow. 19:06:22 * nirik has 2 small followup items for open floor... 19:06:39 <jds2001> k, i guess we can go late :) 19:06:44 <jds2001> feel free :) 19:06:48 <j-rod> 2 seconds... 19:06:57 <j-rod> the c-n-f thing... 19:07:00 <nirik> dgilmore: did you ever get a chance to revise/give feedback on that ThreatAssessment doc? 19:07:17 <nirik> ixs: did you ever gather data we were looking for on the flags thing? 19:07:17 <jds2001> oh, we fixed the cvs ctrl-c thing yesterday, too. 19:07:20 <j-rod> would be cool if it could be "Command not found. Search for similar? y/n" 19:08:07 <j-rod> so you could opt in for the disk thrashing 19:08:07 <dgilmore> nirik: no its one issue 19:08:07 <j-rod> if you just made a typo and know it, its faster to retype than sit there while the system spins 19:08:13 <Kevin_Kofler> nirik: I provided a list of several (mostly KDE) packages using country flags, and I'm fairly sure there are a lot more. 19:08:25 * j-rod is done now 19:08:42 <ixs> nirik: yeah, I did actually. 19:08:50 <nirik> Kevin_Kofler: yes, I know. We asked ixs to gather a bunch more data. Was just wondering if he had a chance. 19:08:56 <nirik> ixs: ok, next weeks meeting? 19:09:01 <ixs> nirik: sounds good. 19:09:07 <Kevin_Kofler> FWIW, there's some effort within KDE to make them share the flags instead of shipping many copies, but still it means many apps need flags (and not necessarily in the same format, there are apps using small icons, apps using large SVGs, apps using 3D flags). 19:09:08 <dgilmore> nirik: the issues was a minor one about how thinsg land in the lookaside hace in cvs 19:09:27 <nirik> dgilmore: ok. We should get that tweaked and release it (as we agreed to do) 19:09:38 <dgilmore> nirik: we should 19:09:43 <nirik> ixs: thanks. 19:09:46 <dgilmore> nirik: mmcgrath it on pto today 19:09:50 <Kevin_Kofler> Upstream KDE is explicitly NOT considering the option to stop shipping or using flags. 19:09:57 <jds2001> going to watch the harry potter movie! 19:10:03 * jds2001 wouldn't take PTO for that :) 19:10:05 <Kevin_Kofler> They're considering them a worthwhile feature, and I agree with them. 19:10:14 * nirik has nothing else. 19:10:39 <jds2001> ok, put a fork in it now? 19:11:01 <j-rod> yes please 19:11:02 <jds2001> #info flags will be discussed next week 19:11:16 <jds2001> #endmeeting -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
