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