16:03:34 <adamw> #startmeeting F30-blocker-review
16:03:34 <zodbot> Meeting started Mon Mar 18 16:03:34 2019 UTC.
16:03:34 <zodbot> This meeting is logged and archived in a public location.
16:03:34 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:34 <zodbot> The meeting name has been set to 'f30-blocker-review'
16:03:34 <adamw> #meetingname F30-blocker-review
16:03:34 <zodbot> The meeting name has been set to 'f30-blocker-review'
16:03:34 <adamw> #topic Roll Call
16:03:46 <adamw> wahay, we have zodbot
16:03:56 <adamw> so, who's around for some blocker review fun? or alternatively, blocker review not fun?
16:03:56 <frantisekz> .hello2
16:03:57 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:03:59 <bcotton> zodbot++
16:04:02 <bcotton> .hello2
16:04:03 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:04:13 * bcotton has to cut out in about 90 minutes
16:04:22 <frantisekz> hmm.... so many people ... :D
16:04:43 * coremodule is here.
16:04:46 * sgallagh is semi-here
16:04:50 <sgallagh> Also in FESCo meeting
16:04:57 <coremodule> I can be the secretary for the meeting.
16:05:07 <adamw> thanks coremodule
16:05:19 <adamw> sgallagh: man, we have to get you out of this 'fesco' thing that keeps conflicting
16:05:22 <adamw> it can't be that important
16:05:42 * sgallagh shakes his head
16:05:50 <adamw> #chair frantisekz bcotton
16:05:50 <zodbot> Current chairs: adamw bcotton frantisekz
16:06:03 * bcotton has the power!
16:06:05 <adamw> impending boilerplate alert!
16:06:06 <adamw> #topic Introduction
16:06:06 <adamw> Why are we here?
16:06:06 <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:06:08 <adamw> #info We'll be following the process outlined at:
16:06:08 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:06:10 <adamw> #info The bugs up for review today are available at:
16:06:11 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:06:13 <adamw> #info The criteria for release blocking bugs can be found at:
16:06:15 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:06:17 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria
16:06:19 <adamw> #link https://fedoraproject.org/wiki/Fedora_30_Final_Release_Criteria
16:06:37 <adamw> #info for Beta, we have:
16:06:38 <adamw> #info 2 Proposed Blockers
16:06:43 <adamw> #info 3 Accepted Blockers
16:06:48 <adamw> #info 3 Proposed Freeze Exceptions
16:06:48 <adamw> #info 6 Accepted Freeze Exceptions
16:06:57 <adamw> #info there are no Final proposals
16:07:05 <adamw> #info coremodule will secretarialize
16:07:17 <adamw> so without further ado...
16:07:23 <adamw> #info we'll start with the proposed Beta blockers
16:07:31 <adamw> #topic (1648907) grub2-common kernel.d plugin removes $ESP/<machine-id>/ directory rendering machine unbootable
16:07:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1648907
16:07:31 <adamw> #info Proposed Blocker, grub2, POST
16:08:15 <cmurf> +1 blocker :D
16:08:17 <adamw> so...this affects people who use systemd-boot
16:08:18 <cmurf> i am not voting twice
16:08:19 <adamw> which is not default
16:08:34 <adamw> but if you *do* decide to use it, then you upgrade to fedora 30...your system doesn't boot any  more. this seems bad
16:08:37 <cmurf> or maybe I am if it's just adamw and I
16:09:06 <adamw> in the bug I proposed accepting it under a provision we don't often use:
16:09:07 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1648907#c6
16:09:31 <adamw> see https://fedoraproject.org/wiki/Fedora_30_Beta_Release_Criteria#Beta_Blocker_Bugs for that
16:09:35 <frantisekz> yeah, sounds like +1 :)
16:09:46 <cmurf> is there any reason to consider blocking it for final instead of beta?
16:09:54 <bcotton> i understand the logic, but also there are a lot of non-default ways to hose your boot
16:10:27 <bcotton> i think i'd be 0 beta blocker and +1 final blocker from the "if this were the only blocker, would we delay the release?" standpoint
16:10:52 <sgallagh> Yeah, I agree with bcotton here. If this was the only thing stopping Beta from going out the door, I'd not call it a blocker.
16:11:05 <cmurf> bcotton: true but there is an unfortunate irony in that the Fedora BLS feature is taking the spec from the systemd-boot folks, modifying it, and now stepping on systemd-boot
16:11:26 <adamw> i'm fairly sure there *isn't* an irony threshold for blockers. :P
16:11:33 <sgallagh> I honestly might not even call it a Final blocker, since the only way to get into this situation is to intentionally change your bootloader, which is absolutely not something that people do without deep technical knowledge.
16:11:57 <adamw> i think i'm still at least +1 final blocker. i don't think it's reasonable to know about this bug and ship a release without fixing it.
16:12:02 * satellit_ listening late
16:12:11 <cmurf> I don't think Fedora should be a bull in a China shop
16:12:14 <sgallagh> I'm -1 Beta Blocker, -1 Beta FE
16:12:15 <bcotton> adamw: if Alanis Morrissette starts singing about a proposed blocker, I'd +1 on that
16:12:22 <adamw> sgallagh: -1 FE?
16:12:25 <sgallagh> Yes
16:12:32 <cmurf> hey let's borrow that spec, change it, and oopsie!
16:12:35 <sgallagh> I don't want any "fix" for this breaking the bootloader.
16:12:48 <sgallagh> If it works today for standard usage, let's not destabilize that
16:13:04 <adamw> i mean, if we refuse an FE they're just going to push it stable immediately after beta anyway, so if it breaks the bootloader, it's still gonna.
16:13:04 <bcotton> i agree with sgallagh, let's not risk breaking the bootloader for everyone by fixing a non-default case
16:13:16 <cmurf> ok we're already changing the bootloader functionality in Fedora 30 in the single most significant way ever since moving to grub2
16:13:21 <adamw> only we won't find out about it until someone complains in the update feedback...
16:13:36 <cmurf> I would sooner say revert the BLS feature...
16:14:19 <cmurf> the Workstation WG last meeting brought up the BLS feature bugs during upgrades and wonder if it should be pushed to Fedora 31
16:14:42 <bcotton> so thursday is the go/no-go meeting. which means we'd really like to have a candidate composite today or tomorrow, so unless they fix it while we're arguing, it's sort of a moot point anyway. if we're no-go on Thursday then they have more time to get it in and tested
16:14:51 <bcotton> i'm not sure which position i'm arguing for here, actually
16:15:22 <cmurf> I can totally accept beta users getting bootloader nerfed
16:15:24 <cmurf> but not for final
16:15:40 <cmurf> beta users ^who experiment with systemd-boot or any other bootloader
16:15:46 <sgallagh> adamw: If it lands after the Beta, it doesn't delay Beta.
16:16:08 <sgallagh> They have time to fix it without derailing the release train in that case
16:16:22 <cmurf> i'm OK with that
16:16:35 <adamw> okay, so, what does everyone else vote?
16:16:36 <bcotton> okay, i'll say my vote unqualified
16:16:43 <bcotton> -1 beta blocker, +1 final blocker
16:16:57 <frantisekz> -1 beta blocker... changed my mind a little
16:17:14 <bcotton> -1 beta FE too, if we're asking about that
16:17:27 <sgallagh> -1 beta blocker, -1 beta FE, 0 Final Blocker right now. (I could be persuaded on Final)
16:17:34 <cmurf> baring a compelling contra argument, -1 beta blocker, -1 beta FE; +1 final blocker
16:18:28 <adamw> we need votes for beta blocker and FE at this poin
16:18:38 <adamw> we don't necessarily need to decide on final blocker right now.
16:18:49 <cmurf> fair enough
16:18:50 <frantisekz> -1/-1 for beta then
16:20:51 <adamw> proposed #agreed 1648907 - RejectedBlocker RejectedFreezeException (Beta) - as this does not involve a default or supported bootloader, and the change required looks like it could break stuff badly if it goes wrong, we agreed this is not a blocker for Beta and the risk of taking the change as an FE is too high
16:21:05 <sgallagh> ack
16:21:14 <frantisekz> ack
16:21:44 <bcotton> ack
16:22:26 <adamw> #agreed 1648907 - RejectedBlocker (Beta) RejectedFreezeException (Beta) - as this does not involve a default or supported bootloader, and the change required looks like it could break stuff badly if it goes wrong, we agreed this is not a blocker for Beta and the risk of taking the change as an FE is too high
16:22:38 <adamw> #topic (1688462) System upgrades involving modular content require explicit --setopt=module_platform_id to work correctly
16:22:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1688462
16:22:38 <adamw> #info Proposed Blocker, libdnf, NEW
16:23:03 <adamw> so, there's a bit of backstory here...we've had #1656509 on the accepted blocker list for a while but it's one of those messy bugs that sort of covers a lot of ground
16:23:22 <adamw> so we decided to split it up a bit to be more clear
16:23:24 <cmurf> if it weren't for the upgrade problems i've been reading about, I'd be nervous about how few blocker bugs we've had this cycle...
16:23:52 <bcotton> cmurf++
16:24:10 <adamw> 1656509 now covers system-upgrade plugin not handling the module platform id properly *at all*, even with an explicit --setopt; this covers the module platform ID not being detected somehow, so the explicit --setopt is needed, even after that first bug is fixed
16:24:25 <adamw> cmurf: lack of successful composes isn't really helping :/
16:25:00 <adamw> i put this on proposed beta blockers so we can discuss it, but i think i'm -1 beta blocker, i think the --setopt workaround is OK for a beta
16:25:03 <sgallagh> The opinion of the Modularity WG is that requiring any specialized arguments for this is undesirable and that upgrades should work the same as they have previously.
16:25:12 <adamw> i'm +1 final blocker, as modularity wg agreed, we shouldn't require the --setopt at final
16:25:23 <sgallagh> But yeah, I'm okay with -1 beta blocker, +1 final blocker
16:25:39 <cmurf> i'm so totally in the dark understanding modularity and what's expected behavior, that I don't feel like I can vote
16:25:49 <adamw> cmurf: well, you don't need much knowledge really
16:25:52 <frantisekz> -1 beta, +1 final
16:25:58 <sgallagh> cmurf: The expected behavior is that you shouldn't have to understand modularity to perform upgrades
16:26:02 <sgallagh> This breaks that expectation
16:26:02 <cmurf> haha
16:26:10 <adamw> the issue is just this: for an upgrade from f29 to f30 to work properly you need to add a special magic parameter to the dnf system-upgrade command that you didn't need before
16:26:42 <cmurf> OK so then why should upgrades work for final but not beta? isn't it a release criterion for beta that upgrades work?
16:26:43 <adamw> if you just use the same command you used for the last X releases, it'll likely fail with a fairly cryptic error about module dependencies
16:27:04 <frantisekz> cmurf, upgrades work, just with one more parameter for dnf
16:27:08 <adamw> cmurf: for me, i'm OK with a beta release note and commonbug that just says "yeah it does that, add this magic parameter"
16:27:11 <adamw> i think that's OK for a beta
16:27:14 <adamw> i just don't think it's OK for final
16:27:31 <cmurf> ok that's convincing
16:27:37 <sgallagh> Yeah, I think we've previously agreed that minor workarounds are okay for Beta
16:27:39 <cmurf> I don't mind an extra hoop for beta users anyway
16:27:54 <cmurf> kinda like a "are you REALLY sure?"
16:28:09 <cmurf> -1 beta block, +1 final block
16:28:39 <bcotton> -1 beta blocker, -1 beta fe, +1 final blocker
16:29:38 <sgallagh> Ah, yeah. I'm also -1 beta FE at this point.
16:29:43 <sgallagh> Best not to rock the boat
16:29:50 <cmurf> -1 beta FE as well
16:29:55 <adamw> yeah, especially since dnf team seems not to understand the 'fix one bug at a time' concept
16:30:00 <cmurf> this is the U.S.S. Ship It
16:30:13 <adamw> whenever we ask for a blocker/FE fix we get eight updates to six packages with seventeen changes and a rewrite of the database system
16:30:15 <bcotton> cmurf: you're funny today :-)
16:30:30 <bcotton> adamw++
16:30:39 * cmurf is funny everyday :P
16:30:48 <adamw> that's what his mom told him anyway
16:32:01 <cmurf> shhh shhh i'm still laughing it's ok, go on
16:32:01 <adamw> proposed #agreed 1688462 - RejectedBlocker (Beta) RejectedFreezeException (Beta) AcceptedBlocker (Final) - we agreed that the workaround here (using --setopt) is OK for Beta, but not acceptable for Final, so this is accepted as a Final blocker. We do not grant a Beta FE as we don't think fixing this late for Beta is worth the risk of taking more DNF change.
16:32:14 <sgallagh> ack
16:32:17 <cmurf> ack
16:32:17 <bcotton> ack
16:32:22 <frantisekz> ack
16:32:27 <adamw> #agreed 1688462 - RejectedBlocker (Beta) RejectedFreezeException (Beta) AcceptedBlocker (Final) - we agreed that the workaround here (using --setopt) is OK for Beta, but not acceptable for Final, so this is accepted as a Final blocker. We do not grant a Beta FE as we don't think fixing this late for Beta is worth the risk of taking more DNF change.
16:33:44 <adamw> #topic Accepted Beta blockers
16:33:57 <adamw> #info that's all the proposed Beta blockers, moving onto existing accepted ones
16:34:04 <adamw> since we're now close to release, we'd best check in on all of these
16:34:13 <adamw> #topic (1688925) Need kde-settings-30 with appropriate settings for F30, including desktop background
16:34:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1688925
16:34:13 <adamw> #info Accepted Blocker, kde-settings, ON_QA
16:34:41 <cmurf> yeah it's hammer time for the accepted blockers
16:34:56 <adamw> this one is fairly straightforward, we just need to test and karma the update and push it stable
16:35:26 <adamw> if folks can do that it'd be appreciated, probably all that's needed is to install KDE in a VM, update this kde-settings, reboot and check nothing explodes (and hopefully the new background shows up)
16:35:28 * jlanda waves
16:35:41 <adamw> #info the update is submitted, we just need to test it so it can be pushed stable
16:35:49 <cmurf> ack
16:35:55 <jlanda> ack
16:36:23 <sgallagh> Acks aren't needed on status check-ins
16:36:26 <sgallagh> (Right?)
16:36:41 <cmurf> it's just short for acknowledge the ##info
16:36:47 <adamw> yeah, right
16:36:53 <adamw> unless we have to agree something
16:36:57 <adamw> pipe down there ack chorus :P
16:36:59 <cmurf> I coulda done an Ackbar
16:37:07 <cmurf> adamw can say it's a trap
16:37:08 <adamw> #topic (1656509) F29 to F30+ upgrades fail unless --allowerasing is used due to issue with module_platform_id, even explicit --setopt=module_platform_id does not work
16:37:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1656509
16:37:09 <adamw> #info Accepted Blocker, libdnf, ON_QA
16:38:00 <cmurf> ok so beta users would need to use two flags on upgrades?
16:38:03 <adamw> so, this one is the first stage of the dnf bug
16:38:22 <adamw> no, for this one you actually can't get a correct upgrade with dnf system-upgrade, aiui anyway
16:38:23 <sgallagh> the `--setopt` one in addition to `--releasever`, yeah
16:38:35 <adamw> that's not my understanding?
16:38:41 <adamw> --releasever is always required
16:38:46 <adamw> the other bug is about --setopt being required
16:38:55 <sgallagh> adamw: I meant *after* this one is implemented, you need both of those to upgrade
16:39:04 <adamw> oh, yes.
16:39:08 <sgallagh> I may have chosen confusing language
16:39:18 <frantisekz> hmm, I see I didn't understand it properly when testing that last week
16:39:22 <adamw> but the problem this bug covers is, even with --setopt, without this fix, dnf system-upgrade doesn't work right.
16:39:32 <cmurf> ok in this bug is suggesting some edge case where you might need --allowerasing (a third flag)
16:39:38 <adamw> the only way to get an upgrade through is with --allowerasing , and it removes stuff it shouldn't remove.
16:39:54 <cmurf> oh i see
16:40:05 <adamw> it's not a true fix/workaround, it just lets the operation proceed with the bug, by removing any packages it affects.
16:40:32 <adamw> the only way to get a 'correct' upgrade with this bug, again aiui, is just to use dnf distro-sync...but then you're doing it online and it might blow up on you.
16:40:45 <cmurf> ok and depending on what packages are removed, the resulting upgrade might still be confused but at least it completes?
16:40:59 <adamw> well, i mean, it won't be confused, it'll just be *missing stuff*.
16:41:00 <adamw> :P
16:41:14 <cmurf> guess it depends on what it's missing don't it?
16:41:14 <adamw> (anything that's part of a module, i think, more or less.)
16:41:38 <cmurf> got it
16:41:43 <cmurf> anyway, it's an accepted blocker
16:41:45 <jlanda> Can it delete paclages that are part of any blocking pack?
16:41:48 <cmurf> so what's the status of the fix?
16:42:01 <adamw> the criterion specifically says "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)."
16:42:06 <adamw> ok, so that's the other thing
16:42:11 <jlanda> it would be weird to upgrade a default wks and end without gnome :D
16:42:15 <adamw> this was never actually directly reviewed as an f30 blocker
16:42:31 <cmurf> was this the one we punted to fesco?
16:43:01 <jlanda> This sound a clear blocker if it deletes non deprecated packages
16:43:10 <jlanda> And it does
16:43:13 <adamw> it was reviewed as an f29 blocker, then the bug was closed (by me) (apparently incorrectly), later it was reopened and bumped to f30 beta blocker, but the 'acceptedblocker' tag wasn't removed
16:43:37 <adamw> so we have not specifically reviewed it as an f30 blocker, but given my understanding of the bug (as described above), i'd say it is one.
16:43:44 <cmurf> haha
16:43:46 <cmurf> convenient
16:43:53 <adamw> does anyone object to it being an f30 beta blocker?
16:43:58 <bcotton> +1 bb
16:45:07 <sgallagh> That logic is... impeccable. So yeah, +1 beta blocker
16:45:14 <frantisekz> +1
16:45:35 <jlanda> +1bb (-1 objection to adams question)
16:45:37 <cmurf> +1 beta blocker; the U.S.S. Ship It's boatswain has a frowny face now...
16:46:10 <sgallagh> ?
16:46:14 <adamw> #info this was never formally reviewed as an F30 Beta blocker due to various shenanigans with it being closed and opened and bumped, but we agreed at this meeting that it ought to be one
16:46:47 <adamw> so, as far as a fix goes...it seems we basically have one, but i am still trying to figure out from the dnf folks whether it needs to be pushed to a) f29, b) f30 or c) both for the bug to be fixed
16:47:10 <adamw> it also seems that upgrades from f28 to f30 would be affected and fixing that isn't as easy
16:47:19 <adamw> though less things were modular in f28
16:47:59 <frantisekz> but, f28 didn't have modular repos enabled by default, or did?
16:48:15 <bcotton> frantisekz: f28 server did, iirc
16:49:12 <sgallagh> Yes, F28 Server Edition had the module repos
16:49:29 <frantisekz> hmm, so, yeah, we'll have to fix it in F28 too :/
16:49:33 <sgallagh> But even then, there were very few modules
16:49:39 <sgallagh> And none of them default.
16:49:48 <sgallagh> So I think we're *probably* going to get away with it
16:49:52 <adamw> yeah
16:49:54 <frantisekz> okay
16:50:00 <adamw> i'm not actually seeing that any of the openqa tests are hitting it atm
16:50:02 <adamw> so it's probably okay
16:50:13 <sgallagh> Just keep an eye out for any meddling kids...
16:50:29 <cmurf> enable all modules you can, do an upgrade?
16:50:59 <adamw> cmurf: that wouldn't hit the criterion, though, the criterion covers only default package sets of release blocking media
16:51:00 <adamw> AAANYHOO
16:51:35 <adamw> #info so far as a fix goes, one exists and updates are submitted for f29 and f30, they just need to be tested and we need to clarify which one(s) need to be pushed for the issue to be resolved
16:52:06 <adamw> #topic (1683197) gdm Fails to load with "nomodeset"
16:52:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1683197
16:52:07 <adamw> #info Accepted Blocker, systemd, ASSIGNED
16:52:12 <adamw> so, this one's getting fun.
16:52:46 <adamw> ajax came up with a fix for this, only...turns out it's not really a complete fix.
16:52:55 <cmurf> yeah I thought it was complicated before finding out systemd was involved
16:52:58 <adamw> basically, it only fixes UEFI.
16:53:42 <jlanda> i suspect that there are more bios boxed wih weird gpus that actually need nomodeset than uefi ones
16:54:00 <adamw> still, we know a bit more about the bug now...on the one hand, it very likely *does* affect all systems, it is not in any way hardware-specific, at least as I now understand it
16:54:13 <adamw> on the other hand, f29 had the same bug and we shipped that and no-one's dead.
16:54:27 <adamw> (though i dunno if anyone's complained about it.)
16:54:30 <cmurf> lol
16:54:39 <cmurf> the anchor has been missing for a year!
16:54:46 <frantisekz> I am okay with not blocking on this... at least not beta
16:54:57 <cmurf> we're fine as long as we don't need a shore to land on
16:55:18 <frantisekz> but we should change our criterions / test cases in that case
16:55:24 <adamw> well, here's one person
16:55:24 <adamw> https://www.reddit.com/r/Fedora/comments/9twenw/fedora_29_install_boot_hangs/
16:55:26 <cmurf> I wish we knew how many systems were affected
16:55:39 <jlanda> The criterion had more sense 5 years ago than today
16:55:56 <cmurf> with Fedora 29 fail you could fall back to Fedora 28 media
16:56:01 <jlanda> But nowadays?
16:56:14 <frantisekz> and if it's not going to be fixed by final, I'd vote to remove the basic graphics option from the boot menu
16:56:18 <adamw> here's another
16:56:19 <adamw> https://ask.fedoraproject.org/en/question/130444/unable-to-boot-on-live-usb-with-nomodeset/
16:56:53 <cmurf> OK so I opened an issue for the Workstation WG for this topic and they haven't flagged it for a meeting to discuss criteria stuff
16:57:39 <cmurf> I agree with kparal that some kind of basic video should actually work, based on the test case expectations, rather than merely having a boot menu item present that sets whatever parameter
16:58:16 <adamw> so, i think i'm gonna try and get some followup on this today
16:58:31 <cmurf> But I'm also not willing to block on this until the Workstation WG settles exactly what to block on
16:58:33 <adamw> but we may end up having to debate whether to keep the criterion at go/no-go, or something
16:58:42 <cmurf> yeah I'm fine with that
16:58:53 <jlanda> And a basic install option that runs anaconda on text mode instead of that? Would that be possible?
16:58:56 <cmurf> we can't ignore not many people were affected with this problem for Fedora 29
16:59:12 <bcotton> cmurf: as far as we know
16:59:33 <cmurf> bcotton: we are all powerful and omnicient
17:00:57 <adamw> i mean, i find quite a lot more results, now i'm googling around
17:01:08 <adamw> just google "fedora 29" "nomodeset" and "fedora 29" "basic graphics"
17:01:55 <cmurf> google... I do "fedora 29" "nomodeset" and I see results from 2016... that is not helpful
17:02:22 <cmurf> anyway yeah it might be more than a few people affected
17:02:38 <adamw> cmurf: look through the ask.fp.o and reddit results, that's where most of the people are. :P
17:02:52 <cmurf> i'll take your word for it
17:02:59 <adamw> #info the proposed fix for this turns out not to be a complete fix, so this is putting the release at risk at this point
17:03:16 <adamw> #action adamw to follow up with graphics and systemd folks to see if a fix is still plausible
17:03:22 <cmurf> would this block beta or final? or is that also an open question?
17:03:58 <jlanda> right now i would.go on -1bb +1fe +1fb
17:04:12 <jlanda> We have this bug on current, no sense on blocking beta
17:04:17 <adamw> it's a basic criterion
17:04:22 <adamw> so it's hard to argue for it blocking final
17:04:22 <jlanda> But we should fix it
17:04:31 <cmurf> so it *ought* to be for beta
17:04:44 <adamw> by the criteria it should either block beta or nothing
17:04:49 <cmurf> roger
17:04:51 <sgallagh> I'd like to suggest that we temporarily call this "not a blocker" if it's the only thing holding up an RC today
17:05:08 <sgallagh> Leaving it open to be reconsidered at Go/No-Go
17:05:38 <cmurf> I think we need to take it seriously on the one hand; but I think it's an overcorrection from Fedora 29 to block beta because of it.
17:05:42 <adamw> we...don't really need to do that
17:05:55 <cmurf> we already let the cat out of the bag so to speak
17:06:06 <adamw> as there is no actual practical difference between a 'candidate compose' and an 'RC' these days except what we call it in the tickets
17:06:07 <sgallagh> adamw: Well, we don't spin RCs until the known blockers are fixed.
17:06:18 <cmurf> yep
17:06:25 <cmurf> I'm with sgallagh
17:06:26 <sgallagh> adamw: I thought there was still a couple things that differed.
17:06:27 <adamw> if we want a candidate i can just create one and we can decide what to call it later. :P
17:06:39 <cmurf> haha ok fine do that then
17:06:41 <sgallagh> If my info is old, sure
17:06:52 <adamw> nah, there's a difference between a nightly and a candidate, but what releng does when i request a 'candidate compose' versus an 'rc' is exactly the same. at least so far as i remember.
17:07:19 <adamw> i'll check with mboddu later, though.
17:07:49 <jlanda> By criterion is a clear beta blocker but is weird blocking the beta with a bug present on our current supported releaae
17:07:52 <sgallagh> OK, as long as we get a "candidate compose" that isn't blocked on this, I'm fine with it
17:07:56 <adamw> roger
17:08:21 <cmurf> jlanda: precisely - I'm suggesting a compromise given the fact we fudged on this for all of Fedora 29 without intention or even awareness we fudged it
17:08:31 <adamw> i don't think we actually fudged on it for f29
17:08:36 <adamw> i think we just didn't consider it
17:08:38 <adamw> but i'd have to check
17:08:42 <cmurf> besides, we don't even know what we're blocking on exactly since we're not even sure of what the fix can be
17:08:57 <cmurf> and it's an open question if the criterion has the support of the WG
17:09:39 <cmurf> and whether it needs revision and relocation to be explicitly beta or final blocking
17:09:48 <adamw> cmurf: the f29 bug you referenced is a different one
17:09:57 <adamw> i think this bug showed up later in the f29 cycle but was never caught for some reason
17:09:59 <cmurf> same outcome
17:10:21 <adamw> nah, the earlier f29 bug was definitely configuration-dependent - note it was UEFI only, for instance
17:11:14 <cmurf> i recognized the details are different, the outcome of a black screen instead of GDM was the same
17:11:24 <adamw> on an affected system. yes.
17:11:27 <adamw> anyhow
17:11:32 <adamw> i think we talked this to death at this point
17:11:34 <cmurf> I had more information about the failure with the F29 bug than the F30 bug, on the same systems
17:11:50 <adamw> #topic Open floor
17:11:54 <cmurf> horse is hamberdered
17:12:11 <adamw> anyone have other bugs to bring up, anything else that's threatening f30 beta at this point?
17:12:26 <adamw> oh wait
17:12:28 <adamw> did i miss FEs?
17:12:32 <frantisekz> yep
17:12:40 <adamw> yes i did
17:12:41 <adamw> sorry
17:12:42 <cmurf> i wanna know where all the bugs are
17:12:46 <adamw> #topic Proposed Beta freeze exceptions
17:12:52 <adamw> #info sorry, went to open floor too soon
17:13:01 <adamw> #topic (1686851) nm-connection-editor should be moved to the X-GNOME-Utilities folder
17:13:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1686851
17:13:01 <adamw> #info Proposed Freeze Exceptions, gnome-menus, ON_QA
17:13:48 <cmurf> seems safe?
17:13:57 <adamw> i'm +1 for this, it's a visible annoyance on the workstation live and the fix looks very safe
17:14:01 <frantisekz> +1
17:14:05 <bcotton> +1
17:14:06 <cmurf> +1 FE
17:14:30 <sgallagh> +1
17:15:02 <jlanda> +1 fe
17:15:50 <jlanda> But. The visible annoiance is not so big anymore
17:16:22 <jlanda> They fixed on upstream: now their just on the frond foldee
17:16:37 <jlanda> s/frond whatever/wrong foldsr
17:16:42 <jlanda> Ar, folder :D
17:17:26 <adamw> proposed #agreed 1686851 - AcceptedFreezeException (Beta) - this bug is quite visible in the Workstation live image (so cannot be fixed with an update) and the fix is very safe
17:17:33 <bcotton> ack
17:17:56 <frantisekz> ack
17:18:03 <cmurf> ack
17:18:38 <adamw> #agreed 1686851 - AcceptedFreezeException (Beta) - this bug is quite visible in the Workstation live image (so cannot be fixed with an update) and the fix is very safe
17:18:40 <adamw> #topic (1684424) [Wayland][ja_JP] [Firefox][wayland] Not able to commit Japanese input from the candidate list, on address bar or search field.
17:18:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1684424
17:18:40 <adamw> #info Proposed Freeze Exceptions, mutter, NEW
17:19:33 <frantisekz> +1 FE
17:19:36 <adamw> so, we had this as a final blocker (iirc) in f29
17:19:47 <cmurf> +1 beta FE
17:19:48 <adamw> it seems it was worked around in gnome 3.30 but neither the workaround nor a fix is in 3.32, so it's back
17:19:52 <bcotton> so FESCo voted to push wayland by default to F31
17:20:03 <frantisekz> I wouldn't block beta on that
17:20:14 <adamw> i don't think this relates to firefox being wayland native
17:20:39 <bcotton> counterpoint: https://bugzilla.redhat.com/show_bug.cgi?id=1684424#c2
17:20:53 <adamw> hmm
17:21:09 <adamw> i am not 100% sure about that
17:21:23 <adamw> i'm not sure bhushan did quite what martin wanted...
17:21:56 <bcotton> +1 FE if it's still relevant
17:22:00 <cmurf> so it's Xwayland related
17:22:25 <jlanda> +1 fe
17:23:36 <cmurf> i'm confused if it only happens with ffwayland, or with ffxwayland, clearly sounds like it's not happening with ffx11
17:23:55 <adamw> the tester doesn't actually say they tested with firefox-x11
17:24:06 <adamw> they say "Martin, yes the issue is with wayland. It works fine i.e I'm ablke to commit jpn input properly with x11."
17:24:16 <adamw> that could equally mean they tried an X11 *session* instead of a Wayland one, and it worked
17:24:23 <cmurf> comment 2 says he gets it to work on x11
17:24:47 <adamw> i.e. they didn't test native vs. non-native firefox on a wayland session
17:24:48 <adamw> anyhow
17:24:53 <cmurf> right
17:24:55 <adamw> i'm not sure we need to decide that, i guess
17:25:06 <adamw> +1 FE for me too
17:25:40 <adamw> proposed #agreed 1684424 - AcceptedFreezeException (Beta) - as described this is a significant problem for CJK-type input that will be present in the Workstation live and so cannot be fixed fully with an update
17:25:50 <frantisekz> ack
17:25:53 <bcotton> ack
17:28:14 <adamw> #agreed 1684424 - AcceptedFreezeException (Beta) - as described this is a significant problem for CJK-type input that will be present in the Workstation live and so cannot be fixed fully with an update
17:28:19 <adamw> #topic (1687896) python-aniso8601 cannot be installed on Fedora 30
17:28:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1687896
17:28:20 <adamw> #info Proposed Freeze Exceptions, python-aniso8601, NEW
17:28:37 <adamw> apparently this is preventing some builds going ahead in copr, i guess i'd be ok with an FE for that purpose
17:28:42 <cmurf> i guess I can go either way on this
17:28:42 <frantisekz> hmm, package I maintain, I broke that, I created FE... :)
17:28:58 <adamw> it Shouldn't be able to break anything significant ;)
17:29:05 <cmurf> +1 beta FE
17:29:06 <bcotton> +1 FE
17:29:09 <frantisekz> +1
17:29:44 <sumantro> +1
17:31:24 <adamw> proposed #agreed 1687896 - AcceptedFreezeException (Beta) - this package is a build dependency for others, so it not being installable is causing problems for other package builds. We grant it an FE to solve that issue. It should not affect the actual Beta composes at all.
17:31:34 <cmurf> ack
17:31:41 <bcotton> ack
17:31:59 <frantisekz> ack
17:32:00 <sumantro> ack
17:32:36 <adamw> #agreed 1687896 - AcceptedFreezeException (Beta) - this package is a build dependency for others, so it not being installable is causing problems for other package builds. We grant it an FE to solve that issue. It should not affect the actual Beta composes at all.
17:32:40 <adamw> ok, so NOW we can do...
17:32:43 <adamw> #topic Open floor
17:32:46 <adamw> same question as before. :P
17:32:55 <frantisekz> finally ... free :D
17:34:07 <bcotton> #info the go/no-go meeting is at 1700 UTC Thursday in #fedora-meeting
17:34:28 <cmurf> dun dun DUNNNN
17:34:31 <bcotton> #info the release readiness meeting is at 1900 UTC Thursday in #fedora-meeting, even if we are no-go
17:35:16 <bcotton> #info for F32, I will make sure the go/no-go and release readiness meetings don't fall on the first weekend of the NCAA men's basketball tournament :-D
17:36:01 <cmurf> psshhh and then it conflicts with lacrosse or hockey instead? thxbutnothx
17:37:23 <cmurf> (basketball and baseball, there's what 4000 games per season between them?)
17:37:39 <bcotton> cmurf: E_TOOFEWGAMES
17:37:57 <adamw> hey, just so long as i don't miss the Milton Keynes Invitational Tiddlywinks Grand Master Tournament everything will be fine
17:38:18 <cmurf> what the
17:38:22 <cmurf> you made that up!
17:38:45 <cmurf> hey adamw how about some more MOM jokes huh?
17:39:26 <adamw> yes. yes i did.
17:43:26 <adamw> alrighty, sounds like we're done here
17:43:30 <adamw> thanks for coming, everyone
17:43:31 <adamw> #endmeeting