16:00:07 <roshi> #startmeeting F26-blocker-review
16:00:07 <zodbot> Meeting started Mon May  8 16:00:07 2017 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:07 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:00:08 <roshi> #meetingname F26-blocker-review
16:00:08 <zodbot> The meeting name has been set to 'f26-blocker-review'
16:00:08 <roshi> #topic Roll Call
16:00:28 <roshi> who's around for some blocker review time!?
16:01:13 <adamw> ahoyhoyhoy
16:01:16 * adamw is!
16:01:22 <roshi> yeah buddy!
16:01:29 <roshi> #chair adamw
16:01:29 <zodbot> Current chairs: adamw roshi
16:02:59 <adamw> blocker bug best buds!
16:03:05 <roshi> :D
16:03:48 <adamw> i spammed a few channels
16:04:15 <adamw> sgallagh: tflink: danofsatx: amita: nirik: pwhalen: satellit: ping
16:04:41 * tflink is otherwise occupied today
16:04:44 <sgallagh> .hello sgallagh
16:04:45 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:05:19 <roshi> #chair sgallagh
16:05:19 <zodbot> Current chairs: adamw roshi sgallagh
16:05:44 <roshi> well, suppose we can get started with we three
16:05:53 <roshi> #topic Introduction
16:05:53 <roshi> Why are we here?
16:05:53 <roshi> #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:05:57 <roshi> #info We'll be following the process outlined at:
16:05:59 <roshi> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:02 <roshi> #info The bugs up for review today are available at:
16:06:04 <roshi> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:07 <roshi> #info The criteria for release blocking bugs can be found at:
16:06:09 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria
16:06:12 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
16:06:15 <roshi> #link https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria
16:06:36 <roshi> we've only 4 proposals to go through, so should be quick
16:06:40 <roshi> first up...
16:06:40 <roshi> #topic (1447777) Since curl-7.53.1-7.fc26 , curl TLS transactions in initramfs environment are broken
16:06:44 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1447777
16:06:46 <roshi> #info Proposed Blocker, dracut, POST
16:08:36 <roshi> welcome Southern_Gentlem
16:08:37 <adamw> this seems a pretty obvious +1
16:08:43 <roshi> #chair Southern_Gentlem
16:08:43 <zodbot> Current chairs: Southern_Gentlem adamw roshi sgallagh
16:09:18 <sgallagh> It's not technically a violation as written. (The criteria only cite HTTP). That said, it's pretty important to fix.
16:09:26 <roshi> seems that way for me
16:09:40 <Southern_Gentlem> doesnt this effect dnf as well
16:09:57 <roshi> adamw: can you take over for a second?
16:10:01 <roshi> brb
16:11:09 <adamw> sure sure
16:11:19 <sgallagh> I'm +1 to block on this, I guess.
16:11:23 <adamw> sgallagh: as the person who wrote that criterion, it's not intended to be 'HTTP not HTTPS'
16:11:25 <Southern_Gentlem> +1
16:11:27 * pwhalen is here
16:11:34 <pwhalen> +1
16:11:39 <sgallagh> It's kind of academic at this point anyway.
16:11:40 <adamw> it was just 'http not ftp or nfs'
16:12:14 <adamw> we can clarify the criterion, but i'd say the intent would be for this to block
16:12:23 <sgallagh> I voted +1
16:12:30 <adamw> yep, just clarifying
16:13:44 <adamw> proposed #agreed 1447777 - AcceptedBlocker (Beta) - this is a violation of "The installer must be able to download and use an installer update image from an HTTP server" (note: 'HTTP' there is meant as 'HTTP not FTP or NFS', it does not mean 'we don't expect HTTPS to work')
16:14:27 <pwhalen> ack
16:14:31 <Southern_Gentlem> ack
16:14:51 <sgallagh> ack
16:15:19 <adamw> #agreed 1447777 - AcceptedBlocker (Beta) - this is a violation of "The installer must be able to download and use an installer update image from an HTTP server" (note: 'HTTP' there is meant as 'HTTP not FTP or NFS', it does not mean 'we don't expect HTTPS to work')
16:15:35 <adamw> #topic (1443938) Firefox 53 - Second arches build failure
16:15:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1443938
16:15:35 <adamw> #info Proposed Blocker, firefox, NEW
16:15:48 <roshi> back, thanks
16:16:23 <adamw> hi kevin
16:17:05 <pwhalen> +1
16:17:10 <adamw> um
16:17:21 <adamw> i'm confused, here. if the package didn't build, the old package should still be tagged.
16:17:25 <sgallagh> What criterion is this violating, exactly?
16:17:27 <adamw> so what's the blocker here?
16:17:55 <pwhalen> maintainer made it intel only, we dont get armhfp xfce image anymore as a result
16:18:11 <roshi> image or firefox?
16:18:13 <adamw> oh crap, i see
16:18:20 <sgallagh> Made Firefox intel-only?
16:18:22 <pwhalen> roshi, ff
16:18:28 <adamw> sgallagh: https://koji.fedoraproject.org/koji/buildinfo?buildID=881361
16:18:28 <sgallagh> Hmm
16:18:39 <adamw> the maintainer did a build with non-x86 arches disabled
16:18:43 <adamw> he really should not have done that
16:18:52 <pwhalen> happened in alpha too
16:19:03 <adamw> sigh. we'll have to get someone to explain to martin
16:19:26 <adamw> so +1, since it does not seem reasonable to say 'we'll ship ARM with some other browser or no browser'
16:19:56 <sgallagh> Is there a strict requirement for a browser on the media?
16:20:11 <sgallagh> I thought it was just "default apps must work"
16:20:56 <Southern_Gentlem> sgallagh, and wouldnt ff be a default app?
16:21:01 <adamw> alpha: "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments."
16:21:09 <adamw> this implies there must *be* a 'default web browser'
16:21:15 <roshi> it is - but ff is the default
16:21:35 <Southern_Gentlem> +1
16:21:40 <roshi> +1
16:21:52 <adamw> i mean, technically we can file a bug saying "the xfce spin has no default browser on arm" and there could be a resolution besides "fix the ff build for arm" (i.e. switch xfce's default to something else) but do we really want to do that?
16:22:25 <sgallagh> I think we probably have to rule this blocker decision that way
16:22:54 <sgallagh> Because if FF really is broken upstream for some arches, we probably need to switch defaults.
16:23:27 <roshi> proposed #agreed - RHBZ#1443938 - AcceptedBlocker - This bug is a conditional violation of the following criterion: "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments."
16:23:35 <sgallagh> (Also, we could *really* hedge and declare elinks or something to be default on ARM...)
16:23:44 <adamw> it can't be just for ARM, really.
16:23:44 <pwhalen> :/
16:23:52 <adamw> we can't define package sets by arch in that way.
16:23:58 <sgallagh> roshi: I'm not sure we are in agreement yet
16:23:59 <roshi> it's whatever the default is in the DE
16:24:08 <adamw> whatever it was, would also be the 'default browser' for xfce on x86_64. which isn't blocking, but still
16:24:14 <sgallagh> roshi: right, which is a comps change.
16:24:18 <roshi> I think we're in agreement that this *issue* blocks - just not on the fix
16:24:37 <adamw> roshi: i think sgallagh is arguing that the blocker bug should be "there's no default browser on Xfce ARM"
16:24:50 <adamw> which allows the resolution of "change the default browser", rather than "fix firefox".
16:24:51 <sgallagh> Well, I want whatever our statement is to make it clear that there's more than one way to unblock
16:25:02 <sgallagh> adamw: yes
16:25:10 * roshi is fine with file new bug and block on that - however, people will expect ff on arm
16:25:29 <pwhalen> roshi, agreed, and ff is the default on a few desktops
16:25:29 <adamw> which, i mean, i'm fine with, it just involves more work, and yeah, i think that would be a pretty shitty resolution
16:25:33 <sgallagh> I don't want to hamstring us in case there is a genuine problem with upstream here
16:25:53 <roshi> fair
16:25:56 <adamw> it's pretty hard to argue we'd do this for x86_64, so we'd be treating ARM as a second-class citizen if we did it
16:25:56 <pwhalen> perhaps we should see if it is. for alpha it was fixed
16:25:59 <adamw> which we're not supposed to do
16:26:12 <roshi> but I also don't see mozilla saying they don't care about the other arches and this problem lingering
16:26:23 <roshi> right
16:26:29 <adamw> but i'm okay to go with the 'file a different bug and +1 it' route.
16:26:39 <pwhalen> the suggestion to change the browser seems premature
16:26:44 <sgallagh> roshi: I can totally see them deciding not to support 32-bit entirely, for example
16:26:57 <roshi> but not arm
16:26:58 <adamw> pwhalen: it's not a *suggestion*, per se, just a recognition that the blocker issue is not technically 'firefox doesn't build'
16:27:20 <adamw> sgallagh: why don't you file a new bug while we paint the bike shed :)
16:27:21 <roshi> is what I'm saying - even if it is an upstream issue, there's momentum behind arm, I don't see them dropping it
16:27:31 <sgallagh> I'm not saying we should change the browser, just that we shouldn't close that off as an option to avoid a slip
16:27:51 <roshi> I don't see how blocking on this closes that door?
16:28:01 <sgallagh> adamw: I'm currently on my phone at lunch, so I can't.
16:28:01 <pwhalen> nor I
16:28:12 <roshi> I mean, if we decide to go that way we just update the bug with a note to the discussion
16:28:12 <adamw> fine, i'll do it
16:28:21 <sgallagh> roshi: the criterion we list carries implications
16:28:39 <adamw> roshi: the thing is, we *do* need a bug for "firefox doesn't build on ARM"
16:28:45 <adamw> that in itself clearly *is* a bug
16:29:00 <adamw> but we can't mark that bug as the release blocker and say "oh but the release blocking issue is _really_ that there's no default browser on Xfce ARM"
16:29:09 <adamw> it's confusing and unclear
16:29:30 <adamw> i'll file a new bug.
16:29:35 * roshi shrugs - I didn't think it was confusing
16:30:25 <roshi> if the bug was "no default apps get installed" we'd block on this, and this bug is just a subset of that - since there'd be no ff to install
16:30:34 <adamw> it's not a subset of that
16:30:40 <adamw> because 'that' could be fixed without this being fixed
16:31:02 <adamw> if we change the xfce package set to use, say, epiphany, then the bug "there is no default browser on xfce" gets fixed, but the bug "firefox does not build on arm" is *not* fixed
16:31:27 <adamw> pwhalen: does xfce ARM actually fail to compose right now? i'd guess that'd be the result?
16:31:39 <roshi> but doesn't the "default application" list come from xfce, not from what we decide?
16:31:46 <nirik> actually midori is still "default" for some values...
16:31:47 <sgallagh> No
16:31:59 <pwhalen> adamw, yes, as does any desktop needing firefox
16:32:00 <adamw> yeah, it does.
16:32:01 <roshi> I mean, if you changed the comps for gnome to all kde apps, would we then say that the gnome defaults work because it's defined in comps?
16:32:20 <adamw> roshi: i don't think upstream firefox defines a default browser.
16:32:21 <adamw> er
16:32:22 <sgallagh> It comes from whatever we put in the comps entry that is used to compose the media
16:32:23 <adamw> upstream xfce
16:32:38 <roshi> then the xfce sig?
16:32:51 <nirik> both firefox and midori are shipped.
16:33:03 <nirik> but if you click the little "browser" button you get midori I think...
16:33:09 <sgallagh> roshi: yeah, which is who would make the decision for whether to drop FF if it couldn't be fixed.
16:33:43 <nirik> The Xfce sig. But we added it because lots of people wanted it.
16:34:15 <sgallagh> nirik: if thats the case, I'd argue Midori is the real default.
16:34:24 <nirik> yes, I would think thats reasonable
16:34:29 <sgallagh> And the blocker bug here is "XFCE spin doesn't compose"
16:34:56 <nirik> sure, but we want to include firefox... so they should fix things
16:35:13 <nirik> and in the past they have pretty quickly
16:35:35 <sgallagh> Yes, I agree. But that's not *blocking*
16:35:46 <sgallagh> Which is the only part we care about in this meeting
16:35:55 <roshi> xfce not composing is blocking because of arm
16:35:56 <nirik> I suppose.
16:35:59 <nirik> I know
16:36:09 <roshi> so midori is the default browser
16:36:12 * nirik has to leave... hackfest is heading to lunch
16:36:13 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1448923
16:36:19 <nirik> file the bugs. I will deal with it somehow.
16:36:20 <roshi> ff is a nice add-on
16:36:28 <roshi> thanks nirik !
16:36:33 <adamw> so, move that we transfer the blocker nomination to that bug>?
16:36:35 <pwhalen> i dont think midori is on the images
16:36:41 <roshi> works for me
16:36:51 <adamw> pwhalen: but we could change that. theoretically. the option exists.
16:36:53 <sgallagh> adamw: agreed
16:37:05 <pwhalen> no , there were issues with midori on arm.
16:37:21 <sgallagh> We don't have to solve the problem here
16:37:25 <pwhalen> ff was more active, the change was good for us
16:37:41 <sgallagh> As long as the image starts to compose again, how it happens is irrelevant
16:37:50 <sgallagh> (To the blocker decision)
16:37:58 <adamw> pwhalen: i'm not saying that's what we *ought* to do. but the point is that the possibility exists, so the blocker bug should be "xfce fails to compose and its current default browser isn't available", not "firefox doesn't build".
16:37:58 <pwhalen> would we change the broswer if this was x86?
16:38:37 <sgallagh> pwhalen: Hypothetically, Chromium is in the repo now...
16:39:01 <adamw> probably not, but it would still be more correct to have the blocker bug be an accurate definition of the actual criteria violation.
16:39:10 <sgallagh> Yes, what he said
16:40:50 <adamw> sgallagh: it's not quite "as long as the image starts to compose again", it's "as long as the image starts to compose again with a 'default browser'"
16:40:53 <roshi> ok +1 to 1448923 as blocker, add a note to 1443938 referencing the blocker
16:41:41 <sgallagh> adamw: Right, I abbreviated.
16:42:06 <sgallagh> +1 like roshi just said
16:42:48 <adamw> pwhalen, are you okay with that?
16:42:52 <pwhalen> i dont think we should open the suggestion to change the default.
16:43:30 <pwhalen> its the default on most desktops. we'd lose all of those for arm
16:44:30 <sgallagh> We don't need to include that in the blocker decision message
16:44:39 <roshi> I'm in strong support of fixing FF for this, fwiw
16:45:02 <sgallagh> I just want it clear that the issues we are blocking on are "Doesn't compose" and (possibly) "has no functional default browser"
16:45:10 <roshi> I see the "change the default" as counterproductive for our ARM presense
16:45:34 <roshi> which might be why I'm confused as to why this is confusing, I guess
16:45:36 <adamw> pwhalen: having the new bug as the blocker does not imply support for changing the default
16:45:40 <sgallagh> I am also strongly in favor of fixing Firefox rather than changing the default
16:46:12 <sgallagh> But I'd choose "switch to Midori" over "slip all of Fedora" if it became clear that Firefox could not be fixed in a reasonable timeframe
16:46:31 <pwhalen> adamw, it was suggested as an alternative option in the bug which to me seems to early to consider
16:46:36 <roshi> so we added a bug and a level of obfuscation from the actual issue (IMO) for a thing none of us actually wants to do (change the default)
16:46:39 <pwhalen> *too
16:46:47 <roshi> ?
16:46:55 <roshi> that's what it's seeming like to me
16:47:27 <adamw> roshi: well, yes, because sgallagh and i think it's important to accurately describe the blocking issue.
16:47:31 <adamw> but we're going in circles here
16:47:52 <Amita> hello adamw
16:47:53 * roshi would have just put the details in the acceptedBlocker comment to make it clear
16:47:54 <Amita> hi everyone
16:47:55 <adamw> we basically have something like +3/-1 for each bug, with a different +3 and a different reason for the -1.
16:48:00 <roshi> welcome Amita
16:48:19 <roshi> adamw: want to take a stab at the proposed?
16:48:31 <adamw> well not really cos i don't know which one to propose. :P
16:48:40 <adamw> can i just toss a damn coin or something?
16:48:41 <roshi> that's what I asked you for
16:48:42 * sgallagh will make an attempt
16:48:47 <roshi> :p
16:48:51 <roshi> since I don't know either
16:48:52 <adamw> if we're going to propose the other bug, we have to change the topic.
16:49:03 <pwhalen> im ok with changing the title of it
16:49:15 <roshi> so propose against the shadow bug we just created I guess
16:49:28 <adamw> it doesn't make sense to me to change the title of the 'fails to build on arm' bug because we *do* need a 'firefox fails to build on arm' bug.
16:49:39 <roshi> right
16:49:45 <adamw> if we fix the 'no default browser / image fails to compose' bug by making firefox build on ARM again, we just close both bugs at once.
16:49:59 <roshi> I thought we were meaning the title of the room right now so logs get generated correctly
16:50:13 <sgallagh> Proposed: BZ 1448923 is accepted as a blocker on the grounds that it causes a release-blocking image to fail to compose. BZ 1443938 is rejected as a blocker because it does not violate any specific criteria.
16:50:15 <adamw> that's what i meant, but i don't think it's what pwhalen meant :P
16:50:24 <pwhalen> right, misunderstood :)
16:50:43 <adamw> sgallagh: i agree with the sentiment, but we should do it by unproposing this bug with a #info and switching the topic to the new bug.
16:50:59 <adamw> sigh, i love bug bureaucracy
16:51:07 <sgallagh> adamw: Un-proposing or rejecting?
16:51:07 <pwhalen> someone does
16:51:15 <roshi> hey, I did promise blocker funtimes, remember?
16:52:44 <adamw> sgallagh: meh, either way.
16:52:59 <sgallagh> Proposed: BZ 1443938 is rejected as a blocker because it does not violate any specific criteria.
16:53:58 <roshi> ack
16:54:07 <Southern_Gentlem> ack
16:54:15 * roshi still thinks it's causally a blocker though :p
16:54:17 <adamw> propose #agreed #1443938 - RejectedBlocker (Beta) - this is rejected in favour of the alternative proposal #1448923 , which more precisely reflects the actual criteria violation
16:54:20 <pwhalen> well, it did
16:54:28 <adamw> (just a bit cleaner than sgallagh's proposal)
16:54:35 <roshi> ack
16:54:38 <pwhalen> ack adamw
16:54:38 <Southern_Gentlem> +1
16:54:40 <Southern_Gentlem> ack
16:54:41 <sgallagh> adamw: ack
16:54:54 <adamw> #agreed #1443938 - RejectedBlocker (Beta) - this is rejected in favour of the alternative proposal #1448923 , which more precisely reflects the actual criteria violation
16:55:02 <Southern_Gentlem> (crp by committee is always interesting )
16:55:03 <adamw> roshi: OK, I proposed the other one so we can go ahead and switch to it now?
16:55:07 <adamw> Southern_Gentlem: right? :P
16:56:46 <roshi> #topic (1448923) Xfce ARM image default browser is unavailable (image fails to build)
16:57:01 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1448923
16:58:21 <pwhalen> +1
16:58:22 <sgallagh> +1 blocker
16:58:35 <adamw> +1
16:59:02 <roshi> +1
16:59:14 <Southern_Gentlem> (crp by committee is always interesting )
16:59:16 <Southern_Gentlem> +1
16:59:52 <roshi> proposed #agreed - RHBZ#1448923 - AcceptedBlocker - This bug is a conditional violation of the following criterion: "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments."
17:00:17 <adamw> mention the 'image fails to compose' criterion too?
17:00:30 * roshi thought about that
17:01:34 <roshi> proposed #agreed - RHBZ#1448923 - AcceptedBlocker - This bug is a conditional violation of the following criterion: "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments." as well as the "image compose" criterion.
17:01:43 <adamw> ack
17:01:49 <pwhalen> ack
17:02:31 <roshi> #agreed - RHBZ#1448923 - AcceptedBlocker - This bug is a conditional violation of the following criterion: "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments." as well as the "image compose" criterion.
17:02:52 <roshi> well, glad that's decided
17:03:00 <roshi> onto the next!
17:03:01 <roshi> #topic (1348688) Anaconda cannot access LVM partitions in a LUKS-encrypted disk partition after decryption
17:03:04 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1348688
17:03:05 * adamw wipes forehead
17:03:06 <roshi> #info Proposed Blocker, lvm2, POST
17:08:07 <adamw> the criterion here would, I guess, be Beta " Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions
17:08:07 <adamw> Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions "
17:09:55 <adamw> this one's new to me, but it reads like a violation of that...
17:10:06 <roshi> that's what I was thinking
17:11:19 <adamw> especially since it's claimed even the workaround doesn't work on f26
17:11:26 <roshi> +1
17:13:10 <adamw> so yeah, +1 for now
17:14:13 <adamw> anyone else still alive out there, or are we suffering a plague of terminal blocker fatigue?
17:14:42 <pwhalen> +1
17:14:45 <roshi> lol
17:15:23 <roshi> proposed #agreed - RHBZ#1348688 - AcceptedBlocker - This bug is a clear violation of the following criterion: "Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table..."
17:15:42 <adamw> patch
17:15:52 <roshi> go for it
17:16:18 <Southern_Gentlem> +
17:16:20 <Southern_Gentlem> 1
17:16:23 <adamw> proposed #agreed - RHBZ#1348688 - AcceptedBlocker - This bug is a violation of the Beta criterion: "When using the custom partitioning flow, the installer must be able to: ... Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table..."
17:16:43 <roshi> ack
17:16:45 <pwhalen> ack
17:17:00 <Southern_Gentlem> ack
17:18:44 <adamw> ooh, sorry
17:18:46 <adamw> that was my proposal :P
17:18:50 <adamw> #agreed - RHBZ#1348688 - AcceptedBlocker - This bug is a violation of the Beta criterion: "When using the custom partitioning flow, the installer must be able to: ... Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table..."
17:19:37 * roshi just finished typing out your bits too :p
17:19:44 <roshi> last one!
17:19:45 <roshi> #topic (1227736) Minimal grub after a kernel update with gnome-software
17:19:48 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1227736
17:19:51 <roshi> #info Proposed Blocker, plymouth, NEW
17:20:51 <halfline> sorry I still need to investigate this issue ^
17:21:00 <roshi> ah, the Punted One
17:22:28 <adamw> i did ping people on this one
17:23:19 <adamw> zbigniew and ray (halfline) both responded and seem interested in addressing this
17:23:35 <adamw> zbigniew says "I'd think it's rather FE or at most Final material, because the setup
17:23:35 <adamw> is non-default, the fix is rather complex, and apparently the issue is
17:23:35 <adamw> not that very common, and it's not a regression."
17:23:41 <adamw> halfline, what's your opinion on blockeriness?
17:27:22 <adamw> bueller?
17:27:49 <adamw> welp, i'm -1 beta based on what we know from the bug report and the feedback i had by mail.
17:27:56 <roshi> wfm
17:28:37 <nb> -1 blocker, it sounds like
17:28:59 <nb> can we make it +1 FE?
17:30:51 <roshi> proposed #agreed - RHBZ#1227736 - RejectedBlocker - This bug doesn't qualify as a blocker due to the fact that it's a non-default installation method as well as how invasive the fix is.
17:30:59 <nb> ack
17:31:31 <adamw> for something like this i think i'd want to see a proposed fix or at least have more concrete info on what it would be before voting for FE
17:31:36 <nb> true
17:31:39 <nb> good point
17:32:30 <adamw> ack
17:33:02 <roshi> #agreed - RHBZ#1227736 - RejectedBlocker - This bug doesn't qualify as a blocker due to the fact that it's a non-default installation method as well as how invasive the fix is.
17:33:08 <roshi> that's all we have for today
17:33:21 <roshi> there are some proposed FEs for Final, but I don't see a reason to do those now
17:33:31 <roshi> ah
17:33:32 <adamw> agreed
17:33:36 <roshi> guess there's a FE for beta
17:33:49 <roshi> #topic (1444654) Moving a file using Drag and Drop onto a folder works immediately the first time in nautilus, takes time subsequently.
17:33:52 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1444654
17:33:55 <roshi> #info Proposed Freeze Exceptions, nautilus, NEW
17:34:00 <roshi> we're close to freeze, so might as well
17:34:55 <adamw> sure
17:35:10 <roshi> +1 punt until we have a fix to look at
17:35:25 <roshi> I really should use a mouse more to catch these things
17:35:35 <adamw> huh, funny bug
17:35:46 <roshi> as my drag and drop is mv <tab-completion> <tab-completion>
17:36:05 <adamw> but yeah, i think i agree, this one would depend on how tricky the fix is
17:38:05 * roshi waits for a couple more votes...
17:38:28 <adamw> nb: pwhalen: sgallagh: southern_gentlem:
17:38:29 <pwhalen> +1 punt wfm
17:38:36 <roshi> proposed #agreed - RHBZ#1444654 - Punt - Before we can vote on this we need a proposed fix so we can see how tricky it is.
17:39:14 <pwhalen> ack
17:39:20 * nb looks
17:39:29 <nb> ack
17:40:26 <adamw> ack
17:41:01 <Southern_Gentlem> +1 punt
17:41:07 <Southern_Gentlem> ack
17:41:38 <roshi> #agreed - RHBZ#1444654 - Punt - Before we can vote on this we need a proposed fix so we can see how tricky it is.
17:41:42 <roshi> #topic Open Floor
17:41:53 <roshi> anyone have anything?
17:42:06 <pwhalen> not I
17:42:14 <adamw> nope
17:42:33 <roshi> thanks for coming everyone!
17:42:39 * roshi sets the fuse...
17:42:40 <roshi> 3...
17:43:12 <pwhalen> thanks roshi!
17:43:13 * adamw runs dramatically, in slow motion
17:43:25 <adamw> cameraperson! wide shot!
17:43:40 <roshi> 2...
17:43:41 * pwhalen is diving behind some 'containers'
17:44:02 <roshi> (little do they know I'm on an atomic host! bwahahaha)
17:44:04 <roshi> 1...
17:44:09 <roshi> #endmeeting