17:06:14 #startmeeting F22-blocker-review 17:06:14 Meeting started Mon Feb 2 17:06:14 2015 UTC. The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:06:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:06:14 #meetingname F22-blocker-review 17:06:14 The meeting name has been set to 'f22-blocker-review' 17:06:15 #topic Roll Call 17:06:15 * danofsatx taps his foot 17:06:23 who's still around? 17:06:27 me! 17:06:33 here, have a chair 17:06:37 #chair danofsatx 17:06:37 Current chairs: danofsatx roshi 17:06:40 pero necesito mas cafe 17:07:05 * pschindl is here 17:07:11 just a sec while I go find a cup (read: pitcher) 17:07:11 * kparal here 17:07:15 you too win a chair! 17:07:22 #chair pschindl kparal 17:07:22 Current chairs: danofsatx kparal pschindl roshi 17:08:56 alright, onto the boiler plate :) 17:09:07 #topic Introduction 17:09:08 Why are we here? 17:09:08 #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. 17:09:12 #info We'll be following the process outlined at: 17:09:14 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 17:09:17 #info The bugs up for review today are available at: 17:09:19 #link http://qa.fedoraproject.org/blockerbugs/current 17:09:22 #info The criteria for release blocking bugs can be found at: 17:09:24 #link https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria 17:09:27 #link https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria 17:09:30 #link https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria 17:09:43 we've got 1 proposed Alpha and 1 proposed Beta 17:09:49 #topic (1185999) [Gtk3] Text on various bits of chrome (tab titles, menus, buttons...) is white with GTK+ 3.15.4 17:09:52 #link https://bugzilla.redhat.com/show_bug.cgi?id=1185999 17:09:53 * adamw brb, call of nature 17:09:55 #info Proposed Blocker, gtk3, NEW 17:10:06 best to heed it's call.... 17:10:08 this is borderline blocker for me, i've been living with it here for the last week or so, but it is pretty annoying 17:11:14 ok, coffee is brewing. We're on proposed #1? I'm not sure...does it actually prevent the use of the browser, or just make it unwieldy? 17:11:16 * nirik agrees with anoying 17:11:25 I think it is more FE. I use it every day with this. It is really annoying, but it can be used. 17:11:26 just makes it very hard to read things. 17:12:08 pschindl: FE for what release? 17:12:16 are we OK releasing Final like this? 17:12:31 I don't think it violates the criterion 17:12:46 I'm not ok, but I don't think it should block release. 17:12:46 I think it violates the polish criteria, but not usability. 17:12:55 kparal: for final, I might want this under the catch-all "polish" criterion 17:13:24 can you use the browser when you can't read some of its UI? 17:13:44 imho it violates the criteria 17:13:47 well, I use the keyboard - so the visual of the UI doesn't affect me much 17:13:59 kparal: Yes I can and I do :) 17:14:04 but then again, I haven't seen it, either 17:14:16 mouseover changes the background so you can see the titles, 17:14:16 we've got a couple people who are still using it 17:14:20 could somebody upload some screenshots to the bug report? 17:14:44 roshi: we're talking about the average joe here 17:14:54 But if there is some polish criteria then it should block 17:15:02 the most annoying thing for me is the right-click menu 17:15:09 kparal: it's hard to take screenshots of menus :/ 17:15:16 how do you download a file, if not right click? 17:15:22 adamw: it's not, set up a delay 17:15:29 oh, yeah, always forget that 17:15:37 or a video 17:15:39 so on the right click menu you can only read the entry that's currently highlighted 17:15:39 I can send some, but not today. 17:15:42 ctrl+alt+shift+r 17:15:46 so you have to wash down it to read each entry one at a time 17:16:12 I'm definitely +1 Final. you can talk me out of the other milestones 17:16:14 hrm 17:16:27 +1 Final - under polish 17:16:39 ^^ what he said. 17:16:41 when you say 'polish', to what exactly are you referring? 17:16:41 does it do the same thing under kde? 17:16:51 roshi: i don't know if anyone's tried, yet. 17:16:53 the criteria that should not be named 17:16:59 :D 17:17:05 I thought there was an entry in the bug that said it did 17:17:49 we talked about this in the past, but don't know if it got properly codified 17:18:09 comment #11 17:18:34 about having a polish criteria, for catching stuff like this - where it still technically *works*, but is ugly or we wouldn't want to ship with it 17:18:47 despite it not actually *violating* a criteria 17:19:18 I think very few of our users would describe it as "technically works" 17:19:41 I think they would use other expressions 17:20:16 we have some criteria that can be described as 'polish criteria', but none of them is really related to this. 17:20:18 I'd use the proposed criterion, just postpone it for a later milestone because it's not that a critical problem 17:20:50 i'd just say it's a conditional violation of the 'browser has to work' criterion and we say it's serious enough to block whichever milestone we want to block. 17:21:08 i'd be fine with beta blocking, probably, i just think for alpha it's liveable-with / workaroundable. 17:21:13 wfm 17:21:24 I was just going off of: "The web browser must be able to download files, load extensions (if applicable), and log into FAS" 17:21:31 (i think you can mess with gtk+ themes or something to avoid it, probably, i was just hoping it'd get fixed before i have to bother.) 17:21:36 yeah, that one. 17:21:48 if all that works, it's a non-blocker in my head 17:22:02 hard to use != not working, IMO 17:22:20 otherwise emacs and vim wouldn't work, for a lot of people :p 17:22:20 roshi: +1 17:22:49 did someone have screenshots or a video to look at? 17:23:12 hard to use != works as expected 17:23:18 roshi: no, we're lazy. get a vm. :P 17:23:25 I have but on the computer which is 20 km far away right now :( 17:23:28 "as expected" is a moving target :p 17:23:43 lol 17:23:48 yeah, I currently expect to hit this bug, so yes - it works as expected 17:24:11 roshi: https://www.happyassassin.net/temp/firefox-white.webm 17:24:13 I won't be upset if I get outvoted - just doesn't seem like it actually violates the criteria to me 17:24:53 yeah, that looks annoying 17:25:03 thanks, btw :) 17:25:07 votes? 17:25:20 -1 (or -.5) 17:25:25 roshi: it's always difficult to absolutely nail down wording. i mean, frequently, it's *technically* possible to do the thing somehow or other. 17:25:43 i'm -1 alpha, +1 final, beta's a bit harder...probably +1 though. 17:25:46 can you get to all the places you need with keyboard shortcuts? 17:26:10 +1 beta or final 17:26:11 true, which is my .5 17:26:24 roshi: i dunno all the firefox keyboard shortcuts. 17:26:54 Ctrl-o, Ctrl-t, Ctrl-s 17:27:09 that's most of the ones you need, but this is a digression :p 17:27:32 none of those seems totally relevant to the things you might want to do, but yeah. 17:27:37 so, looks like +2 for final 17:27:51 any other votes ? 17:28:08 -1 17:28:37 * kparal pokes pschindl 17:29:39 I'm fine with +1 to final 17:29:47 I wouldn't want to ship with this, by any means 17:29:52 proposed #agreed - 1185999 - AcceptedBlocker Final - This bug is a conditional violation of the Alpha criterion, "t must be possible to run the default web browser and a terminal application from all release-blocking desktop environments..." but isn't deemed bad enough to block until a later Milestone as FF *technically* works. 17:30:03 I can vote +1 for final, if you want :) 17:30:15 ack, we can argue about beta if it's still broken then 17:30:16 patch 17:30:28 proposed #agreed - 1185999 - AcceptedBlocker Final - This bug is a conditional violation of the Alpha criterion, "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments..." but isn't deemed bad enough to block until a later Milestone as FF *technically* works. 17:30:40 s/"t/"It/ 17:30:46 ack 17:30:52 ack 17:31:11 #agreed - 1185999 - AcceptedBlocker Final - This bug is a conditional violation of the Alpha criterion, "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments..." but isn't deemed bad enough to block until a later Milestone as FF *technically* works. 17:31:38 onto the next? 17:32:03 yes 17:32:05 #topic (1187742) rebuild openldap with support for moznss 17:32:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=1187742 17:32:06 #info Proposed Blocker, openldap, NEW 17:32:29 who wants to pull secretary duty? 17:33:06 i gots it 17:33:08 based on sgallah's statement in the bug, I am +1 on the grounds that it breaks Server's primary deliverable. 17:33:09 (unless anyone else wants it) 17:33:27 this is proposed for what milestone? 17:33:27 the description is bit terse for me 17:33:31 beta 17:33:40 we should probably adjust blockerbugs to specify the milestone for each nomination... 17:34:29 I agree, the description doesn't give much. I was going to deploy a couple test instances to see WTF was going on. 17:34:41 it does, I just forgot to say we were moving to beta proposals 17:34:56 under this criterion: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements..." 17:35:20 yeah, a bit more detail on what it breaks would be good, but i'm ok with 'sgallagh says it's broken' really 17:35:20 that's a beta criterion? 17:35:35 heh....it is now ;) 17:35:44 danofsatx: i think that's one of the ones from f21 17:35:51 or is that one of my new proposals? 17:35:53 where am i? 17:35:55 where's my drink? 17:35:55 it is, kparal 17:36:06 adamw: why is your bottle empty? 17:36:09 http://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Roles 17:36:14 good lord, this is an emergency 17:36:40 alright, +1 beta 17:36:42 got white russians over here, if you're in need of an emergency infusion of vodka and cream :) 17:36:54 you could also cite one of the specific domain controller role requirements, but eh, i think that's fine for now 17:36:56 +1 from me 17:37:08 +1 beta but i'll ask for a bit more detail on what's broken so we can confirm and test 17:37:31 +1 17:37:49 proposed #agreed - 1187742 - AcceptedBlocker Beta - This bug is a clear violation of the Beta criterion: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements..." 17:38:03 ack 17:39:01 ack 17:39:03 ack 17:39:06 ack 17:39:35 #agreed - 1187742 - AcceptedBlocker Beta - This bug is a clear violation of the Beta criterion: "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements..." 17:39:43 that's it for proposed blockers 17:40:03 discussion time? 17:40:08 want to talk about tagging specific people as bug prodders with the QA-contact field? 17:40:14 sure 17:40:17 #topic Discussion Time 17:40:34 kparal: want to give us a tl;dr of the idea? 17:40:39 so, the idea is, every accepted blocker would get a single qa person assigned 17:40:56 the qa person would make sure the issue is getting resolved 17:41:13 first of all, it would inform the relevant developer that this bug was accepted as a blocker 17:41:16 I would also say the assigned person secretarializes their bug 17:41:29 very often, the developers/maintainers don't know it at all 17:41:44 e.g. gnome devs usually don't follow rh bugzilla 17:41:50 hum. it seems a bit inefficient 17:42:00 which does, adamw ? 17:42:10 kparal: i think that's overstated. at least some of the gnome folks do, and they know as a team when they have blockers. mclasen follows the blocker list 17:42:10 the idea of one-person-per-bug 17:42:21 it seems more efficient for one person to follow up on all blockers 17:42:41 I thought it would be better the distribute the load 17:42:56 I was thikning we'd split it up like this: we have a Gnome person, a KDE person, and anaconda person, etc etc 17:43:00 or several people for each 17:43:36 roshi: also possible 17:43:37 for instance, I'm going to make sure cloud bugs get handled by the cloud folks 17:43:50 what happens when we get a bug that keeps getting tossed back and forth, such as the GTK3 bug we just discussed? Is it a gnome bug, or a Firefox bug? 17:44:18 or upcoming bugs between anaconda and dnf-3 17:44:19 I'd say it stays with whoever had it first, since they have the history 17:44:29 well, for our purposes we'd just pick one person or the other to 'have' it from the blocker process PoV, it wouldn't matter too much 17:44:51 to finish the proposal, the qa person would make sure there are some updates in bugzilla. so we don't always end up with "on updates, will wait another week" during accepted blocker reviews. so he would ping devs to provide some updates, if there were none in bugzilla for e.g. a week or two 17:45:02 I think the idea was to have some way of knowing that the bug was going to get poked, and knowing who that person was 17:45:22 agreed, just playing devil's advocate 17:46:14 the current problem is that I somewhat assume that adamw or roshi pokes the devs, but I'm not sure, so I don't know whether I should do it or not. of course I can always ask first, but it doesn't seem to efficient, mainly due to timezone issues 17:46:24 i guess it just somehow 'feels' to me like something better for one person to do the whole lot - when i used to prioritize it it really wasn't *that* much work, an hour or two 17:46:50 i sort of feel like if we do one-person-per-bug everyone's going to spend 15 minutes on it and that's more person-hours 17:46:53 but it's only a feeling 17:47:10 also, practically speaking, what does the QA Contact field *do*? we've never used it for anything, have we? 17:47:17 I don't think so 17:47:25 it's unused at the moment, I believe 17:47:25 my plan this release was to do the poking - and I'm fine with keeping that idea 17:47:38 i'm already CCed on just about every blocker in existence, so i don't know how i'd conveniently check which blockers were 'mine' to follow up on. well, i suppose it'd be easy to throw together a custom search 17:47:41 and I can reach out if I need someone else to cover it 17:47:51 have you been doing it so far? 17:48:05 if by "doing it" you mean, "meaning to" :p 17:48:23 adamw: so are you volunteering to do all the poking, or do you prefer to split the work between a few people (I'm not saying many people, but a few)? 17:48:31 we talked about it, but I hadn't paid too much attention since we haven't branched yet 17:48:34 kparal: i was volunteering roshi. ;P 17:48:37 :D 17:48:44 * adamw is getting good at that 17:48:50 I'm fine with that, if you guys are 17:48:54 roshi: you know you're filling in my tax returns too, right? 17:48:59 I don't mind spot checks to make sure I did it 17:49:12 is the canadian tax system better than ours? Ours is a nightmare 17:49:31 shall we give roshi a chance to do it, and if it turns out not to work well we can consider the spread-the-load approaches? 17:49:42 that works for me 17:50:13 sure, why not, if roshi is ok with that 17:50:56 I had already planned on doing it - so it's fine with me 17:51:11 then we talked about this, and haven't really thought about it since 17:53:02 ok, agreed. roshi does all the work. deal 17:53:22 =) 17:53:25 where do I get my poking stick? 17:53:32 roshi: give us a yell if you start drowning and we'll reconsider 17:53:37 +1 17:53:50 I'll at least try to give a gurgle 17:53:53 :p 17:54:42 should we go over accepted blcokers, or hold off? 17:55:06 we've got 2/4/3 accepted in Alpha/Beta/Final so far 17:55:20 * roshi is fine with holding off on the review of those 17:55:27 i'm looking at the alpha ones 17:55:30 unless we just wanted to do alpha 17:55:32 the SELinux one just went to modified 17:55:50 the anaconda unicode one i actually wanted to post an update on, i tried to reproduce it last week but couldn't, even though i don't think it's been explicitly fixed 17:55:52 i'm just checking that again 17:56:16 sweet 17:57:23 so...i'm on it 17:58:59 so do we need any discussion on them? 17:59:11 * roshi is fine either way 18:00:12 * danofsatx is drinking coffee, doing homework. Fine either way. 18:01:19 don't think so 18:01:25 i've just asked nirik if he can try and find out why nightly composes keep failing lately 18:01:25 it'd be good to get a new nightly nominated and try to knock out some more of the tests 18:01:34 for sure 18:01:41 which is the last working one? 18:01:57 the current nominated nightly is about the latest we have a boot.iso for 18:02:02 we have much newer lives 18:02:13 we have a workstation live for today 18:03:27 #info Last working boot.iso is the currently nominated nightly. Live images have more recent images to test 18:04:21 if there's nothing else, I'll set the fuse 18:04:30 * roshi sets quantum fuse... 18:04:34 3... 18:04:36 it's just different broken deps breaking the ones that are broen 18:04:38 broken 18:06:09 jreznik just sent the email that python-3 is retargeted for F23. 18:06:21 good to know 18:06:28 and one less thing to test this release... 18:07:11 https://lists.fedoraproject.org/pipermail/devel-announce/2015-February/001530.html 18:07:46 2... 18:09:03 1... 18:09:41 there's up date to openldap blocker already ;) 18:09:47 the bug, anyhow, not the package 18:09:57 more details on what it breaks 18:10:01 updates are good 18:10:09 well, I'm going to close the meeting down 18:10:12 thanks for coming folks! 18:10:16 kerblooey 18:10:22 #endmeeting