16:07:09 #startmeeting F24-blocker-review 16:07:09 Meeting started Mon Apr 11 16:07:09 2016 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:07:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:07:09 The meeting name has been set to 'f24-blocker-review' 16:07:09 #meetingname F24-blocker-review 16:07:09 The meeting name has been set to 'f24-blocker-review' 16:07:09 #topic Roll Call 16:07:21 * danofsatx is here for 30 mins 16:07:31 make that 23 mins 16:07:32 alrighty, we'll try and move fast =) 16:07:34 who else do we have? 16:07:40 hard stop at the 30 minute past mark 16:08:02 * garretraziel is hereā€¦ more or less 16:09:19 I can be mostly here 16:09:28 where will the rest of you be? 16:09:53 alrighty, since we only have dan for 20 more minutes, i'm gonna start the ball rolling and see who shows up to vote 16:09:55 monut thieving obvi 16:10:09 #chair cmurf garretraziel 16:10:09 Current chairs: adamw cmurf garretraziel 16:10:16 #topic Introduction 16:10:16 Why are we here? 16:10:16 #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. 16:10:17 #info We'll be following the process outlined at: 16:10:18 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:10:20 #info The bugs up for review today are available at: 16:10:22 #link http://qa.fedoraproject.org/blockerbugs/current 16:10:24 #info The criteria for release blocking bugs can be found at: 16:10:26 cmurf: What the hell is a monut? 16:10:26 #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria 16:10:28 #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria 16:10:30 #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria 16:10:39 sgallagh: a cross between a madeleine and a donut 16:10:51 ... 16:10:51 sgallagh: otherwise known as a typo i made in bugzilla that we thought we'd make hay with =) 16:11:02 who wants to secretarialize? 16:11:12 sgallagh, not just any cross, FAMOUS 16:11:30 * kparal is here 16:11:34 * adamw looks around to see if kparal and pschindl are hiding behind the furniture 16:11:41 damn, I returned too early 16:11:47 congratulations, Secretary Kparal 16:11:51 #info kparal will secretarialize 16:11:51 pschindl: wake up, and save me! 16:11:56 too late! 16:12:04 * kparal bursts into tears 16:12:16 * pschindl is here. I fell asleep for a while :) 16:12:20 starting with proposed beta blockers: 16:12:23 pschindl: nice timing ;) 16:12:23 /me collects the tears in a jar for later sale 16:12:26 you can fight it out yourselves 16:12:29 #topic (1321393) blivet.errors.DeviceTreeError: no slaves found for device md127 16:12:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1321393 16:12:29 #info Proposed Blocker, python-blivet, ASSIGNED 16:12:36 this is the only proposed beta blocker; it's one we punted on for more info last week 16:12:43 unfortunately, we didn't get any 16:12:59 though we got a note from dlehman saying it looks like a failure case he's aware of 16:13:14 and got no info. So, is this a case of punt again and wait longer, or "its not verifiable, -1 16:13:49 probably wait one more week? 16:13:58 * pwhalen is here 16:14:00 /me shrugs 16:14:16 yeah, i was gonna say the same 16:14:17 punt and ping 16:14:25 Has anyone else tried to reproduce it? 16:14:30 we could put the stick into play this week 16:14:35 'if we don't get any more info it gets rejected' 16:14:52 yes but i don't even know the conditions to set up the reproducer 16:14:52 sgallagh: man, that sounds an awful lot like work 16:15:10 right 16:15:21 it's a bit hard to 'reproduce' when we don't know what they actually have to start with 16:15:31 i mean, i can run a couple of firmware/software RAID installs on my test box, but other than that... 16:15:40 If we don't have enough information to make a judgement, I'd reject it and ask them to resubmit if they can find a clear reproducer 16:15:45 Or if someone else encounters it, etc. 16:15:57 basically the array is failed for some reason but then b, c, and d happen and blivet face plants? (sorta) 16:16:13 adamw: If it's that dependent on starting condition, I think that probably isn't blocker-worthy. 16:16:20 Edge cases will always exist 16:16:26 Well I think it needs to bounce to Anaconda folks to see if it's sufficiently bad to warrant blocking on. 16:16:27 sgallagh: we don't know if it's an edge case, though 16:16:36 just about all we know is that they had some disks and raid is somehow involved and then it crashed. 16:16:37 cmurf: the way I read it was if there is an md array present, blivet bailes 16:16:46 adamw: As far as I'm concerned, it's an edge case until at least one other person hits it 16:16:47 danofsatx: pretty sure it's not that general. 16:16:52 sgallagh: there are two reporters. 16:16:58 * danofsatx admits he skimmed 16:16:59 /me rereads 16:17:04 it's not that general or I'd have hit it 16:17:05 one of them is hughsie, so we can probably lean on him for some info 16:17:45 Oh, I missed hughsie's comment. 16:17:51 Yeah, he'd probably be a good source of info. 16:18:04 cmurf: my interpretation of #c15 is dlehman doesn't think it's a screaming priority (hence 'backlog'), but i admit that's an inference. 16:19:01 i'd like to know more about what the setup is 16:19:13 adamw: Well, it looks like it's not a huge priority because two rapid invocations of the installer right after each other is unlikely 16:19:23 But it may be that the Live image is prone to doing that for some reasons. 16:19:36 (Or it doesn't handle an accidental double-click safely, etc.) 16:19:45 hmm, that could be it... 16:20:24 ooooh the accidental double double-click? 16:20:32 hate those 16:20:39 mike was on KDE 16:20:47 and KDE launches on a single click, and isn't terribly obvious about it 16:20:49 "looks like two anaconda runs in close succession" c15 16:20:51 so you can very easily run it twice 16:20:55 i did not try that 16:21:09 sure helps to read, geez 16:21:17 i'd say that wouldn't constitute a blocker, though it *is* an unfortunate experience, maybe we can talk to KDE folks about it 16:21:29 adamw: Except that doesn't explain hughsie. 16:21:32 hughsie was on Workstation though 16:21:33 yeah 16:21:40 it's possible to do the same from workstation of course 16:21:42 i will ask him about it 16:21:54 it's just *really easy* on KDE, i do it all the time 16:22:06 It's also possible that an input bug could cause it to trigger twisce or something. 16:22:08 so i'm gonna say my proposal here is we go for the stick-based punt 16:22:18 *twice 16:22:29 it is - the GTk stuff doesnt' support the single click launch, and I get confused when going back and forth between Qt and GTk 16:22:34 one more week, but with a presumption that the bug was caused by running the installer twice somehow and we don't consider that blocker-worthy 16:22:42 +1 punt. 16:22:52 adamw: Works for me. 16:22:54 so if we don't get more info that changes the picture, it'll be rejected next week 16:23:00 yes 16:23:34 +1 punt a week 16:23:49 then reject if no new/compelling info 16:23:56 +1 to what adamw said, assuming it's phrased right 16:23:58 proposed #agreed 1321393 - punt (delay decision) - we still didn't get categorical information here, but we suspect it was caused by multiple installer launches, which is an unfortunate UI issue but wouldn't be a blocker. if we don't get new information by next week this will be rejected 16:24:11 ack 16:24:11 ack 16:24:13 ack 16:24:14 ack 16:24:16 #agreed 1321393 - punt (delay decision) - we still didn't get categorical information here, but we suspect it was caused by multiple installer launches, which is an unfortunate UI issue but wouldn't be a blocker. if we don't get new information by next week this will be rejected 16:24:18 adamw: One more thing 16:24:24 #action adamw to ping hughsie about his 1321393 experience 16:24:27 yep sgallagh? 16:24:40 Add to the "stick" message: "Please see if the same problem happens from a network install medium" 16:24:58 can't, no way to double click 16:25:00 Because that would boot straight to Anaconda and eliminate any UI-introduced causes 16:25:07 cmurf: We're *assuming* that's the reason 16:25:12 this is a way to check it, i guess 16:25:13 yes 16:25:14 We can rule that out if it still fails 16:25:40 alrighty 16:25:48 that was the only proposed beta blocker 16:26:02 #info moving on to proposed Final blockers 16:26:07 #topic (1325471) resolving Supplements: dependencies pull in multilib packages 16:26:07 #link https://bugzilla.redhat.com/show_bug.cgi?id=1325471 16:26:07 #info Proposed Blocker, dnf, NEW 16:27:35 * danofsatx needs a criteria before he can vote on this one. 16:27:44 It's ugly, but as it stands it isn't a blocker. 16:27:56 i would actually argue it as a beta blocker 16:28:03 I've seen this also in a different context, where an old or new kernel header was present and for whatever reason dnf decided to drag in a pile of i686 stuff for no obvious reason 16:28:23 "The installed system must be able to download and install updates with the default console package manager." 16:28:33 we've interpreted that criterion as covering major package manager fail before 16:28:49 i think it's better for this to get fixed sooner than later 16:28:58 on the basis that updates go wonky. so okay, updating would technically 'work' with this bug, but it's pretty crappy if you install f24, do your first system update, and get a crapton of i686 packages 16:29:06 but, it isn't failing. It's just doing more than it's supposed to. 16:29:17 and we can't fix it with an update for people who install from a live, because the bug will affect their first update, run with the shipped dnf 16:29:22 yeah 16:29:26 danofsatx: right, but we have been a bit stretch-y on that before 16:29:43 I'm afraid what else this issue can cause than just pulling lots of deps. +1 to Final from me. not sure about Beta 16:29:48 we should probably amend the criterion to be slightly stricter (like 'correctly update the system' or something like that) 16:30:04 oh, now it'll never pass. 16:30:07 kparal: pulling in a bunch of i686 packages is a pretty crappy experience, but okay, i guess final. 16:30:11 danofsatx: heh =) 16:30:18 more elaborate wording suggestions welcome 16:30:34 for me it pulled in so many i686 packages i refused the update 16:30:51 gotta go. +1 final. 16:30:55 +1 beta blocker 16:31:09 if you really wanna make it beta, I guess I can move to +1 beta, too. 16:31:14 have fun, folks. 16:32:06 thanks dan 16:32:06 +1 final/+1 FE for beta. 16:32:17 I think this is going to prove to be a design problem around weak deps 16:32:19 seems we're a bit more +1 final than beta 16:32:26 If these were real packages, it would be pretty sane. 16:32:39 adamw: I'm thinking; on the fence at the moment. 16:32:56 I'm +1 final too. it's inconvenient, but it doesn't break the system AFAIK 16:33:08 shame it cannot be fixed by update though 16:33:38 +1 final 16:34:06 hum, i kinda remember that on mandrake, when you update the whole system, it applies any updates to the package manager first, then updates everything else with the updated package manager... 16:34:09 aaaanyhoo. 16:34:10 I'm definitely +1 to final blocker, but I think I'm slightly +1 on Beta as well 16:34:28 adamw: I filed that RFE two years ago. *crickets* 16:34:35 * adamw tries to count votes 16:35:21 +1 final, and +1 FE beta 16:35:31 so i floated +1 beta as a kind of trial balloon, i'm gonna count myself +0.5. pwhalen is +1. danofsatx seems to be like +0.25. where would you put yourself on a scale of +0 to +1, sgallagh? =) 16:35:47 * adamw doesn't know the decimal interpretation of 'slightly' 16:35:52 It's probably turning out to be an edge-case in dependency resolution, where for some reason at least one of the i686 packages that is pulled in by a virtual provides has decided that the i686 version is the shorter dep-chain or something 16:36:03 Fedora Blocker Voting: Just Slightly Less Of A Joke Than American Presidential Elections 16:36:04 +0.5 Beta 16:36:21 on beta block i'd want to hear from dnf folks if that's realistic, if so then yeah i'm more +1 than not for beta 16:36:30 that gives us a total of like +2.25, i think that's a bit low. so let's go with final for now. we can maybe reconsider based on whatever info comes out in the bug 16:36:42 /me nods 16:36:43 +0 Beta from me 16:36:44 fair 16:36:51 adamw, sounds reasonable 16:36:59 i guess there's always the option that we just drop problematic weak deps from packages, which *would* solve the problem without needing changes to the media 16:37:07 I'm just concerned that folks who install the Beta would get a really bad impression from this 16:37:12 Right 16:38:05 proposed #agreed 1325471 - AcceptedBlocker (Final) - the exact details are not nailed down yet, but the effect of installing a ton of multilib packages on system update is considered a conditional violation of "The installed system must be able to download and install updates with the default console package manager." and accepted as a Final blocker for now. may be up- or down-graded depending on details that later come to light 16:38:06 sgallagh: bad impression and tons of packages which might stay in they system foreverer... 16:38:20 s/they/their 16:38:26 jpigface: Yes 16:38:33 oh, patch 16:38:40 jpigface, yes good point, through the next major upgrade too 16:38:50 proposed #agreed 1325471 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - the exact details are not nailed down yet, but the effect of installing a ton of multilib packages on system update is considered a conditional violation of "The installed system must be able to download and install updates with the default console package manager." and accepted as a Final blocker and Beta freeze exception for now. may be up- or down-graded depen 16:38:50 ding on details that later come to light 16:38:53 grr 16:39:08 Well, in theory we could have glibc.x86_64 Obsoletes: glibc.i686 :-D 16:39:19 (I kid) 16:39:20 proposed #agreed 1325471 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - details are not nailed down yet, but installing a ton of multilib packages on system update is considered a conditional violation of "The installed system must be able to download and install updates with the default console package manager." and accepted as a Final blocker and Beta freeze exception for now. may be up- or down-graded depending on details that lat 16:39:20 er come to light 16:39:25 goddamnit, letters 16:39:42 proposed #agreed 1325471 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - details are not nailed down yet, but installing a ton of multilib packages on system update is considered a conditional violation of "The installed system must be able to download and install updates with the default console package manager." and accepted as a Final blocker and Beta freeze exception for now. may be up or downgraded based on later info 16:39:45 woohoo 16:39:46 ack 16:39:51 patch: Drop "or downgraded" 16:40:19 sgallagh: meh, if we just decide to say 'no goddamn problematic weak deps' that could be no blocker, or one of the special blocker types we invented but didn't use yet 16:40:27 i could just say 'changed' 16:40:32 It's not an actual blocker if we might downgrade it :) 16:40:38 plain language +1 16:40:41 No, that would be a legitimate fix to the "block" 16:40:44 proposed #agreed 1325471 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - details are not nailed down yet, but installing a ton of multilib packages on system update is considered a conditional violation of "The installed system must be able to download and install updates with the default console package manager." and accepted as a Final blocker and Beta freeze exception for now. decision may be changed based on later info 16:40:50 ack 16:40:54 ack 16:40:57 ack 16:40:57 ack 16:40:58 ack 16:41:00 okely dokely 16:41:02 ack 16:41:03 #agreed 1325471 - AcceptedBlocker (Final) AcceptedFreezeException (Beta) - details are not nailed down yet, but installing a ton of multilib packages on system update is considered a conditional violation of "The installed system must be able to download and install updates with the default console package manager." and accepted as a Final blocker and Beta freeze exception for now. decision may be changed based on later info 16:41:07 btw. there is newly proposed Beta blocker 16:41:14 Of course there is 16:41:20 pschindl: thanks, will circle back after doing final 16:41:26 #topic (1320273) Grub2 out of memory error 16:41:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=1320273 16:41:26 #info Proposed Blocker, grub2, NEW 16:42:05 this seems to be an issue when dual booting 16:42:21 reads like it's probably UEFI only, but that's probably becoming the majority case these days 16:43:04 seems to affect only chainloader 16:43:23 +1 16:43:35 The -30 version is find on a Mac and on an Intel NUC with current firmware 16:43:40 find=fine 16:43:46 i'm +1 per the criteria, but with a note we may need to consider changing the criteria if chainbooting UEFI is not realistically supportable 16:44:00 if pjones is fine with supporting that still, then i'd stay +1 16:44:15 Well if it breaks non-Secure Boot chainloading of Windows, then it's a regression. The intent is to support Secure Boot chainloading too. 16:44:15 well it worked until now, so what changed? 16:44:27 see c14 16:44:42 it's just an instinct i have that chainloading UEFI seems to be a more complex case that throws up issues more often 16:44:46 there's a patch for the chainloader module so that it's possible to boot Windows from GRUB with Secure Boot enabled 16:44:49 so i'd kinda like to ask pjones about it 16:45:04 for now, though, looks like a +1 16:45:08 +1 16:45:14 I'm +1 blocker. It breaks the actual criterion. 16:45:16 It's safe to maker it a blocker in the sense that you just back out that patch, if that's the cause, which we don't know right now. 16:45:31 +1 blocker 16:45:34 But it's a regression if Windows can't be booted at all, SB or not. 16:45:34 +1 16:45:39 So yeah +1 16:45:50 +1 16:46:44 proposed #agreed 1320273 - AcceptedBlocker (Final) - this seems like a clear violation of "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora." in the case of a UEFI windows install 16:46:49 hopefully an affected user will build GRUB without that patch, per my request in c14 and we'll know more 16:46:51 ack 16:46:54 ack 16:47:21 ack 16:47:30 #agreed 1320273 - AcceptedBlocker (Final) - this seems like a clear violation of "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora." in the case of a UEFI windows install 16:47:33 maybe enabling grub debug would produce useful info as an alternative 16:47:43 #topic (1317927) selinux prevents systemd-coredump from working 16:47:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1317927 16:47:43 #info Proposed Blocker, selinux-policy, NEW 16:48:52 huh. i have not noticed this happening here, and i run firefox on workstation all the time. 16:49:00 though my install is very old and messy. 16:49:01 1.) set to rawhide 2.) no criterion quoted as blocker justification 3.) i'm running ff ok 16:49:40 has anyone seen anything like this in regular f24 workstation use? 16:49:45 I wonder why mclasen's plugin-helper is crashing 16:49:52 I haven't seen it. 16:50:00 but it probably won't on a clean install, because there would be no plugins 16:50:05 yeah, so when that crashes, then the system becomes slow and unuable 16:50:16 unusable 16:50:33 also, isn't systemd-coredump disabled by default, and abrt used instead? 16:50:46 right 16:50:53 systemd-coredump.socket loaded active listening Process Core Dump Socket 16:50:57 there was talk in desktop@ a while ago about reversing that 16:50:58 so, iunno. 16:51:09 It's running on my system at least 16:51:18 anyhow, i'd suggest we reject with note that it can be re-proposed with a clear rationale 16:51:35 yes 16:52:06 I haven't booted my F24 guests for some days. However, I've never faced this issue. I don't use lots of firefox's extensions/plugins, though... 16:52:07 WFM 16:52:19 at least some reproduction steps. what plugins, what webpage 16:52:22 I'm -1 blocker. 16:52:56 proposed #agreed 1317927 - RejectedBlocker (Final) - firefox being unusable would constitute a blocker issue, however no-one present in the blocker meeting has hit this issue in F24 testing and the bug seems unclear on exactly what configuration is required to trigger it. can be re-proposed with a clearer reproducer and blocker justification 16:53:00 I agree with adamw and kparal. The scenario is not entirely clear. 16:53:16 ack 16:53:18 ack 16:53:19 ack 16:53:19 ack 16:53:22 #agreed 1317927 - RejectedBlocker (Final) - firefox being unusable would constitute a blocker issue, however no-one present in the blocker meeting has hit this issue in F24 testing and the bug seems unclear on exactly what configuration is required to trigger it. can be re-proposed with a clearer reproducer and blocker justification 16:53:59 #info circling back to the newly proposed beta blocker 16:54:30 #topic (1326047) Network Manager IPv4 and IPv6 dialogs incorrectly displayed, unusable with mouse 16:54:30 #link https://bugzilla.redhat.com/show_bug.cgi?id=1326047 16:54:31 #info Proposed Blocker, NetworkManager, NEW 16:54:35 oh yeah, i saw some chatter about this one 16:54:44 criterion not specified, but beta criterion "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional." 16:54:57 cmurf: I replied with a Final criterion that fits 16:54:58 So, is this entirely non-functional? 16:55:10 i might think about it more in terms of not being able to get networking going on a sufficiently configuration-required setup (thus no updates etc) 16:55:11 refresh 16:55:18 but it feels Final-y to me, yeah 16:55:20 I think we could split hairs on whether that's part of the "panel" 16:55:31 i think we can ask people to use workarounds to deal with complex networking at Beta 16:55:39 But I always got the impression that the panel basically meant the desktop shell 16:55:57 sgallagh: it's pretty close for me, it's what you get when you open the top-right menu and hit the network settings 16:56:00 i was going to ask for clarification on 'what constitutes panel' 16:56:04 +1 for final 16:56:07 sgallagh: the criterion was written in the GNOME 2 / KDE 4 days 16:56:09 I think this is caused by reporters screen being very short vertically 16:56:18 when you'd have had an nm-applet icon in the panel 16:56:22 kparal: It's not. 16:56:24 do we have any lowest resolution we officially support? 16:56:26 Can't the dialog be maximized? 16:56:34 I'm experiencing it on a 1920x1080 screen 16:56:37 ok 16:56:42 Though I'm using Wayland 16:56:51 Which is why I asked for someone to try it on X11 16:56:53 sgallagh: can you resize it? 16:57:05 No, it's a modal dialog 16:57:05 I don't think it's resize-able 16:57:15 I think lbrabec saw it on X11 with openVPN dialog 16:57:20 non-resizable windows need to die in a fire 16:57:32 very microsoft-like 16:57:37 kparal: It's also not very large; it should happily fit within 800x600 16:57:45 * cmurf hopes modal dies before he does 16:57:47 Which is the smallest that Anaconda supports, at least 16:58:05 (though I've groused about the lack of support for 720p displays in the past) 16:58:31 in this case I think it's the Final's criterion - all apps must work correctly in a typical use 16:58:40 i see it on X. 16:58:55 on a 2160x1920 setup. 16:59:10 So I'm definitely +1 Final blocker and about +0.5 Beta if we slightly stretch the panel definition 16:59:19 it looks to me like the window is sized for the first panel you see ('Details') and not made bigger when you pick a panel with more stuff in it. 16:59:27 +1 Final 16:59:41 adamw: Two 1920x1080 displays atop one another? Or portrait mode next to each other? 16:59:47 Either way... *low whistle* 16:59:51 +1 final 16:59:52 +1 Final for me also 16:59:54 for Beta i'm okay with telling people to do it blind with keyboard or nmcli or whatever 17:00:05 sgallagh: two 1920x1080 in portrait, i've been running that way for a while 17:00:26 sgallagh: https://www.happyassassin.net/extras/desk5.jpg 17:00:52 The beta criterion says "No part of any release-blocking desktop's panel configuration may crash on startup or be *ENTIRELY* non-functional. ". Therefore, I'm more -1 beta / +1 final. 17:01:05 yeah, the beta panel criterion is intentionally quite narrow, the final one is wider 17:01:45 Right, but at the same time I'd argue that not being able to actually effect any changes on the network settings could conceivably qualify as entirely non-functional 17:02:02 i think it's pretty close to entirely non-functional 17:02:06 So while it sounds like we're going to call it a Final blocker, I'd *really* like to see it fixed before that. 17:02:07 ok maybe two buttons work? 17:02:15 proposed #agreed 1326047 - AcceptedBlocker (Final) - violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." The 'advanced network config' experience for Beta is unfortunate, but we don't consider it a sufficiently serious case to take as a conditional violation of e.g. updat 17:02:16 es criterion 17:02:24 Because it also means that users will have a problem setting up the network in the Desktop Live 17:02:35 proposed #agreed 1326047 - AcceptedBlocker (Final) - violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must...withstand a basic functionality test." The 'advanced network config' experience for Beta is unfortunate, but we don't consider it a sufficiently serious case to take as a conditional violation of e.g. updates criterion 17:02:42 So I've actually talked myself into a full +1 Beta Blocker here 17:02:50 sgallagh: only if they actually need to go in and poke things, though. which isn't a very common case 17:03:05 you don't need it to use a normal DHCP ethernet, that just comes up. you don't need it to get on a typical wifi network. 17:03:19 * kparal agrees 17:03:22 you can even see enough to do a static IP config. 17:03:28 kparal: With whom? 17:03:28 people with custom networking setups can use nmcli 17:03:35 sgallagh: with adamw 17:03:46 I'll add it to commonbugs 17:04:04 anyone else wanna argue for +1 beta? 17:04:31 the 90% use case or better is probably it autoconfigs with dhcp and the user doesn't even look at NetworkManager 17:04:46 yeah, that's my instinct 17:05:13 I suppose we can just tell people to install Cockpit in the meantime :) 17:05:17 haha yes 17:05:22 cockpit is badass 17:05:44 =)( 17:05:52 alright, ack/nack/patch ? 17:05:57 adamw: Did you just make duck-face at us? 17:05:58 I'd be +1 FE beta 17:06:03 sgallagh: no, i typoed. 17:06:08 cmurf: oh yeah, me too. 17:06:22 assuming the fix isn't too crazy and doesn't come last minute, but i'd definitely take it at a sane time 17:06:23 I'd prefer not to give out FEs before Freeze, honestly. 17:06:37 No way of knowing what else is coming along for the ride this far in advance 17:06:40 right 17:06:41 ack 17:06:46 okay, let's go with this then 17:06:48 * adamw self-acks 17:06:49 ack 17:06:55 match patch? 17:07:01 cmurf: ? 17:07:10 ack 17:07:11 mention that we'd consider FE beta? 17:07:26 cmurf: i'm gonna go with sgallagh and just go with the blocker decision for now 17:07:30 fine 17:07:42 note, this of course has NOTHING AT ALL to do with the fact that i dunno how to get the agreed under the character limit with acceptedfe in it 17:07:49 Nothing wrong with adding along "This really sucks, please don't wait for Final Freeze to fix it", though :) 17:07:52 that's entirely coincidental 17:08:01 sgallagh: seconded, kparal do that =) 17:08:20 ack 17:08:22 #agreed 1326047 - AcceptedBlocker (Final) - violates "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must...withstand a basic functionality test." The 'advanced network config' experience for Beta is unfortunate, but we don't consider it a sufficiently serious case to take as a conditional violation of e.g. updates criterion 17:08:39 adamw: : do what? 17:08:51 #agreed we do think 1326047 sucks and would like it fixed ASAP, and will likely vote +1 FE for Beta if it comes to that. 17:08:59 kparal: say what sgallagh suggested in the comment :) 17:09:06 new beta blocker has appeared 17:09:11 cmurf: yeah, i know 17:09:17 we are doomed to never leave this meeting 17:09:26 #topic (1326055) Applications using Qt 5 are not displaying spinner and checked menu items properly. 17:09:26 #link https://bugzilla.redhat.com/show_bug.cgi?id=1326055 17:09:27 #info Proposed Blocker, adwaita-qt, NEW 17:09:44 if anyone proposes another beta blocker i'm gonna re-assign all blockers to them 17:09:56 sgallagh: I see it now. damn, too late 17:10:00 adamw: ^^ 17:10:14 kparal: just add another comment. they're free! 17:10:27 adamw: no, they just have to open a monut truck 17:10:35 I'll rely on the community to do that for me, for free 17:10:36 and we get free monuts 17:10:53 -1 beta, i don't think anything in the beta criteria is gonna depend on Qt apps in Workstation looking nice. 17:11:09 it's pretty borderline even for Final, unless this constitutes 'basic functionality' in any of the default installed apps. 17:12:03 though i suppose this is probably related to the similar issues in firefox, which *is* an important app. 17:12:05 Proposal: punt for a week pending response by QT5 devs 17:12:07 -1 17:12:12 looking at the screenshots, this looks like a polish issue than something not working 17:12:18 sgallagh: mm, nah, still -1. 17:12:39 the description is more severe that the screenshot 17:12:45 cmurf: the checkmark thing would be pretty confusing, for me this is just a case of 'nothing that important in Workstation is a Qt app' 17:12:53 checkboxes are completely broken 17:12:54 -1 17:13:05 drop-down lists are cropped 17:13:16 too bad we don't have any QT apps installed by default 17:13:37 OIC 17:13:41 I'd like to have a final criterion for this anyway, but that's not currently the case, so -1 17:13:49 this is a proposed *beta* blocker, note 17:13:59 I know, I'm thinking ahead :) 17:14:02 =) 17:14:20 yeah so is it a default application, no 17:14:25 we've got -4 so far, anyone wanna stand with sgallagh? 17:14:31 and does it withstand basic functionality yes 17:14:34 so not a final blocker 17:14:39 let alone beta 17:15:00 I'm -1 beta blocker. 17:15:06 I'm just not sure how it stands with Final 17:15:13 If QT5 devs want to propose a blocker criterion... 17:15:30 sgallagh: well, we don't have to punt for any final blocker questions, we can just reject for beta and deal with that later. 17:15:39 agreed 17:15:44 True enough 17:15:53 proposed #agreed 1326055 - RejectedBlocker (Beta) - this clearly does not violate any of the Beta criteria, nothing in those depends on Qt apps running on Workstation 17:16:03 I suspect this would fail the generally-functional test for some of the KDE Live apps though 17:16:11 (For Final) 17:17:12 except that we have no indication it happens in a KDE environment. 17:17:25 the bug specifically talks about running Qt apps *in Workstation*, using the adwaita-qt stuff. 17:17:42 ah, valid point 17:18:03 Also, ack 17:18:07 Are there any Qt apps in workstation installed by default? 17:18:13 ack 17:18:18 ack 17:18:20 off the top of my head i wanna say 'no'. but for beta it doesn't matter. only for final. 17:18:43 #agreed 1326055 - RejectedBlocker (Beta) - this clearly does not violate any of the Beta criteria, nothing in those depends on Qt apps running on Workstation 17:19:03 ack 17:19:07 looking at accepted blockers... 17:19:19 #topic Beta accepted blocker round up 17:19:30 #info info is still requested on https://bugzilla.redhat.com/show_bug.cgi?id=1262556 17:19:33 i should stop sucking and do that 17:20:21 #info we more or less know what's going on with https://bugzilla.redhat.com/show_bug.cgi?id=1306808 (btrfs volume reuse bug) and anaconda team expects it to be dealt with some time this week 17:20:35 the others are just waiting for devs, i think, i should send out a blocker status mail soon 17:20:42 any other notes on those? 17:21:52 freeze is next week tuesday 17:22:05 oh hey that's coming up fast! 17:22:24 #info Beta freeze is 2016-04-19 , so we'll be reviewing FEs next week 17:23:24 #topic Open floor 17:23:42 any other business? anyone got next week's lottery numbers or the winner of the 2 o' clock? 17:24:54 no? damnit, i have to keep working with all these schmucks 17:24:57 * kparal plays lottery only with python's random module 17:25:16 ban lotteries 17:25:21 right after you win 17:26:20 alrighty, thanks for coming folks! 17:26:32 remember, everyone else should do serious beta testing while i screw around with shiny side projects 17:26:35 that's how this team works, right? 17:26:47 /me only enters The Lottery by Shirley Jackson. 17:27:34 adamw: I keep telling everyone the exactly same thing 17:27:49 this could be the problem 17:27:55 * cmurf adds The Lottery to list 17:28:11 #endmeeting