16:00:19 <adamw> #startmeeting F24-blocker-review
16:00:19 <zodbot> Meeting started Mon May 23 16:00:19 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:19 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:00:19 <adamw> #meetingname F24-blocker-review
16:00:19 <zodbot> The meeting name has been set to 'f24-blocker-review'
16:00:19 <adamw> #topic Roll Call
16:00:27 <adamw> ahoyhoy, who's around for blocker review fun?
16:00:30 * kparal is here
16:00:34 * omiday is here
16:00:49 * omiday will mostly listen
16:01:18 * coremodule is here.
16:01:28 <adamw> less listening! more voting!
16:01:32 <adamw> well, i guess listening AND voting is okay. :P
16:01:42 <omiday> okay okay :)
16:02:06 <adamw> danofsatx: nirik: ping
16:02:20 <kparal> we seem to be running with 0 pschindls
16:02:22 <adamw> satellit: sgallagh: tflink: ping
16:02:28 * nirik is in another meeting, but what do you need?
16:02:36 <adamw> the pschindl valve is on empty? oh noes!
16:02:46 <adamw> nirik: it's a blocker meeting, what do we always need
16:02:55 * tflink can be around for 2 hours
16:03:02 <nirik> +1 to block all the things! :0)
16:03:37 * adamw nails tflink to the floor
16:03:41 <adamw> ok, that sounds like enough to move on with
16:03:46 <adamw> #chair kparal tflink
16:03:46 <zodbot> Current chairs: adamw kparal tflink
16:03:52 <adamw> who's gonna secretarialize?
16:03:57 <sgallagh> adamw: I guess I'm here too
16:03:59 <coremodule> adamw, I'll do it.
16:04:06 <sgallagh> But I apologize if I disappear randomly.
16:04:09 * adamw tapes sgallagh to the wall
16:04:11 <sgallagh> *in advance
16:04:13 <adamw> now no-one call the cops
16:04:20 <adamw> #info coremodule to secretarialize
16:04:22 <adamw> coremodule: thanks!
16:04:32 <coremodule> adamw, np
16:04:33 <adamw> #topic Introduction
16:04:34 <adamw> Why are we here?
16:04:34 <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:04:34 <adamw> #info We'll be following the process outlined at:
16:04:34 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:04:35 <adamw> #info The bugs up for review today are available at:
16:04:37 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:04:39 <adamw> #info The criteria for release blocking bugs can be found at:
16:04:41 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria
16:04:43 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria
16:04:45 <adamw> #link https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria
16:04:47 <adamw> wheeee, who doesn't love boilerplate
16:05:00 <adamw> OK, here we go with proposed Final blockers
16:05:01 <adamw> #topic (1337731) Live image compose fails with dnf 1.1.9
16:05:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1337731
16:05:01 <adamw> #info Proposed Blocker, anaconda, NEW
16:05:45 <handsome_pirate> Hey, y'all, I'm probably going to be mostly spectating
16:06:03 <sgallagh> All lives aren't building? Isn't that an auto-blocker?
16:06:52 <adamw> the offending dnf is not stable yet
16:06:55 <adamw> hi, pirate
16:07:01 <adamw> so this isn't technically a blocker yet
16:07:15 <adamw> but it's at +2 and i'm not reading igor as being particularly keen on holding it up...
16:07:16 <sgallagh> ah
16:08:09 <sgallagh> So I guess, conditional blocker? We vote +1 now and if DNF goes stable, it automatically promotes?
16:08:42 <adamw> that, or we punt it for a week and see where we're at then...
16:08:51 <handsome_pirate> Wouldn't this just mean we don't push dnf to stable?
16:09:45 <sgallagh> The sea-dog makes a valid point. Should we just all negkarma the dnf update?
16:09:47 <handsome_pirate> oh
16:10:26 <handsome_pirate> sorry, that oh wasn't meant for this channel
16:10:39 <adamw> sgallagh: that's an option.
16:10:55 <tflink> sounds like the most simple option to me
16:10:59 <adamw> i'd prefer it, but people are throwing +1s at the update and igor is all 'oh well someone else should fix it'.
16:11:02 <adamw> so, i dunno.
16:11:19 <handsome_pirate> So, I do think I agree with the reasoning of the dnf folks, it's a bit late in the release cycle to be doing this sort of change
16:13:07 <adamw> anyhow, we need a discussion
16:13:13 <adamw> so i kinda like sgallagh's idea of 'conditional blocker'
16:13:15 <tflink> definitely not -1 either way
16:13:23 <adamw> s/discussion/decision/
16:13:24 <tflink> works for me
16:13:31 <adamw> would everyone be +1 if this update went stable?
16:13:37 <tflink> +1 blocker if the dnf update goes stable
16:13:39 <sgallagh> /me would
16:13:41 <sgallagh> +1
16:13:50 * kparal nods
16:14:17 <adamw> alright
16:14:18 <handsome_pirate> adamw:  I would be, yes
16:14:20 <coremodule> +1, yes.
16:14:32 <handsome_pirate> adamw:  I also just added -1 karma to the update
16:15:21 <adamw> proposed #agreed 1337731 - conditional AcceptedBlocker (Final) - the dnf update is not yet stable, but there seems to be a possibility that it will be pushed stable. If it does go stable with no fix for this bug in any other component, this bug can be marked as an AcceptedBlocker due to obvious violation of criteria by preventing release-blocking images from composing
16:15:38 <sgallagh> ack
16:15:52 <coremodule> ack
16:16:04 <kparal> ack
16:16:09 <adamw> #agreed 1337731 - conditional AcceptedBlocker (Final) - the dnf update is not yet stable, but there seems to be a possibility that it will be pushed stable. If it does go stable with no fix for this bug in any other component, this bug can be marked as an AcceptedBlocker due to obvious violation of criteria by preventing release-blocking images from composing
16:16:17 <adamw> #topic (1336810) Calligra Words crashed when I opened a template.
16:16:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1336810
16:16:17 <adamw> #info Proposed Blocker, calligra, VERIFIED
16:17:08 <adamw> +1 blocker
16:17:14 <adamw> (looks like it'll be fixed soon, yay)
16:17:49 <tflink> +1
16:18:26 <sgallagh> Pedantic: are templates "basic functionality" for Calligra?
16:18:34 <handsome_pirate> +1
16:18:41 <handsome_pirate> sgallagh:  I would say so
16:18:58 <adamw> i'd say they're pretty basic for anything office-y
16:19:06 <adamw> i think you have to pick a template when creating a new document, no?
16:19:13 <handsome_pirate> aye
16:19:15 <omiday> sgallagh: by default when you start it up it presents you with the template screen
16:19:17 <sgallagh> /me has never used that tool
16:19:23 <sgallagh> OK, then +1 blocker
16:19:32 <kparal> +1
16:19:38 <omiday> +1
16:20:13 <adamw> proposed #agreed 1336810 - AcceptedBlocker (Final) - clear violation of cited criterion "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."
16:20:29 <tflink> ack
16:20:32 <sgallagh> ack
16:20:39 <coremodule> ack
16:20:47 <omiday> ack
16:21:49 <kparal> ack
16:22:12 <adamw> #agreed 1336810 - AcceptedBlocker (Final) - clear violation of cited criterion "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."
16:22:22 <adamw> #topic (1336879) dnf fails to respect conditional level in comps.xml
16:22:23 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1336879
16:22:23 <adamw> #info Proposed Blocker, dnf, NEW
16:22:26 <adamw> oh whee, more comps fun
16:22:31 <adamw> why have we not shot comps in the head y et
16:22:52 <sgallagh> adamw: We have, but unfortunately it's not a Romero-style undead.
16:23:00 <adamw> heh
16:23:05 <adamw> someone pass me the wooden stake
16:23:33 <sgallagh> adamw: Unfortunately, I think we're dealing with a lich.
16:23:40 <adamw> no-one's cited a reason why this is a release blocker yet
16:23:49 <adamw> though it sounds like it affects live image creation
16:24:10 <tflink> is this the bug that prompted the fix that broke lives?
16:24:46 <sgallagh> adamw: Yes, but the workaround is for the live images to just specify their dependencies explicitly.
16:25:22 <adamw> tflink: no, i think that's a different one, about it not failing when a 'mandatory' package isn't present
16:25:32 <sgallagh> I'm inclined to say -1 blocker and ask them to add the missing bits to spin-kickstarts for now
16:25:50 <adamw> that seems reasonable...
16:25:58 <sgallagh> (Or fix the bug, but not block on failing to do so)
16:26:11 <kparal> I think this does not break compose but localization support?
16:26:24 <adamw> kparal: the 'conditional' feature of comps is used for different reasons
16:26:31 <adamw> g11n is one, but there are others
16:26:45 <sgallagh> kparal: This is different from the weak deps
16:26:46 <adamw> e.g. the one luya cites in the description
16:26:51 <tflink> the bug says that KDE is affected
16:26:52 <sgallagh> Which is a better solution than the comps one
16:27:40 <kparal> I thought the end result of this bug that I won't have "Finnish Support" installed when I should have
16:27:41 <sgallagh> As an aside, the effect of this bug is to actually reduce the number of things eligible to trigger the "default functionality" blocker criterion, so leaving it alone makes our jobs easier...
16:27:47 <kparal> so some packages will not have Finnish help, etc
16:28:11 <sgallagh> kparal: That may be true, but this isn't the mechanism that those packages are supposed to be using to achieve that anyway.
16:28:39 <sgallagh> They're supposed to be using Supplements: langpack-fi
16:28:49 <kparal> ok
16:29:22 <adamw> i think i can go with sgallagh on this one, -1
16:29:26 <sgallagh> (Now, whether the compose tools fully understand that is a different question; I think at the moment we're telling people to make sure they're all explicitly listed in the spin-kickstart)
16:29:42 <sgallagh> And then they get picked up properly by DNF during install.
16:30:01 <tflink> -1 blocker, +1 FE
16:31:31 <sgallagh> I'm -1 FE as well, actually.
16:31:53 <sgallagh> If we got to Freeze with this, I wouldn't break freeze to change how we process comps. Too risky.
16:31:56 <adamw> proposed #agreed 1336879 - RejectedBlocker, AcceptedFreezeException (Final) - none of the known impacts of this appear to violate the release criteria, and any missing packages on deliverables can be resolved by adding them to spin-kickstarts until this bug is dealt with
16:32:04 <adamw> hmm, point...
16:32:17 <adamw> tflink: wdyt?
16:33:24 <tflink> makes sense
16:33:25 <tflink> -1 FE
16:34:14 <adamw> proposed #agreed 1336879 - RejectedBlocker, RejectedFreezeException (Final) - none of the known impacts of this appear to violate the release criteria, and any missing packages on deliverables can be resolved by adding them to spin-kickstarts until this bug is dealt with. We also think changing this after freeze would be too dangerous for too little benefit
16:34:27 <kparal> ack
16:34:34 <tflink> ack
16:35:27 <adamw> one more ack?
16:35:39 <omiday> ack
16:35:49 <coremodule> ack
16:35:57 <sgallagh> ack
16:36:00 <adamw> #agreed 1336879 - RejectedBlocker, RejectedFreezeException (Final) - none of the known impacts of this appear to violate the release criteria, and any missing packages on deliverables can be resolved by adding them to spin-kickstarts until this bug is dealt with. We also think changing this after freeze would be too dangerous for too little benefit
16:36:06 * adamw drowns in flood of acks
16:36:13 <adamw> #topic (1337336) gnome-software shows updates but "Restart & Install" button doesn't install them
16:36:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1337336
16:36:14 <adamw> #info Proposed Blocker, gnome-software, NEW
16:36:44 * omiday throws a life vest
16:36:57 <kparal> coremodule reproduced this consistently
16:37:02 <coremodule> FYI, Just retried this, had two other updates needed to be installed, SELinux and gnome-something and now it's working. It looks like when it only had the "OS Updates" as a selected update, it wouldn't trigger the update upon reboot, but now, with more updates, it's working.
16:37:13 <kparal> I wanted to try as well, but at the moment gnome-software shows absolutely no updates for me
16:37:16 <kparal> even though pkcon does
16:37:26 <kparal> broken as usual
16:37:47 <coremodule> The two initial times I tried this, the only update on the list was "OS Updates".
16:37:55 <adamw> hmm, okay
16:38:03 <sgallagh> I have some available right now.
16:38:07 <coremodule> But 'dnf update' worked just fine to install it.
16:38:14 <sgallagh> I can try if you want (but will need to disconnect for a few)
16:38:30 <adamw> sgallagh: only 'OS Updates'? or others too?
16:38:48 <sgallagh> LibreOffice, Empathy and others.
16:40:24 <sgallagh> /me dnf updates the non-OS ones
16:40:41 <adamw> as described, anyhow, I'd be +1 i think
16:41:43 <sgallagh> I'm riding the fence here a little.
16:41:59 <sgallagh> I mean, if the updates work when a desktop app is on the list, then sooner-or-later it's going to work.
16:42:31 <adamw> well, yeah, but what if there's a security critical 0-day or something? and it's a pretty bad look if you go to do your first update and it fails.
16:43:19 <sgallagh> Yeah, not disagreeing.
16:43:19 <omiday> +1 as the behavior is inconsistent
16:43:38 <sgallagh> I'm kind of +0.5 here.
16:44:10 <coremodule> Uploading a new log with the successful install now...
16:45:10 <tflink> I'm also kinda +0.5, not sure this passes the "last blocker at go/no-go" test
16:45:17 <omiday> then it needs more testing?
16:46:01 <kparal> yeah, I'd punt and test more
16:46:32 <coremodule> +1 for punt w/ more testing
16:46:50 <adamw> well i'm fine with punting in the hopes that it gets fixed and we don't have to care...
16:47:03 <tflink> that would be closer to an ideal, yes :)
16:47:09 <tflink> punt works for me
16:47:52 <adamw> proposed #agreed 1337336 - punt (delay decision) - this is definitely a worrying bug but we want to be clear on the circumstances in which it does and does not occur before making a final decision
16:47:59 <sgallagh> ack
16:48:20 <coremodule> ack
16:48:21 <tflink> ack
16:48:38 <adamw> #agreed 1337336 - punt (delay decision) - this is definitely a worrying bug but we want to be clear on the circumstances in which it does and does not occur before making a final decision
16:48:47 <adamw> #topic (1338054) Fedora 24 keepassx has a lower version number it wants to upgrade a higher version package from Fedora 23
16:48:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1338054
16:48:47 <adamw> #info Proposed Blocker, keepassx, NEW
16:49:08 <adamw> is keepassx is any of the upgrade-blocking default package sets?
16:50:30 <adamw> there does appear to be something of a mess here, though
16:50:44 <kparal> there should be a reasonably easy way to figure that out, right? I don't know it
16:50:54 <tflink> wasn't the update unpushed?
16:51:00 <adamw> 2.0.0-1.fc23 was pushed stable
16:51:12 <tflink> the 0.4.4.1 update
16:51:22 <tflink> er, 0.4.4-1
16:51:27 <adamw> a revert to 0.4.4 was done in git and builds sent out for f22, f23 and f24
16:51:35 <adamw> the reverts for f22 and f23 were pushed then unpushed
16:51:40 <adamw> the revert for f24 has not been unpushed
16:51:42 <sgallagh> #link https://fedorahosted.org/fesco/ticket/1569
16:51:44 <kparal> it's not on Workstation
16:51:45 <tflink> wat
16:51:48 * nb thouht limb was working on it
16:51:53 <nb> and was going to re-upgrade to 2?
16:51:58 <adamw> so this is sure a big mess, but i don't know if it's a release blocker
16:52:03 <sgallagh> It's being worked on and the approach is decided.
16:52:27 <sgallagh> I'd definitely offer this a Freeze Exception.
16:52:28 <adamw> keepassx isn't listed in comps at all afaics.
16:52:40 <sgallagh> It's a nasty issue for anyone using keepassx
16:52:47 <sgallagh> But -1 blocker
16:52:52 <adamw> sgallagh: what's the point of giving it an FE?
16:52:58 <nb> -1 blocker
16:53:07 <omiday> -1 here as well
16:53:09 <sgallagh> adamw: Because if limb doesn't fix it by Freeze, I'm going to take over.
16:53:19 <adamw> that's...not an answer?
16:53:32 <nb> +1 FE
16:53:39 <sgallagh> Actually, good point. It doesn't need to be on the frozen set anywhere
16:53:49 <adamw> well, i guess it means we can push a fix during freeze so people who do an upgrade during the freeze period but before we push 0-day updates get it.
16:53:55 <sgallagh> I retract my FE request :-P
16:54:03 <nb> adamw, yeah
16:54:04 <adamw> there is a small benefit to it actually, now i think about it.
16:54:10 <sgallagh> OK, either way.
16:54:20 <nb> -1 blocker +1 FE
16:54:28 <tflink> -1/+1
16:55:13 <omiday> given that it breaks the app I'd give it a +1 FE too
16:55:13 <adamw> proposed #agreed 1338054 - RejectedBlocker (Final) - this is definitely a mess but keepassx is not in any of the package sets cited in the criteria, so it does not qualify as a release blocker. It's accepted as a freeze exception issue as upgrades usually run with u-t disabled, so there is a benefit to pushing it stable between freeze date and 0-day update push date
16:55:38 <sgallagh> ack
16:55:40 <kparal> you should add AcceptedFreezeException(final)
16:55:41 <coremodule> ack
16:55:50 <omiday> also as a workaround the user can always install f23 version
16:56:10 <nb> ack, but add AcceptedFreezeException to the #agreed
16:56:13 <adamw> kparal: yep, sorry
16:56:22 <adamw> proposed #agreed 1338054 - RejectedBlocker AcceptedFreezeException (Final) - this is definitely a mess but keepassx is not in any of the package sets cited in the criteria, so it does not qualify as a release blocker. It's accepted as a freeze exception issue as upgrades usually run with u-t disabled, so there is a benefit to pushing it stable between freeze date and 0-day update push date
16:56:25 <kparal> ack
16:56:28 <tflink> ack
16:56:28 <nb> ack
16:56:31 <adamw> #agreed 1338054 - RejectedBlocker AcceptedFreezeException (Final) - this is definitely a mess but keepassx is not in any of the package sets cited in the criteria, so it does not qualify as a release blocker. It's accepted as a freeze exception issue as upgrades usually run with u-t disabled, so there is a benefit to pushing it stable between freeze date and 0-day update push date
16:56:46 <adamw> coremodule: if you could add a quick note with a link to the fesco issue to lower the reporter's temperature, that'd be good
16:56:55 <adamw> (the bug may also be a dupe, i guess, so check that)
16:57:05 <adamw> #topic (1337582) Fails to start with "Cannot read MSR_ERROR_CONTROL from /dev/cpu/0/msr" when running in VM on Xeon E5-2450 host
16:57:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1337582
16:57:06 <adamw> #info Proposed Blocker, mcelog, NEW
16:57:22 <adamw> so, this is the bug that causes the 'services start' test to fail in openQA quite often
16:57:35 <adamw> for context, we have rejected a similar issue for being too hardware-specific in the past:
16:57:58 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1274193
16:58:02 <kparal> it if seriously decreases our test coverage, I think it's reasonable to block on it
16:58:12 <kparal> we might even have it written like that somewhere
16:58:14 <adamw> kparal: we can actually work around it in openqa quite well
16:58:15 <coremodule> adamw, sure thing.
16:58:29 <adamw> kparal: garret has already written a diff for it
16:58:40 <adamw> i actually nack'ed the diff on the basis that i'd rather we decide on whether the bug is a blocker or not first
16:58:48 <adamw> if we think it's not a blocker, we can implement the openqa workaround
16:59:08 <adamw> so the openqa test will 'soft pass' if only mcelog fails to start
16:59:55 <kparal> All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present
16:59:59 <kparal> so, is this the case?
17:00:02 <adamw> not quite
17:00:04 <adamw> well
17:00:07 <adamw> it's not 100% clear
17:00:15 <tflink> depends on how HW specific it is
17:00:47 <adamw> i guess it may be related to the CPU emulation in qemu...
17:00:59 <adamw> i was hoping to hear back from the mcelog packager /devs by now, honestly
17:01:03 <tflink> is it just that generation of xeon?
17:01:06 <adamw> dunno
17:01:16 <adamw> all i know is it *does* happen on qa14 and does *not* happen on qa05/qa06/qa07
17:01:26 <adamw> but that's exactly two CPUs we know the result for. :P
17:01:42 <adamw> my inclination would be -1 or punt, i think
17:01:47 <tflink> yeah
17:01:51 * kparal is for punting
17:01:54 <tflink> i don't think it's quite blocker yet
17:01:57 <tflink> +1 punt
17:02:16 <adamw> this criterion is very suitable for rejecting 'conditional' blockers, the real idea of the criterion is to make sure we don't ship with a service that's completely broken enabled by default
17:02:28 <adamw> so it kinda does have to be a very non-conditional bug to really count
17:03:29 <omiday> adamw: you noted in the bug that it does start sometimes
17:03:39 <adamw> omiday: it depends on the CPU.
17:04:16 <adamw> proposed #agreed 1337582 - punt (delay decision) - we're inclined to think this is likely too hardware-specific to be a blocker, but we'd like to get some thoughts from mcelog packager/developers if possible, so delaying the decision to see if we hear from them
17:04:29 <kparal> ack
17:04:37 <omiday> ack
17:04:50 <coremodule> ack
17:05:26 <adamw> you know, i'm wondering if it *ever* makes sense to run mcelog in a VM. but maybe best discussed in the bug.
17:05:29 <adamw> #agreed 1337582 - punt (delay decision) - we're inclined to think this is likely too hardware-specific to be a blocker, but we'd like to get some thoughts from mcelog packager/developers if possible, so delaying the decision to see if we hear from them
17:05:44 <adamw> #topic (1332266) systemd-logind does not verify if system has resume device defined when checking if can.hibernate or can.hybridsleep
17:05:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1332266
17:05:45 <adamw> #info Proposed Blocker, systemd, ASSIGNED
17:05:56 <adamw> oh yay. this bug.
17:05:58 * adamw drinks
17:06:08 <tflink> my thoughts exactly
17:06:17 <tflink> but it does sound like there has been some progress
17:06:30 <kparal> c29 is very positive I think
17:06:41 <kparal> we just need to give it go
17:06:48 <kparal> and +1 FE if needed, after freeze
17:07:24 <kparal> IIUIC, fedora will have a local patch for now which will improve logind autodetection and say hibernation is not available if resume= is not present
17:07:45 <kparal> so there will be no misleading popups, and people can still enable resume quite easily
17:07:53 <kparal> (nothing changed in that regard)
17:08:08 <adamw> yeah, sounds good.
17:08:23 <kparal> of course it would be nicer if the resume= was actually added correctly to all installs, but better than nothing
17:08:42 <adamw> i still don't think i buy this as a blocker, personally
17:08:53 <adamw> definitely +1 FE for sensible post-freeze changes
17:09:07 <kparal> +1 FE here
17:09:17 <kparal> do we want to avoid the blocker call? :)
17:11:05 * adamw plays limbo music
17:11:06 <adamw> everybody duck!
17:11:10 <tflink> +1 FE and still on the fence for blocking
17:11:11 <omiday> c29 provides the fix/workaround - what criterion qualifies the bug as a blocker/FE?
17:11:30 <tflink> closer to -1 than +1 on blocker
17:11:48 <kparal> omiday: potential data loss, due to telling the user the system is going to be hibernated, and then not even attempting resume
17:12:04 <kparal> on critical battery, that is
17:12:22 <omiday> c29 patch prevents data logss
17:12:25 <omiday> *loss
17:12:56 <adamw> yes, but it's not in place yet
17:13:26 <adamw> our job at these meetings is to decide whether bugs are blockers: unless a fix is completely in place and the bug report is closed, we should still amke the decision (or explicitly punt)
17:13:42 <adamw> otherwise we can get an unfortunate case where we leave a bug alone because we think it's going to get fixed, then the fix never actually gets landed in time
17:13:45 <tflink> -1 blocker
17:14:30 <omiday> +1 blocker so we get the c29 patch in
17:14:33 <adamw> so we have -2 blocker, +3 fe i think
17:14:41 <adamw> omiday: we don't need to vote +1 blocker for the patch to land.
17:15:05 <adamw> but if we take the bug as a blocker, f24 would not ship until it (or some other fix) did land.
17:15:05 <omiday> ack thanks
17:15:23 <adamw> if we don't take the bug as a blocker, we're saying it's OK for 24 to ship without the fix, if for some reason it doesn't get landed in time.
17:15:27 <adamw> that's the difference.
17:15:27 * kparal is two minds about it
17:16:12 <adamw> pick whichever mind has drunk the most
17:16:16 <omiday> data loss...tells me we need the patch in so we can test before shipping it
17:16:44 <kparal> adamw: let's go -1 blocker
17:18:28 <adamw> proposed #agreed 1332266 - RejectedBlocker AcceptedFreezeException (Final) - we think the consequences of this are unfortunate but don't really constitute a violation of the criteria, the 'data loss' scenario is quite contrived and there is strong precedent to not considering suspend/hibernate issues as release-blocking. This is definitely significant enough to constitute a freeze exception issue, however
17:18:35 <omiday> when are the FE patches made available?
17:18:43 <tflink> ack
17:18:50 <kparal> ack
17:19:33 <adamw> omiday: FE means the fix can go stable during the freeze period.
17:19:48 <adamw> the difference between 'FE' and 'blocker' is that we don't *block* the release if FEs are still outstanding at go/no-go time.
17:20:25 <omiday> would an unresolved FE delay the final release?
17:20:29 <adamw> no.
17:21:26 <adamw> any other ack/nack/patch?
17:21:35 <coremodule> ack
17:22:50 <omiday> I'd be frustrated to install the new release today, hibernate and wake up tomorrow with my session gone... I'm a 'patch' unless someone convinces me otherwise
17:22:59 <adamw> #agreed 1332266 - RejectedBlocker AcceptedFreezeException (Final) - we think the consequences of this are unfortunate but don't really constitute a violation of the criteria, the 'data loss' scenario is quite contrived and there is strong precedent to not considering suspend/hibernate issues as release-blocking. This is definitely significant enough to constitute a freeze exception issue, however
17:23:08 <adamw> omiday: the ack/nack/patch vote isn't a redux of the +1/-1 vote
17:23:21 <adamw> it's only about whether the proposed #agreed accurately reflects everything we discussed
17:23:50 <adamw> it was added because quite often the moderator would typo or miss something out from the #agreed, so it just adds a step for people to spot mistakes
17:24:09 <adamw> it's not appropriate to vote 'nack' because you were on the minority side of the blocker/not-blocker vote
17:24:15 <adamw> (or 'patch')
17:24:22 <omiday> ok got it, thanks (again)
17:24:24 <adamw> npnp :)
17:24:53 <adamw> ok, so that's all the blockers
17:24:54 <tflink> ack
17:25:00 <adamw> er, proposed blockers
17:25:06 <tflink> bah, misread
17:25:23 <adamw> let's do a quick sweep through the accepted blockers and see where we're at...
17:25:27 <adamw> #info moving on to accepted blockers
17:25:31 <adamw> #topic (1318045) Incorrect keymap when decrypting encrypted partitions
17:25:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1318045
17:25:32 <adamw> #info Accepted Blocker, anaconda, NEW
17:25:40 <adamw> we probably need to upload more logs for this
17:25:53 <adamw> we know basically what's going on, it's just a question of co-operative debugging to figure out the underlying causes
17:26:11 <adamw> #info we need QA and anaconda team to work together and isolate the underlying causes here, more logs may be needed
17:26:22 <adamw> any other notes?
17:26:27 * kparal agrees
17:28:07 <adamw> #topic (1333998) After Russian install, console keymap is 'us', not 'ru'
17:28:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1333998
17:28:07 <adamw> #info Accepted Blocker, anaconda, NEW
17:28:22 <adamw> kinda similar story, we have a rough idea what's going on and need to isolate why and what the fix should be...
17:28:28 <adamw> at least the relevant people are all involved i think
17:28:58 <adamw> #info once again this one needs more investigation from both qa and anaconda side, might need to pin down last time it worked (if ever)
17:29:11 <adamw> well...i'm pretty sure it worked sometime.
17:29:31 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1164492
17:29:32 <adamw> grrr
17:31:06 <adamw> alrighty, next one
17:31:13 <adamw> #topic (1164492) Please drop libvirt 'default' network dependency for F24 GA, disrupts livecd networking
17:31:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1164492
17:31:13 <adamw> #info Accepted Blocker, gnome-boxes, NEW
17:31:25 <adamw> #info looks like this will get done soon, though there's ongoing discussion about how to fix the bug better
17:32:27 <adamw> anything else?
17:33:36 <adamw> alrighty
17:33:41 <adamw> #topic (1320273) chainloading bootmgr.efi on UEFI results in error: out of memory
17:33:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1320273
17:33:42 <adamw> #info Accepted Blocker, grub2, NEW
17:34:09 <adamw> this one's a little worrying
17:34:18 <adamw> i'll take an action to ping pjones and mjg59 about it
17:34:27 <adamw> #info there has been no movement on this for some time
17:34:36 <adamw> #action adamw to ping pjones and mjg59 about this bug
17:35:40 <adamw> #topic (1293167) [abrt] kf5-kinit: qt_message_fatal(): kdeinit5 killed by SIGABRT
17:35:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1293167
17:35:41 <adamw> #info Accepted Blocker, kf5-kinit, NEW
17:36:17 <adamw> i'm wondering if we might want to re-evaluate this in light of https://bugzilla.redhat.com/show_bug.cgi?id=1293167#c23 ...
17:36:19 <adamw> any thoughts?
17:36:57 * omiday reading...
17:38:49 <omiday> it appears that we need to ping Rex
17:38:53 * kparal brb
17:39:35 <omiday> everyone has it running but the most-important-user ;)
17:41:18 <omiday> c15 confirmed the bug on Apr-3 - have there been any updates since then?
17:41:22 <adamw> well, i guess we don't really have enough people to re-consider it at present, but we can keep an eye and think about it later...
17:41:26 <adamw> omiday: yes. that's what i linked to.
17:41:42 <adamw> omiday: what i linked to is a comment where rex said he asked on some mailing lists and most people who replied said it worked.
17:42:29 <omiday> adamw: so is everyone on the list running the same stack as Rex and Giulio? If so, why did their tests fail?
17:43:02 <omiday> I've got the KDE VM from calligrawords test - could give it a shot...
17:43:14 <adamw> i dunno. i just work here.
17:43:22 <adamw> okay, well, let's just #info it and move on
17:43:53 <adamw> #info there hasn't been a lot of movement in terms of fixing this bug, but some further testing suggests it may not be as clearly reproducible as first thought, we may consider re-evaluating it later
17:44:01 <adamw> #topic (1333106) Server deployment fails due to SELinux policy changes on current Fedora Rawhide and F24 (2016-05-21)
17:44:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1333106
17:44:01 <adamw> #info Accepted Blocker, selinux-policy, ASSIGNED
17:44:17 <adamw> #info this one is being worked on by appropriate folks, and we're ready to re-test it when fixes are available
17:44:40 <adamw> ok, that's all the accepted blockers...
17:45:14 <adamw> #info that's all the accepted blockers, no need to do proposed FEs yet as we still have another meeting before freeze date
17:45:17 <adamw> #topic Open floor
17:45:19 <adamw> any other business?
17:46:26 <omiday> when is the next meeting?
17:46:42 <adamw> same time same place next week
17:47:29 <omiday> the just so I understand how all this works: if I test https://bugzilla.redhat.com/show_bug.cgi?id=1293167 and it passes what's the process?
17:48:50 <adamw> post a comment on the bug saying you tried it and it worked for you
17:49:22 <omiday> adamw: ack
17:49:32 <omiday> nothing else here
17:49:37 <adamw> alrighty
17:49:41 <adamw> i think we bored everyone else to death
17:49:45 <adamw> thanks for sticking around =)
17:49:51 <adamw> thanks for coming, everyone!
17:49:57 <adamw> i'm off to lie around on the couch and watch tennis
17:50:08 <coremodule> adamw, No problemo!
17:50:12 <omiday> raining?
17:50:22 <adamw> lazy
17:50:45 <adamw> #endmeeting