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