FESCo meeting summary for 2009-07-24

[Jon Stanley]

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