FESco meeting summary for 20090717

[Jon Stanley]

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