16:00:29 <adamw> #startmeeting F31-blocker-review
16:00:29 <zodbot> Meeting started Mon Oct 21 16:00:29 2019 UTC.
16:00:29 <zodbot> This meeting is logged and archived in a public location.
16:00:29 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:29 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:00:29 <adamw> #meetingname F31-blocker-review
16:00:29 <adamw> #topic Roll Call
16:00:29 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:01:43 <sgallagh> I'm semi-here. I commented in bugs
16:02:37 * kparal joins
16:03:11 * satellit_ listening
16:04:27 * coremodule is here. Ready to act as secretary for the meeting.
16:04:29 * pwhalen is here
16:04:43 <adamw> nirik: tflink: halfl: ahoyhoy
16:04:47 * coremodule is here, willing to act as secretary.
16:04:48 <adamw> also halfline sigh
16:04:55 <coremodule> Dunno if my first message went through...
16:04:57 <adamw> my god, there's two of him
16:05:15 <kparal> lruzicka sends apologies
16:05:33 <kparal> lbrabec: ping
16:05:33 <zodbot> kparal: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
16:05:53 * nirik is lurking, ping me if you need me.
16:06:45 <adamw> we always need you
16:07:38 <adamw> alrighty. let's get rolling
16:08:48 <adamw> #chair kparal coremodule
16:08:48 <zodbot> Current chairs: adamw coremodule kparal
16:08:55 <adamw> boilerplate alert!
16:08:56 <adamw> #topic Introduction
16:08:57 <adamw> Why are we here?
16:08:57 <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:08:57 <adamw> #info We'll be following the process outlined at:
16:08:58 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:59 <adamw> #info The bugs up for review today are available at:
16:09:01 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:05 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:07 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:09:09 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria
16:09:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria
16:10:10 <adamw> #info for F31 Final, we have:
16:10:11 <adamw> #info 3 Proposed Blockers
16:10:11 <adamw> #info 2 Accepted Blockers
16:10:15 <adamw> #info 1 Accepted Previous Release Blockers
16:10:16 <adamw> #info 3 Proposed Freeze Exceptions
16:10:16 <adamw> #info 4 Accepted Freeze Exceptions
16:10:28 <adamw> #info coremodule and coremodule will share the secretary duties
16:10:35 <adamw> #info let's start with proposed Final blockers
16:10:48 <adamw> #topic (1763525) Changing user password with wrongly entered current password freezes gnome-control-center
16:10:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1763525
16:10:48 <adamw> #info Proposed Blocker, gnome-control-center, NEW
16:12:39 <adamw> i think i'm with sgallagh on this, it's awkward but it's not something people do all the time, you have to get something wrong to hit it, and we can fix it with an update
16:12:48 <adamw> so i'm leaning to -1
16:13:23 <kparal> I'm +0
16:14:36 <sgallagh> -1 as I was in the ticket
16:17:01 <adamw> aaannyone else
16:17:04 <coremodule> ummm
16:17:37 <coremodule> im -1
16:17:46 <nirik> -1 Blocker
16:17:46 <pwhalen> -1 blocker
16:18:31 * mclasen doesn't reproduce this
16:19:03 <adamw> proposed #agreed 1763525 - RejectedBlocker (Final) - while this is an awkward bug, we agree it is not severe enough to violate the "basic functionality" requirement, especially as this is not something that is likely to be used in a live environment or immediately after install
16:19:25 <sgallagh> Ack
16:19:29 <kparal> ack
16:19:31 <pwhalen> ack
16:19:55 <adamw> mclasen: well, at least sumantro and frantisek did...but maybe there's some step they're doing and you're not?
16:20:45 <mclasen> possible
16:21:09 <pwhalen> worth a FE?
16:21:50 <kparal> I've also seen it
16:22:05 <sgallagh> I’d be -1 FE too. No need to introduce any uncertainty into the RCs
16:22:16 <adamw> yeah...probably agree
16:22:46 <adamw> #agreed 1763525 - RejectedBlocker (Final) - while this is an awkward bug, we agree it is not severe enough to violate the "basic functionality" requirement, especially as this is not something that is likely to be used in a live environment or immediately after install
16:22:53 <adamw> #topic (1762689) [abrt] gnome-software: gs_flatpak_get_installation(): gnome-software killed by SIGSEGV
16:22:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1762689
16:22:54 <adamw> #info Proposed Blocker, gnome-software, VERIFIED
16:22:59 <adamw> i believe we can skip this as the update is pending stable
16:23:10 <adamw> i tried to get it pushed before the meeting but there's a push happening at the moment so it couldn't be
16:23:24 <sgallagh> I saw that it made RC 1.3 also
16:23:33 <adamw> #info the update that fixes this is about to be pushed stable (as it is already granted FE status), so we do not really need to consider it
16:23:42 <adamw> sgallagh: yeah
16:23:52 <adamw> #topic (1762751) Gnome-software should provide workaround for libgit2 for F29/F30->F31 upgrade
16:23:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1762751
16:23:52 <adamw> #info Proposed Blocker, PackageKit, NEW
16:23:57 <adamw> +1 previousrelease blocker
16:24:24 <sgallagh> FESCo declared this a blocker
16:24:26 <kparal> from https://pagure.io/fesco/issue/2230:
16:24:26 <adamw> yeah
16:24:29 <adamw> we don't actually need to vote on it
16:24:30 <kparal> AGREED: (+5, 1, -1)
16:24:30 * kparal nirik to ask kalev about workaround in
16:24:30 <kparal> packagekit/gnome-software and block release on this fix. If it is
16:24:30 <kparal> complicated, ignatenkobrain will create libgit2_0.28 package.
16:24:31 <sgallagh> In the meeting we just had
16:25:01 <kparal> it doesn't explicitly say a blocker, but good enough for me
16:25:25 <adamw> proposed #agreed 1762751 - AcceptedPreviousReleaseBlocker (Final) - we take FESCo's vote on https://pagure.io/fesco/issue/2230#comment-605570 as a declaration that this should be a blocker
16:25:41 <adamw> uff, that's...a bit awkward
16:25:53 <adamw> because the gnome-software workaround would be previousrelease
16:26:00 <adamw> but the libgit2_0.28 package would be f31, right?
16:26:04 <adamw> so we would have to hold the candidate for it
16:26:16 <sgallagh> It’s not on media
16:26:21 <sgallagh> It could be zero-day
16:26:27 * mclasen doesn't see a gnome-software workaround for this in the cards
16:26:32 <adamw> um. i guess.
16:26:47 <adamw> mclasen: can't it do what dnf did?
16:26:57 <adamw> it's a dorky hack, but it's not really horrible
16:27:07 <mclasen> don't cover up modules madness by forcing awkward workarounds in all the wrong layers...
16:27:31 <nirik> we do not live in a perfect world.
16:27:34 <adamw> right.
16:27:40 <mclasen> but thats just my opinion. maybe fesco wants to write that patch
16:30:35 <adamw> proposed #agreed 1762751 - AcceptedPreviousReleaseBlocker (Final) - we take FESCo's vote on https://pagure.io/fesco/issue/2230#comment-605570 as a declaration that this should be a blocker. If a decision is taken to use the libgit2_0.28 workaround instead, this will become a Accepted0DayBlocker
16:30:48 <sgallagh> Ack
16:31:19 <Southern_Gentlem> ack
16:31:20 <pwhalen> ack
16:31:32 <kparal> ack
16:31:36 <coremodule> ack
16:31:48 <adamw> #agreed 1762751 - AcceptedPreviousReleaseBlocker (Final) - we take FESCo's vote on https://pagure.io/fesco/issue/2230#comment-605570 as a declaration that this should be a blocker. If a decision is taken to use the libgit2_0.28 workaround instead, this will become a Accepted0DayBlocker
16:32:08 <adamw> #topic Proposed Final freeze exceptions
16:32:12 <adamw> #info moving onto proposed final FEs
16:32:12 <adamw> #topic (1762909) Fixing spins and labs for F31 final
16:32:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1762909
16:32:13 <adamw> #info Proposed Freeze Exceptions, distribution, NEW
16:32:41 <coremodule> +1 FE
16:32:48 <pwhalen> +1 FE
16:32:56 <sgallagh> +1
16:32:57 <adamw> this seems a bit broad
16:33:07 <adamw> it'd be nice to know exactly what we're approving hre
16:33:16 <adamw> +1 for https://pagure.io/fedora-kickstarts/pull-request/590 at least
16:33:39 <Southern_Gentlem> +1 FE, but would like more info
16:33:47 <coremodule> I'd assume fixing the missing dependencies... or do you mean the exact dependencies that are broken?
16:33:48 <pwhalen> right, I am +1 FE for the listed PR
16:33:51 * sgallagh is hoping it’s irrelevant because RC 1.3 will go GA 😁
16:34:42 <adamw> heh
16:35:05 <pwhalen> well, I dont. An accepted blocker hasnt been addressed.
16:35:19 <adamw> pwhalen: we'll get to accepted blockers in a bit
16:35:23 <adamw> mclasen: hah
16:35:28 <pwhalen> not sure how we got an RC
16:35:30 <pwhalen> ok
16:35:33 <adamw> the copy/paste bug i was telling you about *just* happened
16:35:46 <adamw> i half-typed a 'proposed' line, ctrl-x'ed it to reply to pwhalen, hit ctrl-v and it did not come back
16:36:06 <adamw> (so, cut/paste, but same thing)
16:37:09 <adamw> proposed #agreed 1762909 - AcceptedFreezeException (Final) - we note that this is a bit broad, but it is accepted at least for the purpose of the specific PR that is linked, to fix generation of a non-release-blocking image
16:37:20 <coremodule> ack
16:37:25 <kparal> ack
16:37:45 <pwhalen> ack
16:37:57 <adamw> #agreed 1762909 - AcceptedFreezeException (Final) - we note that this is a bit broad, but it is accepted at least for the purpose of the specific PR that is linked, to fix generation of a non-release-blocking image
16:38:05 <adamw> #topic (1761327) "Object St.Button (0x5621e3249b90), has been already deallocated — impossible to get any property from it." spam in system logs
16:38:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1761327
16:38:05 <adamw> #info Proposed Freeze Exceptions, gnome-shell, NEW
16:38:53 <Lailah> Hello! Sorry for being late.
16:39:13 <coremodule> Did we hear from the gnome devs on this at all, obviously not in-bug?
16:39:18 <Lailah> fas .lailah
16:40:20 <adamw> hi lailah
16:41:08 <Lailah> Hi adamw!
16:41:18 <Lailah> fas .lailah
16:41:28 <Lailah> Why it doesn't work?
16:41:37 <sgallagh> dot in the wrong place
16:41:41 <sgallagh> .fas lailah
16:41:41 <Lailah> .fas lailah
16:41:42 <zodbot> sgallagh: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:41:45 <zodbot> Lailah: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:41:45 <Lailah> Ah
16:41:47 <Lailah> Now
16:41:52 <Lailah> Okay
16:41:57 <Lailah> Heh, sorry, lack of habit
16:42:49 <adamw> i'm still confused about exactly what is proposed to fix this, but anyway, at this point i think fixing logspam is not a big enough issue to pull in Change, so -1
16:43:00 * mclasen was distracted
16:43:45 <kparal> mclasen: can you tell us how beneficial is to have a fix included for this issue on the installation medium?
16:45:00 <mclasen> if the only effect is log spam, I would recommend leaving this to a regular update
16:45:17 <sgallagh> I agree, -1 FE
16:45:18 <pwhalen> -1 FE
16:45:20 <mclasen> looks like the fix will be in 3.34.2 anyway
16:46:55 <adamw> proposed #agreed 1761327 - RejectedFreezeException (Final) - at this point in the cycle we think it's too late to potentially introduce instability to fix log spam
16:47:01 <kparal> -1 FE
16:47:05 <kparal> ack
16:47:16 <sgallagh> ack
16:47:27 <pwhalen> ack
16:48:12 <Lailah> ack
16:48:25 <adamw> #agreed 1761327 - RejectedFreezeException (Final) - at this point in the cycle we think it's too late to potentially introduce instability to fix log spam
16:48:30 <adamw> #topic (1758225) Missing mandatory option for `class' after SilverBlue install
16:48:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1758225
16:48:31 <adamw> #info Proposed Freeze Exceptions, grub2, ON_QA
16:49:05 <adamw> this is breaking silverblue on ppc64
16:50:09 <coremodule> +1 FE
16:50:21 <pwhalen> +1 FE
16:50:25 <sgallagh> I'm on the fence.
16:50:40 <sgallagh> On the one hand, "bootable on ppc64le" is really important and can't be fixed later.
16:50:41 <pbrobinson> sgallagh: unlike you ;-)
16:50:54 <adamw> how exactly do we ship silverblue these days? i keep forgetting
16:51:06 <adamw> do we do it 'two week atomic' styleee?
16:51:13 <pbrobinson> it's an installer isn't it on PowerLE?
16:51:17 <sgallagh> On the other hand, I always get nervous giving FEs for the bootloader, because they don't always improve things
16:51:22 <Lailah> I don't understand the error, what exactly is not working, so I'm 0 on this
16:51:30 <pbrobinson> I don't believe they do 2 week style
16:51:53 <pbrobinson> sgallagh: the process there has improved a LOT
16:51:58 <mclasen> adamw: no two week schedule
16:52:26 <sgallagh> pbrobinson: Yeah, I'm not saying -1, I'm just wary.
16:52:41 <sgallagh> I'll vote 0
16:53:27 <adamw> i for one welcome our new ppc overlords and vote +1 ;)
16:53:48 <adamw> (sgallagh makes a solid point and wins the sacred Right To Say I Told You So, however)
16:53:50 <pwhalen> heh :)
16:55:51 <adamw> proposed #agreed 1758225 - AcceptedFreezeException (Final) - while we note the risk of allowing change to the bootloader at this time, we believe fixing a significant image on ppc64le is at least potentially worth the risk
16:56:26 <sgallagh> ack
16:56:31 <coremodule> ack
16:56:32 <pwhalen> ack
16:57:06 <pbrobinson> ack
16:57:15 <adamw> #agreed 1758225 - AcceptedFreezeException (Final) - while we note the risk of allowing change to the bootloader at this time, we believe fixing a significant image on ppc64le is at least potentially worth the risk
16:57:38 <adamw> #topic Accepted blockers
16:57:44 <adamw> #info let's check in on the state of accepted blockers
16:57:59 <adamw> #topic (1691430) dnf.exceptions.Error: Incorrect or unknown "arch": armv7hcnl
16:57:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1691430
16:57:59 <adamw> #info Accepted Blocker, dnf, ON_QA
16:58:08 <adamw> ah, is this the one you were worried about pwhalen?
16:58:12 <pwhalen> indeed
16:58:21 <pbrobinson> yep
16:58:34 <adamw> ah, i see what happened
16:58:39 <pbrobinson> there's a rpm and libdnf build now in place for the worst of it
16:58:42 <adamw> the bug just shows up as 'ON_QA' in blockerbugs
16:58:48 <adamw> so it read as 'addressed' to me
16:59:01 <adamw> i didn't remember we were still waiting on the libdnf side of the fix, sorry about that
16:59:22 <pbrobinson> adamw: well that team didn't co-ordinate to put it all through as one update :-/
16:59:32 <adamw> yeah, that would've been better :/
16:59:52 * pbrobinson won't comment further on that side of things ;-)
17:00:19 <adamw> #info RC-1.3 was built with an incomplete fix for this (including rpm but omitting libdnf) so should not be released
17:00:35 * sgallagh sadly agrees
17:00:58 <adamw> we'll run a new candidate after this meeting, i guess
17:01:13 <adamw> #info libdnf side of the fix is now also available, so we can run a new candidate compose
17:01:24 <adamw> any more notes on this bug, or is everyone happy with what's there to address it now?
17:01:32 <Lailah> I'm fine
17:01:56 <pbrobinson> there's a related issue in there that's not properly addressed, I had a call with the manager this morning and I'm awaiting to hear back
17:02:10 <adamw> does that need to block release?
17:02:18 <sgallagh> What is the issue?
17:02:31 <pbrobinson> adamw: up for debate, waiting to hear
17:02:49 * pbrobinson wishes that team would have asked for architecture verification before they blindly merged bad shit
17:03:30 * Lailah agrees with pbrobinson and sighs
17:04:40 <adamw> can you give us any details on the remaining issue?
17:05:17 <pbrobinson> it could potentially be fixed with a zero day but then all the live images and installers will be stuck with the bug causing support issues for a year+ afterwards which I don't relish
17:05:50 <pbrobinson> I've asked for it to be added to Fedora so we don't regress while we bike shed it for a bazillion years upstream
17:05:51 <sgallagh> pbrobinson: BZ?
17:06:01 <pbrobinson> it's referenced in that same BZ
17:06:19 <pbrobinson> and in the RPM PR upstream that's referenced in that BZ
17:07:06 <pbrobinson> Arm themselves and RHEL Arm have both stated they don't want it at all every
17:07:08 <pbrobinson> ever
17:09:09 <adamw> this is about "the arm64 mapping", right?
17:09:14 <adamw> dmach at least said he doesn't think it's a release blocker
17:09:29 <adamw> does that basically mean "RPM treats 'arm64' as if it means 'aarch64'"?
17:09:41 <pbrobinson> yup
17:09:52 <pbrobinson> adamw: dmach doesn't need to support it
17:11:17 <adamw> his opinion is significant, though.
17:11:37 <adamw> is your objection to us shipping with this 'arm64 mapping' that it would oblige us to include it forever, or something?
17:11:46 <pbrobinson> Doesn't my opinion as the Arm arch lead cound as that too? Ultimately I feel that it's enough of a problem I'll probably stand down from all Arm related activities unrelated directly to my IoT role and let someone else step up
17:11:51 <adamw> is there some reason we can't just take it out in a post-release update and be fine with that?
17:12:29 <pbrobinson> because it's on live images and installers for the life of the release a lot actually don't apply updates so there's ongoing support implications
17:12:56 <adamw> the fact that something exists does not mean we have to "support" it, though
17:13:08 <sgallagh> pbrobinson: Could you file this issue as a separate BZ that we can vote on as a blocker?
17:13:21 <pbrobinson> adamw: also doesn't mean that even if we don't support it doesn't mean there's no a support load
17:13:35 <adamw> that's a lot of not meaning! but i think i get what you don't mean ;)
17:13:39 <pbrobinson> we don't support the RPi4 but it doesn't stop people bothering me a dozen times a day
17:13:55 <adamw> +1 sgallagh
17:13:59 <pbrobinson> which even though it's unsupported adds loda
17:14:00 <pbrobinson> load
17:14:11 <pbrobinson> sgallagh: sure
17:15:34 <adamw> so the current state is that the pending rpm update for f31 includes "Remove problematic sub variants of armv8 and related" but does not include "Revert "rpmrc: Add architecture compatibility mapping between aarch64 and arm64"", right?
17:15:46 <pbrobinson> correct
17:15:57 <adamw> okay. so yeah, please file another bug and we can vote on it
17:16:07 <adamw> if you can do it *right now* that'd be great, since we're short on time and all :P
17:16:21 <pbrobinson> adamw: yep give me a sec
17:16:22 <sgallagh> Is that a literal git reversion?
17:16:36 <sgallagh> Like, can a provenpackager go ahead and apply it Right Now?
17:16:42 <adamw> sgallagh: i believe so
17:16:51 <pbrobinson> sgallagh: as in literal revert without edit? Yes
17:16:52 <adamw> https://github.com/rpm-software-management/rpm/pull/901/commits/0351a07fe5fe3c82cc8bdc4d85de9ff4624945c6
17:17:18 <sgallagh> Lastly: How much will it break if I (ab)use my provenpackager permissions and do that?
17:18:12 <sgallagh> We have to have an RC 1.4 for the libdnf portion of the fix, so I'd like to just get this done (assuming we vote +1 blocker) and get it kicked off imminently
17:18:15 <adamw> #info the pending rpm and libdnf updates address the most pressing bugs here, but do not include reverting the introduction of 'arm64' as an rpm-level alias for 'aarch64', which pbrobinson would also like included; he will file a separate bug and we will vote on that separately
17:18:30 <adamw> sgallagh: i think at least doing the build and filing an update can't hurt
17:18:34 <adamw> we can always yank it
17:18:55 <sgallagh> Well, the RPM folks might shout at me, so I want to know how defensive I should be :)
17:19:04 <adamw> as i read the upstream PR, those with reservations about reverting the 'arm64' thing mainly have reservations in re doing it upstream
17:19:18 <sgallagh> okay
17:19:26 <adamw> that's just my read though
17:19:45 <sgallagh> I'll risk it. We're short on time and this seems genuinely pressing
17:20:33 <adamw> alright
17:20:34 <mkolman> still seems a bit weird to me to touch something as core as RPM directly
17:20:46 <adamw> mkolman: eh, give it another few years, padawan
17:20:56 <adamw> :P
17:21:07 <pbrobinson> the discussion I had with Jan today was he was going to discuss it with the team and get back to me
17:21:22 <mkolman> well, this is just my opinion :P
17:21:27 <pbrobinson> I insisted it was a problem for us and we don't want it in a stable release
17:21:41 <adamw> doing a build with arm64 reverted, filing an update for it, and even composing a candidate that includes it are all easily reversible actions
17:21:52 <adamw> the only things that would be fairly non-reversible are pushing the update stable and releasing the candidate
17:22:08 <adamw> so, i think it's fine to give ourselves the options as early as possible.
17:22:10 <mkolman> good point about the update - it does not really go live until the update is stable
17:22:27 <adamw> alrighty
17:22:29 <adamw> while that's going on
17:22:32 <adamw> let's review the other accepted blocker
17:22:39 <adamw> #topic (1728240) Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine
17:22:40 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1728240
17:22:40 <adamw> #info Accepted Blocker, sddm, VERIFIED
17:22:45 <adamw> should be easy: fix is verified
17:22:47 <sgallagh> pbrobinson: Both Rawhide and F31?
17:22:54 <adamw> anyone have other concerns?
17:24:00 <kparal> nothing here
17:24:18 <adamw> alrighty
17:24:23 <adamw> #info fix here is verified and pending stable
17:24:31 <adamw> #topic Open floor, pending new proposed blocker
17:24:36 * adamw plays muzak
17:24:53 <adamw> doot doot DOOT...dit dit doot....dootely dootely deet deet boop bap...doot doot DOOT...
17:25:12 * coremodule dances, unforgettably.
17:25:41 * sgallagh tries desperately to forget
17:26:24 * coremodule offers condolences, but knows the truth of the matter; sgallah will be unable to forget.
17:26:32 <pbrobinson> https://bugzilla.redhat.com/show_bug.cgi?id=1763831
17:26:39 <pbrobinson> sgallagh: yes please
17:27:13 <Lailah> LOL
17:27:21 <adamw> .fire sgallagh 's memory
17:27:21 <zodbot> adamw fires sgallagh 's memory
17:27:30 <adamw> it was a mercy firing
17:27:52 <pbrobinson> LOL
17:27:57 * sgallagh scrapes his grey matter off the wall, stuffs it back into his ear and continues fixing RPM
17:27:57 <adamw> allllrighty
17:28:04 <pbrobinson> isn't that what alcohol is for>
17:28:05 <adamw> #info let's go to the new proposed blocker
17:28:14 <sgallagh> pbrobinson: I can't recall...
17:28:16 * pbrobinson goes to check on dinner
17:28:20 <coremodule> pbrobinson, has a point...
17:28:38 <adamw> #topic (1763831) revert incorrect arm64 <-> aarch64 mapping
17:28:41 <Lailah> coremodule: alcohol not always work
17:28:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1763831
17:28:45 <Southern_Gentlem> +1 blocker
17:28:51 <adamw> #info Proposed Blocker, rpm, NEW
17:29:10 <sgallagh> Given the stance of the ARM team (represented by pbrobinson and pwhalen), I'm +1 blocker here
17:29:14 <coremodule> +1 blocker
17:29:16 <adamw> so i'm having trouble seeing where this would really be a *blocker* in the criteria. it doesn't break anything
17:29:22 <Lailah> +1 blocker
17:29:25 <adamw> but i'm happy with +1 FE and to include it in a compose
17:29:29 <Southern_Gentlem> +1 blocker
17:29:32 <pbrobinson> adamw: breaks the Arm team?
17:29:35 <adamw> oy quit voting twice :P
17:29:36 <pwhalen> +1 blocker
17:29:40 <adamw> pbrobinson: you are not a release criterion :P
17:29:49 <pwhalen> :D
17:29:52 <coremodule> called "breaking an ARM"
17:29:55 <sgallagh> He bloody well should be :)
17:30:14 <coremodule> better than breaking one's coccyx
17:32:02 <pbrobinson> sgallagh: I don't think I want that responsibility!
17:32:09 <sgallagh> OK, you're right that I can't find a good justification for blocker.
17:32:12 <adamw> i would like it if someone could at least provide some kind of plausible justification beyond "pbrobinson said so"
17:32:18 <adamw> i mean we all love peter but still :P
17:32:18 <sgallagh> So I guess I'll go with +1 FE, but I'm still going to build it.
17:32:32 <mkolman> (I think I'm not in a voting role, but personally consider this a blocker as well, that should be fixed even at the cost of slipping release dates)
17:32:35 <sgallagh> (Just verifying that a scratch-build on aarch64 works before I push and do a formal build)
17:32:38 <pbrobinson> adamw: is a FE easier and pull it in?
17:32:47 <sgallagh> mkolman: All attendees have voting privileges in this meeting
17:32:47 <adamw> mkolman: you get a vote, with a developer hat on
17:33:06 <mkolman> interesting
17:33:08 <sgallagh> mkolman: Can you justify it with a criterion violation?
17:33:14 <sgallagh> That would make this easier.
17:33:20 <adamw> sgallagh: extremely technically only people who can be counted as 'development', 'releng' or 'qa' for fedora get votes.
17:33:22 <sgallagh> (I mean, FE or blocker, it's going in)
17:33:44 <sgallagh> Isn't every Fedora user one or more of those things? :)
17:33:46 <adamw> pbrobinson: yeah, FE is an easier bar and if it gets FE we'll still do a candidate with it, since we need to respin anyway
17:34:11 <adamw> sgallagh: but not the spies from phoronix! :P
17:34:15 <sgallagh> The primary difference is "If this patch ends up being insufficient, do we slip the release until we get it right?"
17:34:33 <adamw> right. if we accept it as a blocker we're basically declaring this must be changed
17:34:47 <adamw> if we accept it as an FE we leave more wiggle room to ultimately not take it if it blows up or something
17:34:55 <adamw> (we could potentially build one candidate compose with it and one without)
17:35:03 <adamw> (though actually i'd probably just request one with it for now)
17:35:13 <sgallagh> I'd prefer just... yeah
17:35:37 <sgallagh> Proposal: Grant FE today, Blocker decision at Go/No-Go if it becomes necessary?
17:35:43 <Lailah> For what is worth, I'm +1 FE
17:35:57 <adamw> sgallagh: yeah, that seems reasonable
17:36:07 <adamw> at least gives more people time to weigh in with Strong Opinions (tm)
17:36:27 <sgallagh> adamw: Right, because that's what blocker meetings need. *More* strong opinions :-D
17:36:39 <pbrobinson> sgallagh: the revert is sufficient so from that PoV FE is fine here
17:36:51 <sgallagh> OK, scratch-build passed, so I'll go ahead and do official builds for Rawhide and F31
17:39:49 <adamw> proposed #agreed 1763831 - defer decision on blocker status, AcceptedFreezeException (Final) - we accept pbrobinson's contention as ARM lead that this is undesired functionality that we don't want shipped in F31 as it may create a support burden. There is no clear rationale for blocker status but we leave the possibility open for further review at go/no-go meeting depending on how things go this week
17:40:25 <coremodule> ack
17:40:29 <Lailah> ack
17:40:50 <sgallagh> ack
17:40:51 <pwhalen> ack
17:41:21 <pbrobinson> ack
17:41:42 <adamw> #agreed 1763831 - defer decision on blocker status, AcceptedFreezeException (Final) - we accept pbrobinson's contention as ARM lead that this is undesired functionality that we don't want shipped in F31 as it may create a support burden. There is no clear rationale for blocker status but we leave the possibility open for further review at go/no-go meeting depending on how things go this week
17:41:54 <pbrobinson> sorry, was dealing with onions/garlic/rosemary for dinner :-P
17:41:57 <adamw> thanks for providing all the info pbrobinson
17:42:04 <sgallagh> pbrobinson: Aromatic!
17:42:10 <adamw> a r o m a t i c
17:42:30 <adamw> #topic Open floor redux
17:42:35 <adamw> OK, I believe we covered everything now
17:42:40 <adamw> any other f31 release-related business?>
17:42:41 <Lailah> pbrobinson: sounds good, can I drop by for dinner?
17:42:43 <sgallagh> RPM is building for both releases as we speak
17:43:19 <pbrobinson> Lailah: sure, if you're in London, served in ~ 45 mins
17:43:38 <Lailah> I had some issues with KDE and the last kernels, but too vague to open a bug yet.
17:44:11 <adamw> thanks sgallagh
17:44:11 <Lailah> pbrobinson: I'm a bit far from London, but I'll try.
17:49:29 <adamw> looks like we're done
17:49:34 <adamw> thanks again everyone!
17:49:37 <adamw> expect a new RC fairly soon
17:49:42 <adamw> #endmeeting