16:59:51 <jds2001> #startmeeting FESCo meeting - 2009-07-24
16:59:55 * notting nominates zodbot for FESCo
16:59:56 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler
17:00:02 <jds2001> FESCo meeting ping -- dgilmore, jwb, notting, nirik, sharkcz, jds2001, j-rod, skvidal, Kevin_Kofler
17:00:07 * notting is here
17:00:08 * Kevin_Kofler is here.
17:00:09 * nirik is here.
17:00:09 * sharkcz is here
17:00:17 * ricky watches from afar
17:01:01 <jds2001> so f13 needs to get some eyedrops
17:01:07 <jds2001> so i told him i'd start with him
17:01:18 <jds2001> #topic No frozen rawhide proposal
17:01:22 <jds2001> .fesco 224
17:01:25 * jwb is here
17:01:41 * nirik goes to look over the page again
17:01:51 * skvidal is here
17:02:20 * dgilmore is here but needs to leave in 30 minutes
17:02:27 * j-rod in and out for a sec...
17:02:59 <nirik> f13: so, bits go to 12/Everything at branch time. Is that installable then?
17:03:08 <jwb> yes
17:03:29 <jds2001> it will hopefully remain installable :)
17:03:31 <f13> I'm here now
17:03:39 <Kevin_Kofler> +1 to the proposal.
17:03:47 <f13> yes, we wouldn't attempt to make rawhide the path installable
17:03:59 <f13> we'd only start making it installable each night once we branch and start publishing it in a different path
17:04:15 <f13> we will still do installable trees and installable live images when requested for test days
17:04:25 <f13> when the anaconda team feels that it's ready to have wider audience testing of it
17:04:55 <jds2001> so if one wants to install rawhide, they'll need to run pungi themselves?
17:05:04 <nirik> so this may result in more people getting on the f12 train before f12 is out, but I don't think thats a bad thing... as long as there are not too many blowups at the end of the cycle.
17:05:08 <Kevin_Kofler> Oh, no install images for devel? I don't see that written down in the proposal.
17:05:12 <jds2001> i.e. pungify won't run on the tree?
17:05:13 <Kevin_Kofler> And I don't think I like that.
17:05:28 <Kevin_Kofler> I don't see the benefit of dropping them.
17:05:43 <Kevin_Kofler> They don't always work, but sometimes working is better than nothing.
17:05:49 <jwb> less splintering of testers
17:06:04 <jds2001> Kevin_Kofler: you can build the images yourself if needed.
17:06:09 <f13> to get to rawhide, you would install the last snapshot, or the last release, and then yum update to rawhide
17:06:26 <f13> because constantly getting bugs about installer not working, when the installer isn't ready for testing, is not really helpful
17:06:46 <jwb> there are other ways to deal with that, but sure
17:07:02 <f13> I'm not 100% wedded to this particular wrinkle though.
17:07:07 <jds2001> jwb: what other ways?
17:07:26 <jwb> jds2001, don't build anaconda packages that aren't considered usable for testing to begin with
17:08:22 <Kevin_Kofler> Indeed. All the other packages only push versions which are supposed to be actually testable to Rawhide.
17:08:35 <jwb> that aside, i think not having rawhide installable at that point helps focus testing efforts.  so i'm ok with it
17:08:37 <Kevin_Kofler> Why should Anaconda be special?
17:08:59 <jds2001> lots of very broken packages wind up in rawhide
17:09:03 <jds2001> anaconda isn't special there.
17:09:07 <jwb> jds2001, Kevin_Kofler, that's a tangent that we can focus on later.  we have a big agenda...
17:09:10 * nirik looks, so when is the mass branch?
17:09:18 <f13> nirik: at alpha freeze
17:09:34 <f13> so if we enact it for F12, in about 2 weeks
17:09:38 <nirik> wow... so pretty early.
17:09:43 <f13> yes
17:09:55 <f13> to drive home the point that after Alpha, the focus should be on bugfix
17:10:02 <f13> new fancy development can happen in rawhide
17:10:07 <f13> which will be published
17:10:11 <f13> and useful for f13 goals
17:10:20 <nirik> so composing both a 12/Everything and a development won't be a problem resource wise?
17:10:28 <jds2001> this fixes a lot of issues :)
17:10:31 <jwb> s/f13/F13
17:10:33 * j-rod has read over the proposal in detail, hashed out stuff on the list, etc...
17:10:36 <f13> nirik: it's going to hurt, but we're making inroads on that.
17:10:39 <j-rod> +1 for this, I like it a lot
17:11:03 <Kevin_Kofler> And the mass branch is also when install images start being built daily?
17:11:04 <sharkcz> +1, I like it too
17:11:11 <f13> Kevin_Kofler: yes
17:11:12 <nirik> I think it's worth trying, and has a lot of advantages. +1
17:11:18 <skvidal> +1 it seems to make sense to try
17:11:20 <jds2001> mash is now considerably faster if I've been reading correctly.
17:11:21 <jwb> f13, are we confident we can get the bodhi and mash changes in place in 2 weeks?
17:11:26 <f13> Kevin_Kofler: ideally we'd have had a few installer test days prior to feature freeze
17:11:30 <jwb> jds2001, not exactly, no
17:11:36 <f13> jwb: luke said it should be minimal effort.
17:11:39 <jds2001> jwb: :(
17:11:47 <f13> jds2001: it was faster until we turned on deltas
17:12:03 <kital> clear
17:12:09 <f13> jwb: I'd like to set a timeline that if we're not ready by alpha freeze, we punt to f13
17:12:15 <f13> and do f12 as originally planned
17:12:21 <jwb> s/f13/F13
17:12:25 <Kevin_Kofler> So I don't object to the install images stuff either, I confirm my +1 vote to the proposal.
17:12:25 <j-rod> speaking of drpms... are they really worth all the pain they're causing?
17:12:36 <jwb> j-rod, yes, they are
17:12:42 <jds2001> j-rod: different topic :)
17:12:47 <jwb> f13, i think that is a reasonable goal
17:12:53 <jds2001> but anyhow
17:13:01 <j-rod> yeah, sorry, realized I should save that for later too late. :)
17:13:08 <f13> heh
17:13:14 <notting> as part of releng, i already approved this, so +1.
17:13:14 <jds2001> oh, +1, seems like a very sane proposal.
17:13:14 <j-rod> ok, if they're worth the pain...
17:13:29 <jwb> f13, we still need to work out signing right?
17:13:39 <f13> yes, signing is also a bit of a sticky point
17:13:50 <f13> I didn't mark in teh proposal at which point we'd promise to have everything signed
17:13:51 <jds2001> #agreed No frozen rawhide proposal is approved.  If not ready by alpha freeze of F12, will be deferred to F13.
17:13:58 * onekopaka notes that f13's signing bridge got built
17:13:59 <f13> ideally it'd be after mass branch
17:14:13 <f13> however it remains to be seen if we can safely automate signing to make this happen.
17:14:39 <jwb> f13, ok.  i think that's something we can work through, particularly with the 'punt to F13' provision in place
17:14:46 <jwb> so i'm +1 as well
17:14:47 <f13> thanks guys!  I'll check back in with progress before alpha freeze
17:14:56 <jwb> excellent
17:15:07 <jds2001> thanks f13!  Get some eyedrops :)
17:15:20 <f13> yes, I'd like to see again
17:15:35 <jds2001> #topic Bugzilla 484855 - Mediawiki Fedora-only patch
17:15:38 <jds2001> .fesco 225
17:15:59 <jds2001> I forgot to add the meeting keyword to this, was just wondering where it went :/
17:16:08 <nirik> I'd like to start by saying I would hope we can avoid fesco micro managing packagers.
17:16:17 <Kevin_Kofler> nirik: Me too.
17:16:18 * ricky hopes his comment made the core of the issue clearer
17:16:19 <jds2001> same here.
17:16:24 * ricky agrees
17:16:54 <nirik> in the past when we have had sticky packaging issues where people cannot agree, we have appointed a mediator. Should we do that here?
17:16:55 <Kevin_Kofler> Plus, this was brought up hours before the meeting and I didn't have the time to truly study the details of what the patch does and how it can be done differently.
17:17:15 <nirik> Kevin_Kofler: agreed. I didn't have a chance to read the packagers reply very well or understand it.
17:17:31 <jwb> is there someone on fesco willing to moderate this?
17:17:36 <jds2001> this bug has been going on for 5 months though.
17:17:48 <ricky> Sorry about that.  I was honestly hoping very much to avoid filing a ticket for this, but after the last comment, I didn't see it moving forward any other way.
17:17:53 <jds2001> with minimal response from the maintainer, but we're not focused on that.
17:17:54 <jwb> jds2001, then i think it can wait another week for us to make an informed decision...
17:18:04 <jds2001> jwb: it can.
17:18:41 * ricky is fine with that as well
17:18:43 <jds2001> ok, so let's defer this?
17:18:43 <ricky> Thanks for bringing some attention to this though
17:18:47 <jwb> Kevin_Kofler, you seem to have made the most comments from a FESCo perspective.  do you want to try moderating this for now?
17:18:49 <jds2001> np
17:18:50 <nirik> Or perhaps we could ask for someone from FPC to moderate who has no interest in the package or the issue?
17:19:06 <Kevin_Kofler> jwb: I can take care of moderating this.
17:19:13 * nirik is fine with that as well.
17:19:16 <jwb> anybody opposed to that?
17:19:20 <jds2001> nope
17:19:24 <sharkcz> no
17:19:34 <nirik> if no accomodation can be reached, we can revisit?
17:19:42 <jwb> Kevin_Kofler, thanks.  i think we'll all try and keep an eye on the ticket as well
17:19:42 <Kevin_Kofler> I certainly have the packaging experience, and if there are questions for FPC, I'll just talk to rdieter. :-)
17:19:52 <jwb> sounds fine
17:20:03 <jds2001> #agreed Kevin_Kofler will moderate mediawiki packaging dispute
17:20:10 <ricky> Should I reply to athimm's last comment?  I was hoping to deal with some of the statements in meeting to avoid turning the ticket into another pointless flamewar.
17:20:41 * ricky will probably hold off for the week unless anybody specifically wants to see a response
17:20:42 <jwb> ricky, in ticket please.  i don't think athimm is here
17:20:54 <ricky> I was talking about the ticket comment
17:21:06 <jds2001> if it turns into a flameware we can deal with that.
17:21:12 <jds2001> s/ware/war :)
17:21:27 <ricky> OK then, thanks again
17:21:54 <Kevin_Kofler> ricky: Please post all the info you can provide to the ticket.
17:22:22 <Kevin_Kofler> I really need to understand the details to arbitrate.
17:22:25 <ricky> All right.  I'll be repeating a lot of what I said on the bug though :-/  I'm fine with it if that's what you prefer though.
17:22:43 <jds2001> alright, on to the next hot item.
17:22:54 <jds2001> #topic mikeb sponsor nomination
17:23:00 <jds2001> .fesco 211
17:23:06 <Kevin_Kofler> -1, for several reasons:
17:23:18 <Kevin_Kofler> * mikeb himself hasn't even confirmed he is interested in becoming a sponsor at all.
17:23:28 <nirik> Kevin_Kofler: he has via irc.
17:23:28 <jds2001> Kevin_Kofler: he has, i asked him specifically.
17:23:42 <Kevin_Kofler> But that still leaves the others. :-)
17:23:55 * nirik notes he can't see any of the emails to the sponsors list. I guess he could have chimed in on the fesco ticket.
17:23:56 <Kevin_Kofler> He has 2 packages and 3 reviews, that's very little.
17:24:33 <nirik> true, but I don't think quantity should be a absolute requirement.
17:24:35 <j-rod> however, he's one of the core infrastructure guys, and deals with a lot of package stuff every day
17:24:36 <Kevin_Kofler> https://admin.fedoraproject.org/pkgdb/users/packages/mikeb - he owns 2 packages and comaintains nothing.
17:25:14 <Kevin_Kofler> Plus, several sponsors objected.
17:25:25 <nirik> I might like to defer this to next week and ask him to post to the trac ticket more info... ie, who is he intending to sponsor? does he have time for it? etc
17:25:32 <jds2001> the objections seemed to be on the basis on quantity, though
17:26:18 <jds2001> What I wanted to discuss was maybe providing some rough guidelines on sponsorship.
17:26:30 <jds2001> Though I believe that it will always be subjective.
17:26:50 <j-rod> +1 for nirik's suggestion, NEEDINFO
17:27:01 <nirik> I posted my thoughts on that to the list... I agree more information on those things would be good to note in the wiki, etc.
17:27:03 <jds2001> and therefore, I'm not sure what guidelines we can provide.
17:27:11 * jwb notes he has to leave in 3 min
17:27:33 <jds2001> jwb: you'll miss all of our great features! :)
17:27:50 <jwb> jds2001, i'll be on the phone, but i'll try to pay attention
17:28:02 <jds2001> jwb: i was just joking :)
17:28:12 * notting is ok with NEEDINFO. probably would be -1 without any additional info
17:28:13 <jds2001> anyhow, lets defer this til next week
17:28:19 <nirik> does anyone object to deferring and asking him for more info?
17:28:20 <Kevin_Kofler> defer +1
17:28:28 <nirik> is he even cc'ed on the ticket?
17:28:44 <jds2001> not sure, I'll check when I update the ticket :)
17:28:57 * jds2001 didnt make that one
17:29:00 <nirik> nope. he's not.
17:29:04 <nirik> may not know it exists.
17:29:12 <notting> well, the cc issue can be fixed
17:29:19 <jds2001> yep
17:29:25 <nirik> ok, lets move on?
17:29:49 <jds2001> #agreed mikeb sponsor nomination is deferred, waiting for more information (more details will be in ticket)
17:30:00 <jds2001> anyhow
17:30:12 <jds2001> #topic power mgmt F12
17:30:19 <jds2001> .fesco 217
17:31:39 <notting> that's a lot of documentation
17:31:45 * jds2001 not sure what an httpd server has to do with this
17:31:47 <Kevin_Kofler> +1, looks good.
17:31:52 <Kevin_Kofler> notting: That's a good thing. :-)
17:32:04 <notting> except i'm not sure it's accurate, nor all good ideas
17:32:06 <Kevin_Kofler> A change from the usual "FIXME: write me".
17:32:12 <jds2001> hold on, $WORK coworker here :)
17:32:12 <notting> mjg59: how much of that stuff should we be doing by default, anyway?
17:32:32 <nirik> yeah, we should try and ditch all the suggestions that tell people to run obscure commands.
17:32:47 <jwb> does this overlap with powertop
17:32:55 <notting> it uses powertop
17:33:05 <jwb> ah
17:33:05 <Kevin_Kofler> notting: Certainly not downgrading the network card to a lower speed. ;-)
17:33:16 <nirik> overall I like it, but I think the user suggestions section needs to be revamped/re-written.
17:33:24 <notting> no, but things like usb autosuspend, hal CD polling (which is dying anyway, .etc)
17:33:37 <notting> reading it, the docs don't really relate to the rest of the feature (they don't even mention tuned at all)
17:33:49 <nirik> yeah.
17:34:06 <jwb> i agree
17:34:22 <jwb> the feature looks cool, but needs a small documentation revamp geared towards users
17:34:47 <notting> so, +1 with the caveat that the documentation needs to reflect the feature, not general tips
17:34:49 <nirik> should we defer? or approve with docs being fixed?
17:35:05 <jwb> nirik, getting close to freeze...
17:35:16 <nirik> +1 here if docs get fixed. I note that 60% means that it will need to hussle to get done in time.
17:35:43 <jds2001> +1 with docs fix, the docs are horrid atm :)
17:35:59 <sharkcz> +1
17:35:59 <skvidal> agreed on docs
17:36:00 <j-rod> +1, looks like there's plenty of people putting in solid effort on this
17:36:00 <skvidal> +1
17:36:24 <j-rod> and we could certainly stand to be less harsh on batteries
17:36:35 <Kevin_Kofler> AFAICT, this looks like a set of several independent changes, so I don't think the percentage says all that much.
17:36:51 <Kevin_Kofler> AIUI, there'll definitely be enough in F12 to advertise the feature.
17:37:10 <jds2001> #agreed Power management F12 feature is approved, documentation needs to be revamped in order to be more user facing.
17:37:32 <jds2001> #topic stap tracing refresh
17:37:38 <jds2001> .fesco 220
17:38:15 <Kevin_Kofler> This is the replacement for the larger feature which didn't make it.
17:38:21 <Kevin_Kofler> It's the subset which got actually done.
17:38:30 <Kevin_Kofler> So +1 from me.
17:38:41 <nirik> it's kinda a odd name, but otherwise ok. +1
17:38:46 <sharkcz> +1
17:38:47 <nirik> (also fix FIXMEs)
17:39:13 <notting> +1, although the part that did get done isn't nearly as exciting
17:39:23 <j-rod> "we updated some stuff"... really a feature?
17:39:58 <jds2001> there's some new stuff.
17:40:10 <j-rod> I mean, its good that its being done, but... *snooze*
17:40:16 <notting> j-rod: as i read it, it now has the support for instrumenting userspace. which is something to advertise for other apps to use
17:40:20 <Kevin_Kofler> jds2001: Right.
17:40:30 <nirik> "we revamped this area so it doesn't suck as much and has new feaures" is how I read it.
17:40:44 <Kevin_Kofler> Yeah, the part that didn't get done was to actually ship some userspace stuff with the instrumentation.
17:40:51 <Kevin_Kofler> But the feature is available now.
17:40:52 <jds2001> notting: i think it'
17:41:03 <jds2001> it has supported tracing userspace for awhile
17:41:13 * jds2001 has never used it for such, only kernel tracing
17:42:11 <Kevin_Kofler> What's new is this part: "Experimental utrace/kprobe sdt support. This is the basis for the next step  Systemtap Static Probes Feature."
17:42:21 <Kevin_Kofler> This allows inserting static probes into applications.
17:42:26 <jds2001> anyhow, there is significant new stuff, it's being developed in Fedora, and we want to trumpet that :)
17:42:44 <Kevin_Kofler> The next step will be shipping some userspace stuff with those probes already inserted, which got postponed to F13.
17:42:55 <sharkcz> and it missed F11 IIRC
17:43:43 * jds2001 will brb
17:43:56 <j-rod> okay, I suppose on the basis of there being some new nuggets and its being developed in fedora...
17:43:57 <j-rod> +1
17:44:10 <Kevin_Kofler> We're missing one more +1 (we have 4 of them now).
17:44:29 <j-rod> It could stand to be called something more informative than "Systemtap Tracing Refresh" though
17:44:51 * nirik agrees, the name isn't ideal
17:46:18 <Kevin_Kofler> SystemtapTracingImprovements?
17:47:01 <jds2001> +1
17:47:03 <jds2001> sorry
17:47:20 <Kevin_Kofler> I counted five +1 votes, can we move on now?
17:47:26 <jds2001> #agreed SystemTap tracing refresh feature is approved
17:47:33 <jds2001> Kevin_Kofler: i can only type so fast :)
17:48:04 <jds2001> #topic yum langpack plugin
17:48:09 <jds2001> .fesco 186
17:48:17 * skvidal does not like the idea of the langpack being merged into yum core
17:48:24 <jds2001> so we got some questions answered here
17:48:40 <Kevin_Kofler> Let's just keep it as a plugin.
17:48:51 <jds2001> huh?
17:49:07 <jds2001> we had the question of integration
17:49:07 <Kevin_Kofler> Somebody added this sentence to the feature page: "Rather than making changes to each of the tools using Yum (as outlined above) it might be easier just to enable the langpack plugin in yum by default to avoid having to change Yum code in multiple places?"
17:49:21 <Kevin_Kofler> That's what skvidal's and my comments are referring to.
17:49:59 <jds2001> right, but even as a plugin, tooling changes are required.
17:50:17 <jds2001> notting would probably be the better person to comment than me, though.
17:50:17 <notting> i still don't like the idea of the metapackages as the key for what languages to install
17:50:27 <notting> but i also don't have any better ideas at the moment :/
17:51:43 <jds2001> so are you satisfied with the changes required, notting?
17:52:26 <notting> that's a loaded question
17:53:05 <jds2001> hehe
17:53:16 <jds2001> this one's not easy :)
17:53:49 <Kevin_Kofler> Folks, we have a lot more features to discuss...
17:53:55 <jds2001> but I do want to be a first-class distro for i18n, too
17:54:00 <Kevin_Kofler> I vote +1 to this (in fact I already did last week IIRC).
17:54:36 <notting> much like the opensharedroot feature, it strikes me as 'aspects of this are doing it wrong, and will cause problems for other packages later'. but don't have the time/resources to throw at doing it differently now
17:54:38 <nirik> I guess I will also vote +1. I am reluctant somewhat due to how many places this touches... it's going to require a lot of tweaking.
17:55:12 * notting is curious what skvidal's opinion is
17:55:20 <skvidal> I don't like having it in core
17:55:27 <skvidal> but if it is a plugin, installed by default, that's workable
17:55:38 <skvidal> I think it is not obviously going to benefit us
17:56:04 <notting> well, the benefit, if it works, is to get out of the business of having to update comps
17:56:09 <notting> for a lot of things
17:56:26 <skvidal> notting: forgive my skepticism on it working totally
17:56:51 <j-rod> ooh, so, like, someone just picks their language and their packages, and all the stuff under internationalization (or whatever it is) just gets properly installed?
17:57:05 <notting> it's worth a shot. that's why we have contingency plans. +1
17:57:09 <nirik> j-rod: yeah.
17:57:14 <nirik> in theory
17:57:21 <j-rod> cool. okay.
17:57:22 <j-rod> +1
17:57:29 <sharkcz> +1
17:57:43 <jds2001> yeah, +1 here too. Contingency plans are good
17:58:03 <jds2001> #agreed yum langpacks feature is accepted
17:58:20 <jds2001> #topic KVM stable guest ABI
17:58:23 <jds2001> .fesco 202
17:58:24 <skvidal> +0 - not thrilled
17:58:29 <skvidal> but I'll live
17:59:11 <jds2001> that page looks to have gotten cleaned up
17:59:28 <Kevin_Kofler> Yeah, they did what we asked for.
17:59:31 <jds2001> +1 here
17:59:35 <nirik> yeah, looks much nicer.
17:59:41 <Kevin_Kofler> +1 here too.
17:59:46 <sharkcz> +1
17:59:57 <nirik> it's not entirely clear how to update a guest to the new stuff and ignore the stable os tho...
18:00:03 <notting> +1, much better.
18:00:17 <nirik> "If you want to move to a newer machine type, you just edit the guest config and update it there."
18:00:20 <cdub> nirik: i don't follow your question?
18:00:37 <nirik> cdub: how do I know what to change in the guest config?
18:00:41 <skvidal> I liked this proposal + 1
18:00:43 <skvidal> err +1
18:00:47 <nirik> do I just make a new guest and copy/paste?
18:00:53 <nirik> anyhow, thats a side note... +1 here too.
18:00:59 <jds2001> #agreed KVM Stable Guest ABI feature is accepted
18:01:12 <cdub> nirik: well, it's mainly about letting the hv change underneath, and _not_ having to change the guest at all
18:01:31 <jds2001> cdub: right, we want to use new features of the hv
18:01:38 <nirik> cdub: sure, but what if I do want to take advantage of new hv changes in my linux guests?
18:01:39 <jds2001> how to do that with an existing guest?
18:01:44 <Kevin_Kofler> cdub: But the thing is, some people want to get their stuff upgraded automatically.
18:02:08 <cdub> yes, in that case you need to update guest config
18:02:14 <Kevin_Kofler> With this libvirt patch, there's no way to tell it "I always want the latest" because it'll "helpfully" "canonicalize" it to a specific version.
18:02:33 <j-rod> +1 on stable abi
18:02:35 <Kevin_Kofler> There should be a way to just store "pc" in the guest config.
18:03:18 <jds2001> well that might be an F13 feature :)
18:03:35 <jds2001> #topic PK browser plugin
18:03:42 <jds2001> .fesco 207
18:04:04 <cdub> Kevin_Kofler: i didn't do the libvirt work, but i'd expect "pc" to stay reserved
18:04:14 <jds2001> ok, so webkit browsers dont work/
18:04:22 <jds2001> but they are working on it.
18:04:26 <Kevin_Kofler> And Konqueror probably hasn't been tested at all.
18:04:45 <Kevin_Kofler> And BTW, isn't Epiphany also WebKit-based in Rawhide?
18:04:55 <nirik> Kevin_Kofler: yeah, I think so.
18:04:57 <jds2001> is konqueour not a webkit based browser?
18:05:02 <jds2001> forgive my ignorance.
18:05:12 <Kevin_Kofler> Konqueror is KHTML-based.
18:05:19 <Kevin_Kofler> Not WebKit-based.
18:05:22 <nirik> cdub: just consider that a feature request or documentation request I guess. ;)
18:05:24 <Kevin_Kofler> WebKit is a fork of KHTML.
18:05:30 <Kevin_Kofler> Konqueror uses the original KHTML.
18:05:31 <cdub> nirik: fair enough ;-)
18:05:38 <jds2001> sorry :)
18:06:25 <jds2001> anyhow, I'm fine with this the way it is - we know there are limitations.
18:06:41 * jds2001 suspects that 90% of our users use FF anyways.
18:06:43 * nirik wonders again about his security question. Should have asked the feature owner... not a big deal tho.
18:07:01 <jds2001> security?
18:07:07 * jds2001 forgets the question
18:07:27 <j-rod> it does seem... potentially exploitable...
18:07:51 * jds2001 assumes it asks the user for confirmation????
18:07:56 <jds2001> that would make sense.
18:08:01 <j-rod> yeah, I believe so
18:08:13 <j-rod> but sometimes users just clickety click click click
18:08:14 <nirik> like the recent firefox update...
18:08:51 <nirik> user has 3.5.0, a exploit comes out, they release 3.5.1, but it's not updated in fedora yet or on mirrors. Someone puts up a page asking them to install firefox. Then they can see from their logs the user has a vulnerable version.
18:09:11 <notting> AIUI, it doesn't install any packages that the user couldn't install with gpk-application (or whatever), which has the same controls
18:09:15 <nirik> or make someone install something from fedora with a bug (window might be small tho)
18:09:37 <Kevin_Kofler> nirik: The README file talks about this.
18:09:43 <Kevin_Kofler> http://cgit.freedesktop.org/packagekit/plain/contrib/browser-plugin/README
18:09:44 * nirik goes to look.
18:09:49 <Kevin_Kofler> See the "Security Considerations" section.
18:10:26 <nirik> yeah.
18:10:39 <Kevin_Kofler> "the only applications that could be installed in that way are applications from the package repository already configured for the system" - that makes this feature not all that useful at all.
18:10:39 * notting is +1; it's mostly done, it's something interesting to mention. i do wonder how much uptake there will be in web pages providing this interface
18:10:42 <nirik> it's not a great big deal, but there is a slight chance for vulnerability there.
18:10:53 <skvidal> notting: I concur w/notting
18:11:03 <skvidal> hmm - concur with notting on uptake of the feature
18:11:06 <skvidal> rather than just providing an rpm
18:11:10 <Kevin_Kofler> Normally, if users want to install things from websites, it's somethirdpartyrepo-release for a repo which they DON'T have yet.
18:11:18 <Kevin_Kofler> Then they just fire up their package manager to install things.
18:11:20 <skvidal> but I don't have a defensible reason to keep it out
18:11:22 <nirik> Kevin_Kofler: if it allowed for otherwise it would be a nasty security hole.
18:12:00 <Kevin_Kofler> nirik: And a link to foo-release.rpm is more secure how?
18:12:02 * jds2001 te4lls you to install rpmfusion-release - or what purports to be rpmfusion-release
18:12:18 <jds2001> but it's really root-kevins-system-really-bad.rpm
18:12:20 <jds2001> :)
18:12:34 <j-rod> ah. crap. need to read closer...
18:12:36 <Kevin_Kofler> The security issue of *-release packages is a problem which will always be there.
18:12:42 <nirik> sure, thats got problems to... but this is more automatic...
18:12:50 <Kevin_Kofler> But so will the fact that people want to add third-party repositories.
18:12:55 <Kevin_Kofler> And this plugin does nothing for that.
18:12:59 <j-rod> I was thinking this let arbitrary rpms from wherever be installed by clicking on a thing in a web page
18:13:03 <nirik> right, it's an unrelated issue.
18:13:13 <nirik> well, related, but not something we should worry about for this.
18:13:28 <j-rod> if its only a helper to install things from the user's enabled repos, then I have no real objections
18:13:30 <j-rod> +1
18:13:53 <Kevin_Kofler> -1 here, it's a useless gimmick not worth advertising as a feature.
18:14:12 <jds2001> +1 here, no reason not to advertise it.
18:14:16 * nirik is looking to see where the voting stands...
18:14:17 <Kevin_Kofler> It is only successfully tested in one browser (Firefox) and known NOT to work in at least a whole class of others.
18:14:32 <skvidal> +1 on the no reason not to do it
18:14:38 <sharkcz> +1
18:14:39 <Kevin_Kofler> It doesn't solve the problem the users will actually expect it to solve (installing packages from third-party repos).
18:14:58 <Kevin_Kofler> So how's this something to present as a Fedora feature?
18:15:34 <jds2001> i can put a link on a webpage to go install openoffice.org-writer right by an ODT document, for instance.
18:16:02 <jds2001> maybe your particular problem space isn't solved, but others are.
18:16:06 <j-rod> I can see navigating to a project's web page, which includes an "install your distro's package of our software" link
18:16:18 <jds2001> that too.
18:16:19 <j-rod> or something like that
18:16:44 * nirik shrugs. I don't see this as being that great a feature either... +0 from me I guess.
18:17:30 <j-rod> its more of a "hey, look at this nifty thing we did, and maybe some sites might take advantage of" than something I'd actually find terribly useful myself
18:17:46 * jds2001 sees four +1
18:18:13 <sharkcz> no, there are 5 +1
18:18:35 <jds2001> oh?
18:18:35 <Kevin_Kofler> Hmmm, skvidal isn't actually clear on whether he's +1ing the proposal or not.
18:18:48 <jds2001> actually he is.
18:18:49 <skvidal> I agree with notting and with jds2001
18:18:56 <skvidal> +1 - why the hell not
18:19:11 <jds2001> #agreed PackageKit browser plugin feature is accepted.
18:19:16 * skvidal has a certain devil-may-care thing going on today :)
18:19:45 <jds2001> #topic GFS2 clustered Samba
18:19:52 <jds2001> .fesco 212
18:19:57 <jds2001> this had me quite confused.
18:20:22 <skvidal> jds2001: why?
18:20:36 <Kevin_Kofler> AIUI: mount as GFS2, export as Samba
18:20:39 <abhi`> jds2001, I wrote the feature page btw.
18:20:55 <Kevin_Kofler> So you get the reliability of a GNU/Linux cluster and the compatibility with inferior OSes of Samba.
18:20:55 <jds2001> abhi`: and we couldnt do this before?
18:20:58 <j-rod> Ugh, desktop went belly-up on me
18:21:01 <skvidal> I was rather pleased about this one - in terms of making samba more failsae
18:21:21 <abhi`> jds2001, yes... we couldn't do active/active samba sharing in particular
18:21:21 <skvidal> jds2001: was samba properly awae of gfs2 locking?
18:21:31 <jds2001> skvidal: it's cool, no doubt
18:21:41 * j-rod iphoning it for a sec, may be slow with replies
18:21:54 <Kevin_Kofler> +1 to the feature.
18:21:54 <sharkcz> yes, that's what the server people should like
18:21:58 <sharkcz> +1
18:22:00 <abhi`> with ctdb, multiple smbd over different nodes are aware of each others' states
18:22:06 <jds2001> skvidal: not that im aware of, but im not sure why an app would need to be.
18:22:07 <nirik> +1 here. DOn't know how many will use it, but cool.
18:22:12 <jds2001> abhi`: oh, that is cool
18:22:15 <notting> sounds neat. +1
18:22:15 <jds2001> +1 here.
18:22:17 <skvidal> jds2001: for oplocks, etc?
18:22:19 <skvidal> +1 from me
18:22:30 <j-rod> +1 here
18:22:41 <jds2001> skvidal: yeah, im just being dense is all.
18:22:47 <abhi`> failover/load balancing etc can be done
18:22:52 <skvidal> jds2001: better than being too thin :)
18:23:01 <jds2001> hehe
18:23:09 * jds2001 is el fatso :D
18:23:26 <skvidal> jds2001: fat men unite
18:23:57 <Kevin_Kofler> Next feature please!
18:23:58 <jds2001> anyhow, i see five +1's
18:24:26 <jds2001> #agreed GFS2 clusterd samba feature is approved
18:24:29 <jds2001> #topic KSM
18:24:48 <jds2001> .fesco 213
18:24:48 <Kevin_Kofler> +1
18:24:58 <jds2001> hmm, i know a certain propietary hypervisor that's been doing this :D
18:24:59 <jds2001> +1
18:25:06 <j-rod> Very cool stuff, read over that earlier
18:25:10 <j-rod> +1
18:25:20 <sharkcz> +1
18:25:23 <nirik> +11
18:25:30 <skvidal> +1 to ksm
18:25:32 <jds2001> nirik: you only get one :)
18:25:37 <j-rod> goes to 11?
18:25:40 <nirik> aww. ;)
18:25:50 <onekopaka> something is going to 11?
18:25:56 <jds2001> #agreed KSM feature is accepted
18:25:56 <notting> +1, this is obviously useful for virt
18:26:15 <jds2001> #topic KVM hugepage backed memory
18:26:35 <jds2001> so this is just libvirt changes?
18:27:01 <Kevin_Kofler> It's mostly stuff you need to do manually.
18:27:06 <nirik> https://fedoraproject.org/wiki/Features/KVM_Huge_Page_Backed_Memory (BTW)
18:27:08 <Kevin_Kofler> And it has drawbacks (can't swap out the memory).
18:27:10 <cdub> essentially, yes.  the qemu/kvm changes are already done, and the kernel already supports hugepages
18:27:11 <j-rod> also very beneficial to virt
18:27:33 <jds2001> Kevin_Kofler: no, this is automating the (currently) manual stuff
18:27:59 <jds2001> of course there are drawbacks, that's why this isnt default.
18:28:00 <j-rod> +1
18:28:02 <nirik> +1 here.
18:28:02 <Kevin_Kofler> It automates the -mem-path /dev/hugepages parameter to KVM.
18:28:05 <jds2001> +1
18:28:08 <sharkcz> +1
18:28:08 <Kevin_Kofler> All the other setup is still manual.
18:28:13 <Kevin_Kofler> See "How To Test".
18:28:30 <notting> +1, i suppose. given that we want people to use libvirt, we need all these wrappres.
18:28:42 <skvidal> +1
18:28:48 <nirik> hum... that device doesn't exist here...
18:28:59 <cdub> Kevin_Kofler: that bit is debatable
18:29:02 <nirik> or dir I guess.  /dev/hugepages
18:29:10 <jds2001> #agreed KVM Huge Page backing is accepted
18:29:33 <cdub> Kevin_Kofler: would need to grow a default location in Fedora for hugetlbfs mountpoint, or, have libvirt handle it all internally
18:29:33 <Kevin_Kofler> -1 for the record.
18:30:05 <Kevin_Kofler> cdub: And that should be done before you can call the feature complete.
18:30:18 <jds2001> #topic lower process capabilities
18:30:21 <j-rod> Nb: there's a simplified setup script thingy coming soon
18:30:24 <jds2001> .fesco 215
18:30:42 <j-rod> Its part of a jboss rfe, but would work here too
18:30:43 <jds2001> j-rod: that would be cool.
18:31:09 <jds2001> oracle can use hugepages as well, iirc
18:31:31 <jds2001> lots of stuff uses it :)
18:31:35 <jds2001> anyhow
18:31:37 <j-rod> Yup
18:31:44 <Kevin_Kofler> Hmmm, that capabilities stuff is interesting.
18:32:09 <notting> it is interesting
18:32:09 <Kevin_Kofler> They're trying to get some SELinux-style security with DAC (i.e. without relying on SELinux).
18:32:13 <nirik> wasn't this tried a while back and broke horribly?
18:32:21 <sgrubb> nope
18:32:31 <jds2001> it's not selinux-style at all.
18:32:38 <sgrubb> this isn't file system based capabilities
18:32:38 * nirik must be misremembering something else with capabilities.
18:32:41 <notting> without symlinks, you can't move /etc/resolv.conf
18:33:18 <skvidal> how does this tie in with when I do an rpm -V?
18:33:19 <Kevin_Kofler> sgrubb: How much stuff is actually being chmodded 000?
18:33:21 <jds2001> notting: how common is that? I don't do it, but I can immediately think of use cases where you might, though
18:33:30 <Kevin_Kofler> Or is this feature about the possibility only?
18:33:39 <sgrubb> shadow for sure
18:33:46 <sgrubb> gshadow too
18:34:48 <sgrubb> skvidal, we would nee to fix file permissions in the packages so that they are right
18:35:07 <sgrubb> unfortunately, some packages call out explicit perms
18:35:18 <skvidal> sgrubb: which means...?
18:35:22 <notting> sgrubb: the standard root shell has DAC_OVERRIDE, right?
18:35:29 <sgrubb> they need the spec file edited
18:35:37 <sgrubb> notting, yes
18:35:51 <sgrubb> anything from sshd and login are still DAC_OVERRIDE
18:35:57 <sgrubb> and gdm etc
18:36:32 <nirik> so this feature is gathering information to make those changes? or it's also making them to the @core packages? or ?
18:36:53 <sgrubb> yes I want to make them to all the @core packages
18:37:36 <sgrubb> as far as patches to daemons, I already have several that are tested but not built into rawhide
18:38:15 <Kevin_Kofler> +1 to the feature.
18:38:56 <jds2001> are you getting these patches upstream to the various daemons?
18:39:10 <Kevin_Kofler> I think it definitely makes sense to do these changes, and our meeting is a bad place to discuss the details. ;-)
18:39:17 <Kevin_Kofler> We have 5 more features on the table.
18:39:21 <sgrubb> haven't yet, but that is the intention
18:39:57 <jds2001> cool
18:40:00 <jds2001> +1
18:40:08 <sharkcz> +1
18:40:16 <notting> +1 in general. i think the resolv.conf bit could use work, but that's a ways down the line
18:40:40 <nirik> +1 here as well. A heads up to the list might be good of the changes... also some release notes for users might be nice.
18:40:43 <skvidal> +0 - I'm a little skeptical of the benefits here given the number of things it is touching - but I don't want to block
18:41:03 <j-rod> +1, seems like a good thing to be doing from a security standpoint
18:41:14 <jds2001> #agreed Lower process capabilities feature is accepted.
18:41:17 <sgrubb> yes, I'll adjust release notes based on where this project finishes
18:41:23 <j-rod> can take it on an app-by-app basis too
18:41:28 <sgrubb> sure
18:41:34 <jds2001> #topic ovirt node
18:41:42 <jds2001> .fesco 216
18:41:49 <Kevin_Kofler> This one contains a spin.
18:41:54 <Kevin_Kofler> Plus other stuff.
18:42:15 <huff> 2 packages and a spin
18:42:36 <Kevin_Kofler> Doesn't the spin have to go through the spins process?
18:42:43 <huff> yes
18:42:46 <jds2001> it does.
18:42:47 <Kevin_Kofler> Did it already?
18:42:53 <huff> https://fedoraproject.org/wiki/Ovirt_Node_Spin
18:42:56 <nirik> it hasn't yet... but it is.
18:43:08 <nirik> the maintainer/submitter was at the last spins meeting to answer questions.
18:43:21 <nirik> it will be voted on next meeting (monday) I suspect
18:43:32 * j-rod knows a fair amount about this from the inside...
18:43:38 <Kevin_Kofler> +1 to the feature, contingent on the spin getting accepted.
18:43:40 <j-rod> +1, assuming the spin is approved
18:43:48 <sharkcz> +1
18:43:52 <jds2001> +1
18:44:08 <nirik> yeah, +1 here as well, seems a nice addition to the fedora family. ;)
18:44:30 <jds2001> #agreed ovirt node feature is accepted
18:44:35 <notting> +1, seems like a neat idea.
18:44:54 <jds2001> #topic Rakudo Perl 6
18:45:00 <jds2001> .fesco 218
18:45:32 <Kevin_Kofler> Rakudo review request: https://bugzilla.redhat.com/show_bug.cgi?id=498390
18:45:34 <buggbot> Bug 498390: medium, medium, ---, nobody, NEW, Review Request: rakudo - Rakudo - A Perl compiler for Parrot
18:45:49 <Kevin_Kofler> Seems like this is waiting on upstream releasing something which actually works with a system Parrot.
18:46:35 <skvidal> -1 we're so close to putting a stake in perl - let's not let  a new one gain a foothold
18:47:18 <jds2001> well, perl in @core, yeah
18:47:31 * jds2001 thinks a stake needs to be put in that
18:47:32 <skvidal> jds2001: right
18:47:39 <Kevin_Kofler> skvidal: Perl (5) is not going to go away any time soon, it's required for KDE.
18:47:48 <nirik> is this something we should tout? is there a lot of demand? Also, we don't have any timeframe? thats sad.
18:47:49 <skvidal> Kevin_Kofler: well, we could get rid of kde, too ;)
18:47:55 <wwoods_> kernel builds, too, right?
18:48:01 <skvidal> wwoods_: hush :)
18:48:16 <skvidal> I'm not serious about getting rid of perl
18:48:19 <Kevin_Kofler> But this feature is about Perl6 which isn't really used anywhere yet.
18:48:20 <skvidal> but I do think -1 to this feature
18:48:37 <Kevin_Kofler> And the problem is that I doubt it'll be ready in time for F12 given the state of the review request.
18:48:45 * jds2001 is -1 to this feature, there's no package in sight
18:49:06 <nirik> yeah, we could drop it if it's not ready though?
18:49:36 <jds2001> by wendesday?
18:49:56 * jds2001 doesnt see that as remotely possible.
18:49:58 <Kevin_Kofler> jds2001: New packages can go in late.
18:50:15 <j-rod> so its basically an implementation of as-yet-not-finalized perl6...
18:50:25 <j-rod> it largely boils down to being a new package
18:50:27 <Kevin_Kofler> But I have no idea when it will be ready and apparently neither does the packager.
18:50:35 <nirik> I guess I would say to punt to next release when it's in and ready and working...
18:50:40 <j-rod> and I'm sure there *are* people excited about perl6
18:50:52 <skvidal> j-rod: they died waiting for it
18:50:57 <notting> 'next ten years'? wow, that's not really a normal fedora scale.
18:50:58 <Kevin_Kofler> LOL
18:51:10 <j-rod> I don't see why we can't approve it as a feature, and drop/punt it if its not ready in time
18:51:20 <notting> skvidal: perl6 vs hurd vs chinese democracy vs. duke nukem forever?
18:51:21 <j-rod> although, if its going to be 10 years...
18:51:27 <j-rod> hahahaha
18:51:50 <skvidal> mmmm
18:51:55 <nirik> are we going to have a special session before feature freeze end on features? or is this it?
18:51:59 <skvidal> if duke nukem comes out first....
18:52:10 <jds2001> nirik: i wanted to talk about that
18:52:19 <jds2001> i forgot at the beginning.
18:52:21 <nirik> how many do we have left?
18:52:30 <Kevin_Kofler> nirik: 3 more
18:52:32 <notting> given that they haven't even submitted a buildable package to review (as of yesterday, their last comment update), -1
18:52:41 <jds2001> 3
18:52:45 <nirik> yeah, -1 here, try again in F13
18:52:47 * abadger1999 notes that the non-timeframe comment was made in May and the feature page lists releases of parrot and rakudo on July 23.
18:52:50 <sharkcz> -1 here
18:53:07 <skvidal> -1
18:53:11 <notting> abadger1999: yesterday they updated the bug with the pointer to a scratch build that immediately fell over
18:53:15 <Kevin_Kofler> I'm voting +1 because I don't see anything wrong in principle.
18:53:25 <j-rod> +1 here too
18:53:27 <Kevin_Kofler> I have my doubt it can make F12, but it can be punted later.
18:53:35 <j-rod> but with the caveat its not likely to fly for f12
18:53:49 <abadger1999> <nod> But that's not necessarily an indicator that things aren't going to be ready soon.
18:54:12 <nirik> if we are doing a special session I would be fine with defering until then too. ;)
18:54:13 <abadger1999> There's not enough information about what the packagers or upstream are doing/the current state of things.
18:54:14 <Kevin_Kofler> So how many +1 and -1 votes do we have now?
18:54:22 <jds2001> four -1
18:54:24 <jds2001> two +1
18:55:07 <jds2001> anyhow, nothing wrong with deferring til wednesday to see if anything changes
18:55:36 <Kevin_Kofler> I'm OK with deferring too.
18:55:41 <Kevin_Kofler> Seems we can't make a decision today.
18:55:44 <jds2001> #agreed Rakudo perl6 feature is deferred until Wednesday special session
18:56:01 <jds2001> #topic virt privileges
18:56:07 <jds2001> .fesco 221
18:57:25 <jds2001> +1
18:57:41 <sharkcz> +1
18:57:59 <Kevin_Kofler> +1
18:58:01 <nirik> +1 here... I ran kvm guests like that here before I moved to libvirt.
18:58:27 <j-rod> +1
18:58:43 <jds2001> #agreed virt privileges feature is accepted
18:58:55 <notting> seems like a good idea.+1. although how does this work when you start doing things like PCI passthrough, etc. etc.
18:58:56 <jds2001> #topic virt storage management
18:59:07 <jds2001> .fesco 222
18:59:35 <cdub> notting: it will get...interesting....
19:00:13 <Kevin_Kofler> +1 to Virt Storage Management too
19:00:22 <sharkcz> +1
19:00:36 <nirik> +1, although I suspect most fedora users don't have storage setups like those. :)
19:00:44 <jds2001> is it really libvirt's job to scan storage?
19:00:59 <jds2001> +1 at any rate
19:01:17 <j-rod> +1, seems generally useful for datacenter type stuff
19:01:33 <jds2001> i guess $PROPIETARY_THING i use here at work does that.
19:01:38 <sharkcz> there is a rescan script packaged in sg3_utils
19:01:38 <notting> +1, seems useful. dunno if you'll find that many testers :)
19:02:17 <Kevin_Kofler> Next feature please? We have one more left AFAIK.
19:02:41 <jds2001> #agreed virt storage management feature is accepted
19:02:49 <jds2001> #topic virt tck
19:02:56 <jds2001> this is just a test suite?
19:03:06 <jds2001> .fesco 223
19:03:07 <Kevin_Kofler> Looks like it.
19:03:18 <Kevin_Kofler> Is this worth advertising as a feature?
19:03:26 <Kevin_Kofler> It says it's a test suite users will be able to use.
19:03:27 <jds2001> sort of what i was wondering
19:04:13 <nirik> is this usable for end users to tell if their hardware is suitable for virt and what kind?
19:04:17 <Kevin_Kofler> But mostly it's for Fedora's internal use and for third-party virtualization developers' use.
19:04:33 <Kevin_Kofler> "End users will see fewer regressions and bugs in the virtualization technologies." doesn't sound much like a feature to advertise to end users.
19:04:42 <Kevin_Kofler> It's just a regular process improvement.
19:05:08 <nirik> yeah.
19:05:24 <Kevin_Kofler> This is the actual package: https://bugzilla.redhat.com/show_bug.cgi?id=513253
19:05:25 <buggbot> Bug 513253: medium, medium, ---, sseago, CLOSED RAWHIDE, Review Request: perl-Sys-Virt-TCK - libvirt Technology Compatability Kit
19:06:15 <nirik> yeah, I would say cool stuff and good to have, but not a feature.
19:06:24 <jds2001> me too
19:06:34 <sharkcz> same here
19:06:45 <Kevin_Kofler> Same here, so I vote: -1 not a feature
19:06:58 <nirik> -1, but good idea and work...
19:06:59 <j-rod> well, we wrote it
19:07:13 <j-rod> so that alone can qualify it as a feature, can't it?
19:07:33 <jds2001> it could....
19:07:45 <j-rod> and is feature advertising only aimed at end-users?
19:07:53 * j-rod thinks it isn't
19:08:02 <jds2001> not really, it's aimed at generating press
19:08:15 <jds2001> and really, come to think of it
19:08:24 <j-rod> "Fedora is working hard to further improve and stabilize virtualization technology"
19:08:26 <jds2001> press that we're trying to be interoperable is *really good*
19:08:31 <nirik> https://fedoraproject.org/wiki/Features/Policy/Definitions
19:08:42 <j-rod> +1 from me
19:09:09 <skvidal> +1 overall
19:09:13 <jds2001> yeah, this meets definition #3
19:09:32 <notting> i'm not sure i'd qualify a test suite as 'exciting new capabilities'. so -1 from me.
19:09:40 <Kevin_Kofler> +2 -3 now
19:09:48 <jds2001> +1
19:09:57 <Kevin_Kofler> Now +3 -3, fun...
19:09:58 <jds2001> if i wasnt clear.
19:10:35 * jds2001 would urge the detractors to reconsider. This would be good press.
19:10:48 <sharkcz> ok, +1
19:11:09 <jds2001> one more???
19:11:51 <notting> jds2001: the good press is 'we support the same virt features in vmware and kvm', not 'we have a test suite'
19:12:13 <Kevin_Kofler> Right.
19:12:15 <jds2001> notting: right.
19:12:23 <Kevin_Kofler> I think advertising something users don't care about just to generate press is wrong.
19:12:32 <Kevin_Kofler> The press should be about things users care about.
19:12:34 <nirik> I think this is a very nice thing to have, I just don't think it's a feature. I think if we make it so, our users will yawn and look to the next thing.
19:12:42 <j-rod> Press gets more users.
19:12:55 <Kevin_Kofler> It's sad that journalists who don't understand a darn will write about stuff nobody cares about, do we really want to encourage it?
19:13:19 <Kevin_Kofler> This is a nice internal process improvement, but not a feature.
19:13:28 <jds2001> if the appropriate publications picked this up, people would care about it.
19:13:46 <notting> jds2001: to put it a different way, if we set up an automated kickstart test farm for F12 beta... is that a feature?
19:13:59 <cdub> j
19:14:01 <jds2001> it further advances our "we're hypervisor agnostic" line.
19:14:19 <jds2001> notting: of course not :)
19:14:21 <notting> jds2001: we aren't. we want you to use kvm :)
19:15:05 <jds2001> notting: of course, but libvirt is a hypervisor agnostic management layer
19:15:09 * Kevin_Kofler urges the people who voted +1 to reconsider. :-)
19:15:21 * notting urges the 3 people who haven't voted to show up
19:15:22 <nirik> so, we are already over here... punt until next week? just drop?
19:15:43 <jds2001> so that i can manage all of my kvm, legacy xen, vmware, $foo_new_hypervisor stuff
19:16:03 <jds2001> all from one spot
19:16:12 <jds2001> i think that management story is a great one to tell.
19:16:29 <nirik> thats not what this feature is though...
19:16:46 <nirik> that would be a LibVirt_IS_GREAT feature or the like. ;)
19:16:53 <jds2001> lol
19:17:18 <Kevin_Kofler> There's no way we can get a definite vote here.
19:17:18 <j-rod> ok, so I think this could be morphed into something more feature-y
19:17:32 <Kevin_Kofler> Ask the remaining people to vote in the ticket?
19:17:43 <nirik> or next wed if we are doing a special session.
19:17:54 <jds2001> yeah, lets defer this :)
19:18:32 <notting> that would be jwb and dgilmore?
19:18:49 <jds2001> yeah
19:19:12 <jds2001> i'll work out the time of the special session on the list, unless there's some burning desire to do it here.
19:19:26 * j-rod likes this debate and contested vote stuff... :)
19:19:43 <jds2001> j-rod: it's very healthy :)
19:21:28 <jds2001> anyhow
19:22:04 <skvidal> are we movingon?
19:22:08 <jds2001> #agreed VirtTCK featuere is deferred to special session.
19:22:22 <jds2001> #topic Open Floor
19:22:29 <jds2001> we're done, anyone got anything?
19:22:41 <notting> a strong desire to get back to work?
19:22:55 <jds2001> lol, same here :)
19:22:57 <skvidal> notting: :)
19:22:57 <nirik> I talked with ixs, he has flag info, but it's not in time for this week as he just moved... can address it at some later time.
19:23:07 <sharkcz> or to go for dinner :-)
19:23:09 <jds2001> sure thing
19:23:22 <Kevin_Kofler> Yeah, please defer the flags, we're out of time already!
19:23:35 <nirik> Kevin_Kofler: yes, I was saying we should defer as ixs is not ready this week. ;)
19:23:55 <jds2001> I'll send out something to the list asking for times for Wednesday
19:23:57 <nirik> (as well as us being way over time)
19:24:19 <jds2001> #endmeeting