18:00:24 <mjg59> #startmeeting FESCO (2012-02-06)
18:00:24 <zodbot> Meeting started Mon Feb  6 18:00:24 2012 UTC.  The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:24 <mjg59> #meetingname fesco
18:00:25 <mjg59> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
18:00:25 <mjg59> #topic init process
18:00:25 <zodbot> The meeting name has been set to 'fesco'
18:00:25 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
18:00:33 <t8m> Hello
18:00:43 <mmaslano> hi
18:00:46 <limburgher> hey
18:00:51 <pjones> hello.
18:00:56 * nirik waves
18:01:00 <twoerner> hi
18:01:20 <mitr> Hello
18:01:33 <mjg59> sgallagh:yo
18:01:38 <MarkDude> \o
18:01:43 <sgallagh> present, sorry I'm late
18:01:46 <mjg59> Let's wait a couple of minutes to see if notting turns up
18:01:48 <mjg59> sgallagh: No problem
18:02:02 * notting is here
18:02:11 <mjg59> Great, that's everyone
18:02:12 <mjg59> Ok
18:02:21 <mjg59> #topic #690 F17 Feature: move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove
18:02:24 <mjg59> .fesco 690
18:02:26 <zodbot> mjg59: #690 (F17 Feature: move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove) – FESCo - https://fedorahosted.org/fesco/ticket/690
18:02:41 <mjg59> Judging by the ticket, it seems that this got sorted to everyone's satisfaction?
18:03:04 <limburgher> I haven't tested personally, but there's at least a path.
18:03:12 <mjg59> nirik: Do we have a complete compose for rawhide now?
18:03:16 <nirik> yep.
18:03:17 <notting> it got sorted. given it's fedora, i can't imagine that everyone is satisfied
18:03:18 <nirik> it's landed.
18:03:30 <mjg59> Ok
18:04:03 <mjg59> It doesn't look like we're being asked to do anything else here, so I guess we can close this again?
18:04:11 <t8m> notting, +1 :)
18:04:18 <pjones> appears so
18:04:18 <sgallagh> +1
18:04:21 <nirik> yeah, close. +1
18:04:33 <mjg59> Anyone any objections?
18:04:52 <notting> mjg59: sure, close it
18:05:04 <t8m> no, although I still think that merging this one day before alpha freeze was very unfortunate
18:05:07 <mjg59> #agreed close it out again
18:05:21 <mjg59> And thanks to everyone who worked through the problems on this
18:05:26 <nirik> well, it landed friday, but yeah
18:05:33 <mjg59> #topic #756 F17 Feature: English Typing Booster - https://fedoraproject.org/wiki/Features/english-typing-booster
18:05:37 <mjg59> .fesco 756
18:05:38 <zodbot> mjg59: #756 (F17 Feature: English Typing Booster - https://fedoraproject.org/wiki/Features/english-typing-booster) – FESCo - https://fedorahosted.org/fesco/ticket/756
18:05:42 <limburgher> Yeah, and I'd rather the announcement have been more widespead, but the cat's already out of the barn doors.
18:05:49 <mjg59> Looks like there's no legal problem here
18:05:55 <mjg59> So I guess we can accept this
18:06:01 <t8m> +1 to accept
18:06:01 <mjg59> Votes?
18:06:03 <mmaslano> I think so, +1
18:06:04 <mjg59> +1
18:06:06 <mitr> +1
18:06:06 <nirik> +1, sure
18:06:07 <notting> +1
18:06:15 <pjones> +1
18:06:18 <sgallagh> +1
18:06:20 <limburgher> +1
18:06:29 <mjg59> #agreed feature is accepted
18:06:51 <mjg59> Ok, so anyone mind if I go out of order and take 797 (firewalld) before 796 (network zones)?
18:07:05 <sgallagh> Go ahad
18:07:07 <sgallagh> *ahead
18:07:12 <mitr> please do
18:07:13 <mjg59> #topic #797 F17 Feature: firewall-d - default firewall solution -- https://fedoraproject.org/wiki/Features/firewalld-default
18:07:16 <mjg59> .fesco 797
18:07:17 <zodbot> mjg59: #797 (F17 Feature: firewall-d - default firewall solution -- https://fedoraproject.org/wiki/Features/firewalld-default) – FESCo - https://fedorahosted.org/fesco/ticket/797
18:07:38 <mjg59> twoerner: This one's your baby?
18:07:50 <twoerner> mjg59: yes
18:08:26 <mjg59> mitr: Did the ticket update answer your questions?
18:09:11 <mitr> mjg59: yes (comment 3), along with the feature page update to say "An explicit transition is planned after Fedora 18 with dropping support for the static firewall with system-config-firewal/lokkit. A migration from the static firewall model will be needed then. "
18:09:49 <mjg59> twoerner: One question I had - you mention a shell extension. Is that something you've discussed with the desktop people?
18:10:09 <limburgher> and is the extension mandatory?
18:10:22 <limburgher> Thinking about X-less machines.
18:10:30 <twoerner> mjg59: the extension is only needed if you want to use the applet
18:10:54 <twoerner> the applet is optional for this version
18:11:02 <mjg59> twoerner: And the feature is still functional in the absence of the applet, right?
18:11:05 <mjg59> Ok, cool
18:11:09 <mjg59> Anyone else have anything?
18:11:10 <twoerner> but we need a way to ask the user for the default one in the furture
18:11:20 <twoerner> s/default/default zone
18:11:37 <mjg59> twoerner: That's something you're going to have to work through with dcbw and the desktop team, I guess
18:11:40 <mmaslano> twoerner: when it will be in C? :)
18:11:59 <twoerner> yes, will work out with the desktop people
18:12:00 <drago01> twoerner: does it have support for stuff like port forwarding? or is iptables supposed to be used for this
18:12:11 <twoerner> mmaslano: as soon as I have time and some help
18:12:42 <twoerner> drago01: you can do most things you could do with s-c-fw
18:12:55 <drago01> twoerner: ok
18:13:07 <twoerner> but the custom files are not supported anymore - you have to use the "direct" interface now
18:13:20 * nirik is +1. will require some adjustments, but then change always does.
18:13:22 <mjg59> Ok, so we'll take a vote?
18:13:27 <mjg59> +1
18:13:31 <pjones> yeah, +1
18:13:44 <mitr> +1
18:13:53 <sgallagh> +1
18:14:00 <mmaslano> +1
18:14:05 <notting> +1
18:14:07 <limburgher> +1
18:14:48 <mjg59> #agreed feature is accepted
18:14:50 <mjg59> Ok
18:14:59 <mjg59> #topic #796 F17 Feature: Network Zones - https://fedoraproject.org/wiki/Features/network-zones
18:15:02 <mjg59> .fesco 796
18:15:04 <zodbot> mjg59: #796 (F17 Feature: Network Zones - https://fedoraproject.org/wiki/Features/network-zones) – FESCo - https://fedorahosted.org/fesco/ticket/796
18:15:11 <mitr> twoerner: Please make sure the release note announces the post-F18 deprecation
18:15:27 <twoerner> ok
18:15:33 <mjg59> Anyone have anything to say on this?
18:16:00 <mjg59> Or should we just vote?
18:16:01 <nirik> twoerner: can you make your own zones? ;)
18:16:03 <sgallagh> Sounds like a good idea to me
18:16:11 <mjg59> Yeah, I'm +1
18:16:23 <pjones> I'm +1 as well.
18:16:25 <sgallagh> +1
18:16:26 <twoerner> nirik: this is on the TODO list for F-18 altogether with user policies
18:16:31 <nirik> twoerner: cool.
18:16:34 <nirik> +1
18:16:36 <notting> +1
18:16:43 <mitr> +1
18:16:46 <mmaslano> +1
18:16:47 <limburgher> +1
18:16:52 <t8m> I'm curious if it will be more useful than the zones in windows but +1 anwyay
18:17:09 <sgallagh> t8m: That's a pretty low bar. I might trip over it.
18:17:20 <t8m> I hope so
18:17:27 <mjg59> #agreed feature accepted
18:17:34 <mjg59> Ok, something slightly more controversial
18:17:37 <mjg59> #topic #704 F17 Feature: BTRFS default file system https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs
18:17:41 <mjg59> .fesco 704
18:17:42 <twoerner> t8m: NetworkManager stores the zones for connections
18:17:42 <zodbot> mjg59: #704 (F17 Feature: BTRFS default file system https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs) – FESCo - https://fedorahosted.org/fesco/ticket/704
18:17:52 <mjg59> josef: You here?
18:17:54 <josef> yup
18:17:57 <twoerner> thanks, guys
18:18:07 <mjg59> josef: So really definitely actually btrfsck?
18:18:16 <josef> yup he's doing all the cherry picking now
18:18:21 <josef> says it will be ready tomorrow morning
18:18:21 <mitr> Is anaconda able to handle this right now?
18:18:30 <josef> anaconda has all the kickstart stuff and it works for hte auto partitioning
18:18:47 <josef> but heres the gotcha, you wont get any fancy stuff if you do a custom partiotn setup
18:18:53 * nirik would prefer to land in f18.
18:19:11 <josef> i dont think thats a huge deal since i wasnt planning on anaconda being able to do anything fancy at first anyway
18:19:17 <limburgher> fancy such as. . . ?
18:19:25 <josef> subvols, raid, compression etc
18:19:36 <notting> how often are we discovering any new data-eaters?
18:19:40 <pjones> yeah, we're looking at very basic support right now
18:19:50 <josef> notting: no big dataeaters since the last one
18:19:53 <drago01> what about the "omg it kills vms" bug?
18:19:53 <mjg59> josef: And we're now stable and don't have any known critical crash-my-system-and-eat-my-data issues?
18:20:02 <notting> josef: the last one?
18:20:07 <limburgher> josef: :)
18:20:15 <limburgher> josef: That's always true. :)
18:20:19 <josef> so we had a problem with our barrier code so if you crashed the box at the right second you'd lose stuff
18:20:30 <josef> but we built this nice cool tool to verify stuff
18:20:31 <pjones> limburgher: always except once, anyway ;)
18:20:37 <josef> so we're pretty confident its all ok now
18:20:48 <limburgher> pjones: Fair. :)
18:20:54 <josef> if worse comes to worse i have this really cool restore tool that will pick up the peices and get all of your data back :)
18:21:13 <limburgher> josef:  So you keep the baby pictures on it currently then? :)
18:21:15 <josef> but we spent a lot of time verifying that we were doing everything right with our barriers to make sure we dont have this problem
18:21:20 <josef> i do
18:21:34 <josef> all my boxes (exception for my devel box of course) are btrfs
18:21:44 <josef> same goes for chris
18:21:49 <josef> been that way for years
18:22:04 <mjg59> josef: Ok, so you're good with people coming to your house and setting you on fire if this all goes awfully wrong?
18:22:13 <sgallagh> Just as a notable data point: I've been running with a btrfs filesystem since F16 beta. I can vouch for its stability in an assortment of workloads.
18:22:14 <josef> yup
18:22:20 <mjg59> Ok, good enough for me
18:22:28 <pjones> sgallagh: not really a useful datapoint, no.
18:22:34 * nirik had a corrupted btrfs install, but josef worked hard to get my data back, and I did.
18:23:01 <josef> worse comes to worse its pretty easy to make anaconda go back to what we had (afaik)
18:23:13 <notting> sure, but the josef-get-your-data-back service doesn't scale
18:23:17 <nirik> I'd still prefer to land in f18 (land right after branch) and give time to have the cool features and test out things much better.
18:23:31 <mmaslano> nirik: me too
18:23:41 <mjg59> pjones: Switching the default back is achievable?
18:23:44 <limburgher> nirik: nods
18:24:06 <josef> yes waiting till f18 gives us a nicer looking release with more complete anaconda support
18:24:12 <pjones> mjg59: no reason it wouldn't be.
18:24:19 <mitr> mjg59: for new installs anyway
18:24:21 <mjg59> josef: How valuable would the testing in F17 be?
18:24:22 <sgallagh> josef: Sounds like you're arguing to defer
18:24:25 <nirik> josef: what about live media?
18:24:45 <pjones> sgallagh: no, not defer - split between minor and major feature sets.
18:24:55 <josef> mjg59: i think very valuable, we're getting to the point where it's mostly stable for us, we need users to break it in new and interesting ways ;)
18:25:04 <drago01> are we planning to do btrfs convert on upgrades?
18:25:06 <josef> nirik: i havent done anything for live media
18:25:07 <notting> that sounds like an excellent opt-in feature :)
18:25:08 <sgallagh> pjones: Ah, ship all the features but not flip the "default" switch?
18:25:10 <drago01> or new installs only?
18:25:20 <josef> new installs only
18:25:27 <drago01> ok
18:25:36 <josef> afaik live media will probably have to stay on ext whatever
18:25:39 <josef> for now
18:25:41 <pjones> sgallagh: btrfs tools support more complex options that anaconda simply won't be using at this time.
18:25:47 <sgallagh> ok
18:26:05 <notting> "need users to break it in new and interesting ways" screams like a bad idea for people's data. now, if we had some large scale *system* installations where we could swap 25% of them for btrfs and test the results, sure
18:26:11 <sgallagh> Sorry, my knowledge level on btrfs is limited to "it's the Next Big Thing we should all be testing".
18:26:35 <mjg59> Do we still have time to make the change pre-Alpha?
18:26:46 <sgallagh> mjg59: Oh, HOURS at least :)
18:26:53 <notting> freeze is tomorrow, so, sure!
18:26:57 <mjg59> Ok, so
18:26:59 <sgallagh> notting: Not quite
18:27:25 <pjones> that's a question for dlehman I guess.
18:27:26 <sgallagh> notting: According to dgilmore: "plan on landing today. tomorrow is too late"
18:27:41 <mjg59> Proposal: Switch to btrfs by default for alpha. Revert if it's overly bumpy.
18:27:46 <pjones> mjg59: +1
18:27:53 * notting points dgilmore at rbergeron to get everyone on the same page w.r.t. communications
18:28:20 <mmaslano> -1 fsck is here for only a while. I'd rather see it in F-18
18:28:22 <mitr> Was the VM question answered yet?
18:28:27 <josef> so what do i do if i dont get the package built before the branch, just pull the f17 branch and update it?
18:28:31 <sgallagh> Yeah, the source of this was me asking rbergeron for clarification and getting dgilmore's answer of "tonight"
18:29:03 <mjg59> I'm +1
18:29:15 <mjg59> Any other votes?
18:29:21 <limburgher> I'm on the fence.
18:29:21 <sgallagh> I'm also -1 for F17. I think we're a bit too close to the line here.
18:29:22 <notting> i'm -1
18:29:23 * nirik ponders
18:30:06 <mitr> josef: KVM performance?
18:30:07 <notting> it would be interesting if we could enforce separation where it would be the default for system partitions but not data partitions
18:30:17 <nirik> yeah, -1 I guess. I'd like to see us use it all around with nice features and also have some time to see that fsck is working well in the wild.
18:30:24 <t8m> I'm +0 I think btrfs might be ready for general consumption now however without the full support in anaconda, does it make really sense to switch?
18:30:26 <josef> mitr: been something i'm working on, we're getting better but not quite to ext* speed yet
18:30:29 <mjg59> +2/-4 at present, then
18:30:53 <pjones> t8m: honestly from the anaconda POV, we'd rather have a release with the basic support so we can isolate bugs from it vs our big UI redesign.
18:30:53 <mjg59> And with a +0 it's not going to reach +5
18:30:55 <mitr> I'm +1 to the idea, but I think this really needs to land (including the anaconda default flip) for Alpha - is that manageable?
18:31:10 <pjones> the anaconda default flip is not a big change.
18:31:29 <t8m> pjones, ok that's good idea
18:31:34 <sgallagh> mitr: I don't think we can allow this to land post-alpha. Alpha is supposed to be feature-complete and testable
18:31:46 <t8m> ok changing my vote to +1 if it lands pre-alpha
18:31:48 <sgallagh> If it lands post-alpha, it won't be installable until beta, which isn't enough time for testing
18:31:59 <mjg59> +3/-4
18:32:14 <mitr> sgallagh: right
18:32:20 <mjg59> Just waiting for nirik and limburgher I think?
18:32:25 <limburgher> I think so.
18:32:42 <mitr> mjg59: I count +4
18:32:43 <nirik> I was -1
18:32:52 <limburgher> Reluctant +1 if pre-alpha.
18:33:20 <mjg59> Oh, yeah
18:33:21 <mjg59> Ok
18:33:26 <mjg59> So that makes +5/-4
18:33:38 <drago01> so we basically would end up with two different default file systems depending on install method / media?
18:33:43 <drago01> doesn't sound right to me
18:33:44 <mjg59> Which I guess means we're going to give this a go?
18:33:50 <pjones> I _think_ the anaconda change is roughly http://fpaste.org/p9zw/
18:33:53 <nirik> drago01: yeah, it would.
18:33:59 <sgallagh> That vote is still a little skewed
18:34:11 <sgallagh> Some were unqualified +1, others only pre-Alpha
18:34:21 <mjg59> sgallagh: I think the assumption is pre-Alpha, yes
18:34:23 <sgallagh> Do we assume that makes the whole vote "yes, if pre-Alpha"?
18:34:24 <pjones> I think pre-alpha is the working assumption there
18:34:25 <josef> and pre-alpha means today right?
18:34:29 <sgallagh> (Just wanted to clarify)
18:34:29 <pjones> josef: right
18:34:31 <nirik> yeah, asap
18:34:32 <sgallagh> josef: Yes
18:34:34 <mjg59> Ok
18:34:42 <josef> ok so if i miss that i'm screwed?
18:34:50 <pjones> only for six months!
18:34:52 <josef> haha
18:34:52 <mjg59> #agreed We'll try btrfs by default as long as it lands in alpha - if not, push to F18
18:34:56 <josef> ok
18:34:59 <sgallagh> If you miss that, we have to decide whether we want this badly enough to slip for it.
18:35:07 <josef> i'll go poke chris with something sharp
18:35:17 <mjg59> josef: Ok, so work with rel-eng and anaconda to get this happening
18:35:21 <sgallagh> josef: Not too hard. If you kill him, he won't be much help.
18:35:32 <mjg59> Right
18:35:35 <mjg59> #topic #798 ibus makes Ctrl+Space a global shortcut
18:35:35 <mjg59> .fesco 798
18:35:38 <zodbot> mjg59: #798 (ibus makes Ctrl+Space a global shortcut) – FESCo - https://fedorahosted.org/fesco/ticket/798
18:35:40 <josef> great thanks guys
18:35:48 <nirik> thanks for all the hard work josef
18:35:57 <sgallagh> josef: Good luck!
18:36:02 <mjg59> Issue here is that ibus grabs ctrl+space, and some applications use it
18:36:09 <mmaslano> not sure what we have to say about this one. If it's there since FC-2..
18:36:09 <josef> thanks :)
18:36:31 <nirik> yeah, seems like this has been the case for a long time.
18:36:31 <sgallagh> mmaslano: I think maybe the order of operations swapped. It's still a little unclear.
18:36:42 <mmaslano> sgallagh: it seems so
18:36:43 <t8m> mmaslano, but ibus was not on by default for everyone installing gnome
18:36:44 <sgallagh> It sounds to me like previously, applications would win the race
18:36:50 * drago01 wonders why this isn't just a bug ticket
18:36:52 <mitr> I have honestly never noticed because I uninstall ibus soon enough.
18:36:52 <sgallagh> But now ibus overrides it
18:36:58 <mjg59> Yeah there's ongoing discussion in the bug
18:37:06 <sgallagh> drago01: Because the maintainer and reporter can't agree
18:37:16 <drago01> sgallagh: ah missed that part
18:37:16 <mjg59> So I'd be inclined to just punt this until it's clear there's no resolution there
18:37:19 <pjones> I propose deferring for more discussion outside of the meeting.
18:37:29 <mjg59> +1
18:37:49 <mitr> I guess the right behavior here depends on user's locale - that satisfies everyone's expectations.
18:38:05 <pjones> mitr: I didn't realize emacs was a locale, but okay, I can see it ;)
18:38:18 <nirik> I'd be ok with defering, but In that case I think we should appoint someone to mediate or at least gather more info...
18:38:25 <t8m> I think the main reason why it wasn't noticed before is that everyone who doesn't use ibus remove it and everyone who uses it does not use eclipse or emacs or whatever...
18:38:33 <nirik> EMACS.UTF8
18:38:36 <mmaslano> +1 to defer
18:38:39 <sgallagh> I can't help but wonder whether ibus should be a prominent option in anaconda
18:38:57 <sgallagh> i.e. if you're sure you only care about en_us, don't bother installing ibus
18:39:04 <mitr> pjones: :p  Ctrl-space is, I think, widespread enough (Windows as well)  that CJK users are used to using something else in  ermacs and similar applications.
18:39:15 <pjones> please never suggest adding UI to anaconda again.
18:39:25 <mitr> sgallagh: This is a per-user thing, not per-system
18:39:45 <t8m> mitr, the problem is that it is even not per-locale thing
18:40:30 <mitr> t8m: it's configurable at both sides I think, the question is what the default should be
18:40:43 <sgallagh> pjones: Fair enough :)
18:41:06 <mjg59> Anyone have any other opinions?
18:41:08 <t8m> is this shortcut configurable in ibus?
18:41:16 <notting> mitr: it breaks the deadlock by uninstalling emacs on ctrl-space
18:41:33 <pjones> *snort*
18:41:45 <nirik> I don't think there's a good answer here... control-space is used by several things...
18:41:56 <limburgher> nirik: nods
18:42:06 <t8m> ok I see it is configurable
18:42:14 <notting> only somewhat sarcastic - is there an actual keyboard shortcut that *won't* conflict with emacs in some way?
18:42:26 <sgallagh> Given that we are a vast collection of tools, I think I'd rather see ibus change its behavior
18:42:41 <mitr> notting: The report was motivated by eclipse
18:42:42 <sgallagh> emacs aside, there are other apps that have issue with ctrl-space
18:42:49 <sgallagh> Yeah, eclipse being one
18:43:01 <mitr> sgallagh: This is not an ibus-specific thing - http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/langbar_keystroke_shortcuts.mspx?mfr=true
18:43:40 <sgallagh> Ok, let me rephrase.
18:43:59 <sgallagh> We have any number of apps that may be in conflict, but only one of the packages in question is installed everywhere
18:44:04 <sgallagh> ergo, it is the easiest to change
18:44:22 <pjones> honestly given that it's configurable and a relatively common thing and it took a very long time to notice, I'm inclined towards "leave it be", but I think we should allow the stakeholders some time to sort it out with that in mind.
18:44:35 <limburgher> Plus, eclipse and emacs are not breaking each other.
18:44:42 <mitr> Has anyone researched what has exactly changed in F16?
18:44:42 * mitr admits he hasn't
18:44:47 <mjg59> I don't think any of us currently understand the issue sufficiently well to make any useful conclusions
18:44:52 <pjones> mitr: no.
18:44:58 <sgallagh> limburgher: The issue is that eclipse and emacs don't run concurrently
18:44:58 <notting> mjg59: given that: Proposal: defer and collect more info
18:45:01 <sgallagh> Only one has focus
18:45:12 <t8m> As long as this shortcut is _easily_ configurable in ibus, I don't see the real problem here. Also it's questionable whether ibus should be forced on everyone even users who never need it.
18:45:17 <mjg59> Does anyone object to deferring?
18:45:19 <sgallagh> But ibus ALWAYS has "focus" as a part of the overall desktop environment
18:45:20 <pjones> notting: +1, again.
18:45:30 <mitr> +1 to deferring
18:45:43 <limburgher> sgallagh: missed that completely.
18:45:43 <sgallagh> -1, I'd rather we just solved this and got it off our plate
18:45:49 <t8m> +1 to defer
18:46:01 <mmaslano> +1 defer
18:46:04 <mjg59> Ok
18:46:11 <mjg59> #agreed defer to next week, gather more information
18:46:12 <nirik> I'm fine again with defer, but we should make sure someone actually gathers info.
18:46:19 <nirik> not just hope new info appears.
18:46:23 <mjg59> Anyone want to volunteer to do that?
18:46:47 * mitr can try that
18:46:52 <mjg59> mitr: That'd be great, thanks
18:47:03 <mjg59> Ok
18:47:10 <mjg59> #topic Next week's chair
18:47:28 <sgallagh> I haven't chaired in a while, so if no one else is dying to do it, I'm your man
18:47:46 <mjg59> sgallagh: Sounds good to me
18:47:51 <mjg59> #agreed sgallagh to chair next meeting
18:47:56 <mjg59> Right then
18:47:57 <mjg59> #topic Open Floor
18:48:01 <mjg59> Anyone have anything?
18:48:09 <sgallagh> Yes, I have two items
18:48:24 <sgallagh> First, there was a reduction in scope on the FreeIPAv3 feature
18:48:42 <sgallagh> The kerberos cross-realm trust work isn't going to make F17. But the two other sub-tasks of that Feature will.
18:48:57 <sgallagh> (Also it won't be called v3 but 2.2 instead)
18:49:22 <sgallagh> I don't *think* there are any additional steps to take here other than updating the Feature page, but please correct me if I'm mistaken.
18:49:56 <limburgher> I don't think so.
18:50:04 <nirik> yeah, update feature page with new scope and completely
18:50:07 <mmaslano> only update of feature page
18:50:07 <nirik> completion.
18:50:13 <sgallagh> ok, thanks
18:51:11 <mjg59> sgallagh: Ok, item two?
18:51:41 <sgallagh> Actually, scratch item 2. I was going to ask for permission to late-add a completed feature, but I just got notified that one of the pieces isn't going to be ready today after all
18:52:00 <limburgher> Well that's easy then.
18:52:00 <mjg59> Ok
18:52:10 <nirik> I had one quick item I wanted to bring up...
18:52:13 <mjg59> nirik: Go for it
18:52:16 <sgallagh> The short version is that we modified kerberos to store kerberos credential caches safely in /run/user/<username> instead of /tmp, thereby avoiding any number of security issues.
18:52:27 <sgallagh> But it looks like rpc.gssd didn't do their piece in time
18:52:53 <nirik> There was a suggestion on the list that we change the update requirement from (now): 2 +1's from any logged in user, to 1 +1 from a proventester.
18:53:15 <nirik> I don't like the idea myself, but thought I would suggest it and see how fesco feels about it.
18:53:21 <mitr> nirik: that is change as in "add an alternative", not "replace", right?
18:53:46 <nirik> yeah, that was 'or' I guess.
18:53:54 <sgallagh> Heh, why not just make proventesters' votes count double :)
18:54:16 <sgallagh> I think that's basically free license to game the update system, frankly
18:54:24 <pjones> I'm not big on that, no.
18:54:24 <mjg59> I'd like to see some evidence that proventester karma is reliably better than other logged in users
18:54:43 <sgallagh> mjg59: I don't think that will ever be anything but a qualitative assessment
18:54:48 <drago01> mjg59: didn't your data from a while ago show that this is *not* the case?
18:54:52 <limburgher> Yeah, I'd say leave as is.
18:54:57 <nirik> ok, so sounds like this doesn't have enough energy to pass...
18:55:04 <nirik> just thought I would bring it up. ;) thanks.
18:55:07 <mjg59> drago01: I found it didn't make any difference in terms of changing the fate of critpath packages, which isn't quite the same thing
18:55:26 <drago01> mjg59: ok
18:55:29 <mjg59> sgallagh: No, we do actually have the means to do that quantitatively
18:55:50 <sgallagh> mjg59: How do you determine "better"?
18:55:59 <pjones> fewer quantifiable errors.
18:56:19 <mitr> I'm not too enthusiastic either... In general I think ideally, each package would have a "devel owner" and an (optional) "QE owner" instead of this "I can test everything" model
18:56:21 <mjg59> sgallagh: More reliably tied to packages that got through bodhi
18:56:53 <pjones> mitr: I really do agree with that statement in general.
18:56:55 <sgallagh> mjg59: To me it would be more useful to study the number of Regression bugs that crept up from updates that passed due to karma
18:57:39 <sgallagh> mitr: And only the QE owner could approve things if one was specified?
18:58:09 <sgallagh> Interesting, except that it wouldn't help finding major issues in applications that have widely-varied uses (like Firefox and GNOME for example)
18:58:25 <mitr> sgallagh: I suppose a proventester/sig model could work for QE just as well as for devel - for me the important part is that QE process doesn't hold up packages for which noone has signed up to do QE
18:58:45 <mitr> Also, this would motivate much closer cooperation between devel and QE
18:59:01 <sgallagh> mitr: It's an interesting idea. Would you be willing to write up a proposal to devel@ to discuss it?
18:59:16 * nirik thinks that would be lovely in an ideal world, but I don';t think we have enough people interested in that currently.
18:59:18 <mitr> sgallagh: It's buried somewhere on my long-term todo list :)
18:59:35 <sgallagh> As I understand it, lmacken is currently scoping Bodhi 2.0, so now would be a good time to bring up such major changes
19:00:01 <pjones> nirik: still, there's middle ground.  we could try to encourage people doing QE to focus on specific packages and develop a relationship with their maintainers.
19:00:03 <sgallagh> nirik: If nothing else, it would help facilitate getting RHT-driven projects through the updates process.
19:00:24 <nirik> sure, we could try...
19:00:58 <pjones> sgallagh: not really a priority - if that's a real problem, we at Red Hat should be letting our managers know that they need to focus resources on Fedora QE for our internal projects.
19:01:47 <sgallagh> pjones: fair enough
19:03:56 * nirik has nothing else for open floor
19:04:18 <limburgher> Me neither,.
19:04:30 <mjg59> Ok
19:04:37 <mjg59> #endmeeting