Here is the summary and logs from today's FESCo meeting. Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-24/fedora-meeting.2009-07-24-16.59.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2009-07-24/fedora-meeting.2009-07-24-16.59.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-24/fedora-meeting.2009-07-24-16.59.log.html ---- 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
