17:00:40 <bcotton> #startmeeting F31 Final Go/No-Go meeting
17:00:40 <zodbot> Meeting started Thu Oct 17 17:00:40 2019 UTC.
17:00:40 <zodbot> This meeting is logged and archived in a public location.
17:00:40 <zodbot> The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:40 <zodbot> The meeting name has been set to 'f31_final_go/no-go_meeting'
17:00:42 <bcotton> #meetingname F31-Final-Go_No_Go-meeting
17:00:42 <zodbot> The meeting name has been set to 'f31-final-go_no_go-meeting'
17:00:47 <bcotton> #topic Roll call
17:00:59 * pwhalen is here
17:01:03 * pbrobinson is here
17:01:15 * satellit_ listening
17:01:26 <bcotton> hello, p{whalen,robinson}, satellit_
17:01:46 <bcotton> also hello to pbrobinson, who was not included in the expansion above :-)
17:02:13 * pwhalen looks for probinson.. he might be the clone we ordered
17:02:19 <frantisekz> .hello2
17:02:20 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:02:28 <bcotton> welcome frantisekz
17:02:35 <frantisekz> Hi :)
17:02:45 <mboddu> .hello mohanboddu
17:02:46 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:03:17 <bcotton> hi mboddu
17:03:33 * mboddu waves at bcotton
17:04:22 <adamw> yo yo yo
17:04:26 <adamw> .hello adamwill
17:04:27 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:04:31 <bcotton> ahoj adamw
17:04:44 <adamw> ahoyhoy
17:05:21 <mboddu> .hire more yaks for testing
17:05:21 <zodbot> adamw hires more yaks for testing
17:05:28 <lruzicka> .hello2
17:05:30 <bcotton> .fire yaks
17:05:31 <spotz> o/ just peeking in:)
17:05:32 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:05:35 <zodbot> adamw fires yaks
17:05:49 <bcotton> we have too many yaks already. if they'd stop testing, we'd stop having bugs :p
17:05:59 <bcotton> welcome lruzicka and spotz
17:06:12 <mboddu> Haha, that is true
17:06:16 <spotz> thanks bcotton
17:06:20 <bcotton> okay, let's get this party started
17:06:24 <bcotton> #topic Purpose of this meeting
17:06:25 <bcotton> #info Purpose of this meeting is to check whether or not F31 Final is ready for shipment, according to the release criteria.
17:06:31 <lruzicka> bcotton, but you would not be able to drink milk and burn droppings :)
17:06:40 <bcotton> #topic Purpose of this meeting
17:06:41 <bcotton> #info Purpose of this meeting is to check whether or not F31 Final is ready for shipment, according to the release criteria.
17:06:45 <bcotton> no, bad copypasta
17:06:46 <bcotton> #undo
17:06:46 <zodbot> Removing item from minutes: INFO by bcotton at 17:06:41 : Purpose of this meeting is to check whether or not F31 Final is ready for shipment, according to the release criteria.
17:06:47 * mboddu sees party and grabs a beer :P
17:06:48 <bcotton> #undo
17:06:48 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f938de75b50>
17:07:06 <bcotton> #info This is determined in a few ways:
17:07:08 <bcotton> #info 1. No remaining blocker bugs
17:07:09 <bcotton> #info 2. Release candidate compose is available
17:07:11 <bcotton> #info 3. Test matrices for Final are fully completed
17:07:12 <bcotton> yay
17:07:34 <mboddu> 1. No, 2. No, 3. No
17:07:36 <bcotton> #topic Current Status — Blocker bugs
17:07:43 <bcotton> mboddu: right? should be an easy decision
17:08:00 <bcotton> #info 5 Proposed Blockers
17:08:02 <bcotton> #info 5 Accepted Blockers
17:08:14 <adamw> +1 mboddu i'm going for a drink
17:08:25 <frantisekz> :D
17:08:30 <mboddu> bcotton: #info nogo, #endmeeting and done :D
17:08:36 <bcotton> so i'm inclined to go ahead and do a blocker review for the 5 proposed blockers so that we can get the label slapped on them before monday. objections?
17:08:43 <adamw> fiiiiiiiiiiiiiiiine
17:08:47 <adamw> i'll bring my drink here
17:08:53 <bcotton> mboddu++
17:09:03 * pbrobinson gets a G&T
17:09:06 <mboddu> cheers adamw
17:09:06 <frantisekz> can't we just ship latest nightly ... :) ? openqa tested it... so
17:09:15 <bcotton> #topic (1761777) multilib issue with bashbug
17:09:16 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1761777
17:09:18 <bcotton> #info Proposed Blocker, bash, NEW
17:09:47 <mboddu> -1 Blocker, +1 FE - which I mentioned in the bug
17:09:54 <adamw> yeah, i haven't seen a justification for blocker here
17:10:38 <frantisekz> yeah, -1 blocker, is there a fix proposed already? I am a bit hesitant with FE...
17:10:50 <adamw> they seem to be arguing about the fix
17:11:10 <adamw> there's a ticket to update the multilib blacklist
17:11:10 <adamw> https://pagure.io/releng/issue/8906
17:11:11 <pbrobinson> can it be shipped as an update post release?
17:11:13 <frantisekz> I'd either punt or -1 FE before I see what's agreed to be a fix here
17:11:34 <pbrobinson> or does it affect live images and related
17:11:47 <mboddu> I think adding it to multilib should fix it
17:12:31 <adamw> which, i think requires an FE by releng policy
17:12:32 <mboddu> I merged multilib PR in rawhide, but unfortunately we couldn't get a rawhide since then due to other reasons
17:12:39 <adamw> so I'm +1 FE for a blacklist update
17:12:53 <lruzicka> they say that it is better to fix, because it might be worse fixing later, so I am +1FE
17:13:06 <adamw> i think the blacklist is applied at compose time
17:13:15 <mboddu> Right
17:13:16 <frantisekz> yeah, that sounds fine
17:13:18 <adamw> so if we apply the change before final compose, bash-devel will be left out of the x86_64 repo for the compose
17:13:22 <frantisekz> so +1 FE
17:13:25 <lruzicka> adamw, so we want it for RC
17:13:26 <adamw> if we don't, it will always be there in the frozen release repo
17:13:27 <adamw> yeah
17:13:35 <pbrobinson> +1FE
17:13:36 <pwhalen> +1 FE
17:13:37 <adamw> er, bash-devel.i686 i mean of course :)
17:13:39 <bcotton> -1 blocker, +1 FE
17:14:54 <bcotton> prooposed #agreed 1761777 - RejectedBlocker(Final), AcceptedFreezeException(Final) - This does not appear to violate any release criterion, however it is accepted as a Freeze Exception to avoid having an uninstallable package in the compose.
17:15:05 <frantisekz> ack
17:15:07 <pwhalen> ack
17:15:19 <lruzicka> ack
17:15:37 <adamw> ack
17:15:43 <pbrobinson> ack
17:15:49 <mboddu> ack
17:15:54 <bcotton> #agreed 1761777 - RejectedBlocker(Final), AcceptedFreezeException(Final) - This does not appear to violate any release criterion, however it is accepted as a Freeze Exception to avoid having an uninstallable package in the compose.
17:16:14 <bcotton> #topic (1691430) dnf.exceptions.Error: Incorrect or unknown "arch": armv7hcnl
17:16:15 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1691430
17:16:17 <bcotton> #info Proposed Blocker, dnf, POST
17:16:58 <mboddu> This is +1 blocker, and fixes are available, but not sure if dnf reviews/approves in the time frame
17:17:06 <pbrobinson> as the proposer this is critical for support for ARMv7 on a bunch of HW/virt environment inc next gen builder HW
17:17:13 * nirik is here now.
17:17:13 <mboddu> And I am not sure how invasive the fixes are
17:17:24 <frantisekz> I've talked with dnf guys today, they-re not sure about the safety of the fixes
17:17:25 <pbrobinson> the fixes aren't very invasive
17:17:43 <mboddu> Oh thats good to know
17:17:47 <frantisekz> but they said they-re willing to merge them downstream if I remember correctly
17:17:53 <mboddu> frantisekz: Whats their reasons?
17:18:04 <adamw> i'm kinda willing to be +1 on this if pbrobinson and nirik say so (i don't entirely understand the bug) but would prefer minimal change
17:18:20 <frantisekz> I didn't talk too much about the details, just quick talk in the office around the cubicle
17:18:21 <adamw> i still don't entirely understand the details of the bug
17:18:22 <pbrobinson> frantisekz: yes, but the other distro has revealed the reasons for their change and IMO it's no sustainable
17:18:31 <pwhalen> iiuc, this just goes back to the way it was before the patches were added
17:18:42 <pbrobinson> I've had some internal threads about some of it
17:19:09 <nirik> basically they made the stack check for some features on aarch64 hardware.
17:19:17 <pbrobinson> it doesn't revert it 100% but it fixes things to stop the problems we're having and the issues about supportable on arm platforms
17:19:29 <pbrobinson> I've also had people from Arm itself verify they are correct
17:19:36 <pwhalen> +1 blocker
17:20:20 <pbrobinson> I've dropped a couple of the patches that were incorrect architecturally but doesn't directly affect and it's old platforms we don't care about
17:20:37 <nirik> I don't know how widespread the affected hardware is... but I know for sure it affects the lenovo ampere stuff, which is enterprise gear... one of the only ones.
17:21:05 <frantisekz> yeah, I am willing to vote for +1
17:21:12 <bcotton> seems like there's a general consensus on blocker here, what criterion do we want to base it on?
17:21:21 <lruzicka> if pwhalen who usually does all the testing says +1, I throw my +1 in
17:21:47 <pbrobinson> bcotton: there's a number, virt, installing, updating.
17:21:55 <nirik> I'm a bit sad that dnf is so different in f31. ;( But oh well.
17:22:23 <lruzicka> this is because DNF team strive to make one DNF to rule them all
17:22:37 <adamw> does this only affect VMs? that's one thing i was not clear on
17:23:20 <nirik> well, but it's not... f30 and f32 are one version and f31 is an older version... but anyhow, that doesn't affect this bug that affects all of them, it just makes testing/fixing it harder
17:23:25 <pwhalen> adamw, I have only seen it on VM's
17:23:26 <pbrobinson> adamw: there's the potential there to affect things like RPi4 but we don't support that in F-31 ATM
17:23:32 <lruzicka> adamw, I think it affects certain boards, at least this is my understanding
17:23:34 <nirik> I think it's only vm's
17:23:47 <pbrobinson> because the kernel there is a complete shit show and I've not got drunk enough to deal with it
17:24:13 <bcotton> proposed #agreed 1691430 - AcceptedBlocker(Final) - This violates several criteria including "The release must be able host virtual guest instances of the same release."
17:24:17 <pbrobinson> but it would mean people couldn't use our images with a custom kernel
17:24:26 <mboddu> ack
17:24:27 <jlinton> Just to toss in here, I'm a little concerned about 32-bit containers on aarch64 kernels too
17:24:27 <pwhalen> ack
17:24:28 <nirik> ack
17:24:36 <frantisekz> ack
17:24:37 <adamw> sure, whatever, ack :P
17:24:43 <pbrobinson> ack
17:24:55 <pbrobinson> jlinton: agreed, I need to test that too
17:24:57 <pwhalen> good point jlinton
17:25:33 <bcotton> #agreed 1691430 - AcceptedBlocker(Final) - This violates several criteria including "The release must be able host virtual guest instances of the same release."
17:25:58 <bcotton> #topic (1762689) [abrt] gnome-software: gs_flatpak_get_installation(): gnome-software killed by SIGSEGV
17:25:59 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1762689
17:26:01 <bcotton> #info Proposed Blocker, gnome-software, NEW
17:26:06 <adamw> this one doesn't seem to have much info yet
17:26:17 <mboddu> Yeah, we need more info on this bug
17:26:26 <adamw> so far my instinct is -1, it doesn't seem like a general issue that hits the criteria, but i'd be fine with punting to monday as we clearly are gonna slip
17:26:38 <mboddu> +1 punt
17:26:56 <bcotton> any objections to leaving this for monday?
17:27:04 <nirik> yeah. +1 to get more info and leave
17:27:17 <frantisekz> I didn't see this in the wild, +1 punt
17:27:25 <bcotton> #agreed 1762689 - Deferred to Monday's blocker review meeting
17:27:34 <pwhalen> +1 punt/ack
17:27:40 <bcotton> #topic (1760307) CVE-2019-16746 kernel: buffer-overflow in net/wireless/nl80211.c [fedora-all]
17:27:40 <mboddu> ack
17:27:41 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1760307
17:27:43 <bcotton> #info Proposed Blocker, kernel, ON_QA
17:27:57 <lruzicka> +1 punt
17:28:04 <frantisekz> soo, there is moderate on cve details, +1 FE?
17:28:21 <frantisekz> lruzicka, was that to the previous bug?
17:28:35 <lruzicka> yeah, the one with flatpaks
17:28:44 <mboddu> I think, I am +1 FE
17:28:52 <mboddu> -1 Blocker
17:29:13 <bcotton> there are enough votes to accept this one as a freeze exception, and as it's ON_QA blocker status may be moot (hopefully)
17:29:37 <bcotton> anyone want to state with enthusiasm that we should accept/reject it as a blocker?
17:29:45 <lruzicka> why do not we want to block on that?
17:29:53 <frantisekz> on what basis lruzicka?
17:30:03 <pbrobinson> I don't mind the state, I feel we should have it in the release how ever you wish to tag it :)
17:30:07 <frantisekz> the cve criterion is only for higher impact imo
17:30:26 <lruzicka> The reason in comment 5?
17:30:46 <pbrobinson> frantisekz: well there's no documentation as to the impact, debian has it as high because remote
17:30:50 <adamw> the 'moderate' tag is somewhat suspicious to me
17:30:51 <lruzicka> It seems plausible to me that we want it in the release.
17:30:52 <nirik> +1 FE, not sure I would vote blocker without more info
17:30:56 <pbrobinson> IE it's affected by network
17:30:58 <adamw> yeah, local vs. remote seems like it's not agreed on
17:31:01 <adamw> RH has it as local
17:31:06 <adamw> but mitre has it as remote
17:31:15 <adamw> so 🤔🤔
17:31:21 <adamw> i think we can accept it as FE, get the update in and forget about it, though
17:31:25 <frantisekz> whatever... +1 FE would get it to the release anyway and that's what we can agree upon it looks
17:31:32 <pbrobinson> well it's the 802.11 stack and it's around SSID so a rouge SSID could potentially affect it?
17:31:57 <pbrobinson> but +1 FE or +1 blocker I don't mind
17:32:11 <lruzicka> but +1 FE does not guarantee that it is in the release if there is no fix ready. Can we make sure the fix is there?
17:32:28 <pbrobinson> the fix is ready there kernel is in updates-testing
17:32:32 <mboddu> I agree with adamw, accept it as FFE and push the update and leave it at that
17:32:34 <bcotton> okay, well it's already accepted as an FE, so let's defer to Monday to see if the fix worked and if not re-evaluate blocker?
17:32:35 <nirik> it may make things tricky if we have more kernel fixes and don't take this. ;)
17:32:42 <lruzicka> ok, so we can +1FE
17:32:45 <adamw> yeah, punt on blocker
17:32:59 <lruzicka> great
17:33:00 <pwhalen> +1punt
17:33:09 <lruzicka> +1 fe, +1 punt on blocker
17:33:19 <bcotton> #agreed 1760307 - Previously accepted as a Freeze Exception. Blocker decision deferred to Monday's blocker review meeting
17:33:43 <bcotton> #topic (1762291) Discover does not refresh after manipulating packages which results in error messages.
17:33:44 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1762291
17:33:46 <bcotton> #info Proposed Blocker, plasma-discover, NEW
17:35:03 <frantisekz> -1 Blocker, it seems it only happens if you remove the package really soon after installation if I understand it properly
17:35:23 <nirik> -1 blocker, +1 FE...
17:35:27 <adamw> kparal is now amending that to 'it may happen any time within the same run of the app'
17:35:39 <adamw> but still, installing and removing in one app session seems pretty uncommon to me
17:35:47 <pwhalen> -1 blocker , +1 FE
17:35:54 <lruzicka> adamw, you can change your mind
17:35:58 <adamw> the only case i can see for 'install and remove' is "whoops fat fingered it"
17:36:04 <lruzicka> adamw, or hit a wrong Install button
17:36:04 <adamw> which, i mean, i guess it happens
17:36:06 <mboddu> -1 Blocker, +1 FE as its not breaking things, just a ugly behaviour
17:36:07 <adamw> yeah
17:36:15 <adamw> but the fact that it's not new is an argument against blocker
17:36:19 <adamw> so, i think -1 blocker / +1 fe
17:36:39 <pbrobinson> yes +1FE -1 blocker
17:37:03 <lruzicka> as you wish
17:37:13 <lruzicka> but don't blame me
17:37:40 <frantisekz> you have your right to say "I told you" lruzicka :)
17:37:49 <bcotton> proposed #agreed 1762291 - RejectedBlocker(Final), AcceptedFreezeException(Final) - This seems to be a rare case in real usage, but it's worth having a fix in the compose. We are forbidden from blaming lruzicka.
17:37:52 <lruzicka> such bugs could eat the whole desktop bread
17:37:53 <mboddu> ack
17:37:59 <frantisekz> ack
17:37:59 <nirik> ha. ack
17:37:59 <lruzicka> ack
17:38:09 <pwhalen> ack
17:38:21 <spotz> :)
17:38:36 <adamw> ack
17:38:41 <bcotton> #agreed 1762291 - RejectedBlocker(Final), AcceptedFreezeException(Final) - This seems to be a rare case in real usage, but it's worth having a fix in the compose. We are forbidden from blaming lruzicka.
17:39:28 <bcotton> okay, that's the end of the proposed blockers. i do want to mention this accepted blocker for the record
17:39:31 <bcotton> #topic (1747408) Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
17:39:33 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1747408
17:39:34 <bcotton> #info Accepted Blocker, distribution, NEW
17:39:43 <nirik> such a fun one. ;)
17:39:45 <frantisekz> :)
17:39:50 <bcotton> this is starting to feel like a bug that will have us slipping until thanksgiving
17:39:57 <pwhalen> heh, now get the drinks
17:39:58 * nirik thinks we should just do the compat package and move on
17:40:08 <bcotton> so i am open to suggestions on how we can get everyone to agree on a solution
17:40:20 * mboddu thinks beer isn't good enough and needs a much stronger drink
17:41:19 <lruzicka> the DNF team approached me with their solution on Monday -> they wanted to pull an error message string, but FESCo voted against this.
17:41:19 <bcotton> we don't have to get into this now, but if you have ideas later, i'd be happy to hear them. we need to come to *some* solution soon, preferably a good one
17:41:30 <frantisekz> proposed solutions  are in https://bugzilla.redhat.com/show_bug.cgi?id=1747408#c72 , if you don't want to scroll throughout that page
17:41:32 <adamw> i think there are sufficient ideas in the bug
17:41:48 <adamw> either pull the compat package into f31 or just write the workaround into dnf-plugin-system-upgrade and gnome-software
17:41:49 <bcotton> yeah, now we just need to figure how to to get people to agree to one of the ideas
17:41:54 <lruzicka> and they said the would love to fix it but they needed "clear requirements"
17:42:05 <adamw> i think i like the 'do the workaround in dnf and g-s' idea best
17:42:07 <nirik> I think the compat package is the best answer. ;(
17:42:11 <adamw> FITE ME
17:42:23 <frantisekz> imo, I'd vote for solution #1 , seems safest not to cause any more delays
17:42:24 <lruzicka> what exactly is a compat package?
17:42:24 <adamw> 👊
17:42:37 <bcotton> okay, well i'll continue to use my charm to try to get this worked out :-)
17:43:11 <bcotton> executive decision: we'll skip voting on the two proposed
17:43:11 <frantisekz> also FESCO can create blocker for F32 to ensure we don't need to have another ugly solution for F32
17:43:26 <bcotton> two proposed FEs, that is
17:43:33 <bcotton> so i guess let's move on to the compose
17:43:34 <mboddu> I prefer #1 just because its a known ugly solution
17:43:45 <bcotton> #topic Current status — Candidate compose
17:43:49 <nirik> the compat package is adding a libgit2_0.28 package to f31 (or 0.27? would have to look)
17:44:00 <bcotton> no candidate yet, i believe?
17:44:08 <mboddu> bcotton: Yes
17:44:09 <lruzicka> nirik, an unmodular package?
17:44:17 <nirik> correct
17:44:20 <mboddu> lruzicka: Yes
17:44:30 <bcotton> #info No candidate compose has been requested
17:44:32 <adamw> no candidate, yeah, since we still have outstanding blockers
17:44:40 <bcotton> are we still composing well in general?
17:44:44 <adamw> yeah
17:44:46 <nirik> yep.
17:44:51 <mboddu> Yup
17:44:55 <bcotton> well at least there's that :-)
17:45:05 <nirik> there are still some spins/labs that are failing
17:45:05 <adamw> nightlies are composing and passing everything in openqa except the arm test which has been busted forever and a modularity check which finds a ton of known bugs
17:45:18 <bcotton> #info nightlies are composing and passing everything in openqa except the arm test which has been busted forever and a modularity check which finds a ton of known bugs
17:45:30 <nirik> also armv7 containers have been failing since forever.
17:45:31 <bcotton> nirik: do the spins/labs owners know this?
17:45:34 <lruzicka> yes, modularity usually fails on incorrect module definitions
17:45:46 <nirik> I mailed out a status a few weeks ago to spins and devel...
17:46:03 <bcotton> nirik++
17:46:05 <mboddu> May be we should send another email
17:46:09 <nirik> which was great, because one of the broken ones made me see we were building f31 with rawhide kickstarts. ;)
17:46:25 <bcotton> yeah, wouldn't hurt to do another round before we get a candidate
17:46:27 <nirik> we can, but can we get changes in now? or they would need FE's?
17:46:38 <lruzicka> there are like 18 modules, that do not have default streams (some of the on purpose) and some of them do not have the yaml file in fedora-module-defaults.
17:46:38 <Southern_Gentlem> which spins
17:46:41 <adamw> yeah, but hey, we can do FEs.
17:47:14 <nirik> https://pagure.io/releng/failed-composes/issue/331
17:47:25 <bcotton> #link https://pagure.io/releng/failed-composes/issue/331
17:47:40 <bcotton> okay, let's move on to test coverage
17:47:41 <mboddu> They would need FE's and we can always say if they are invasive
17:47:43 <nirik> Games, Scientific-KDE, Jam-KDE, Scientific
17:47:53 <bcotton> #topic Current status — test coverage
17:47:53 <nirik> and arm containers/server
17:48:22 <adamw> as always, https://www.happyassassin.net/testcase_stats/31/
17:48:44 <bcotton> #link https://www.happyassassin.net/testcase_stats/31/
17:48:49 <adamw> cloud tests haven't been run for nearly a month
17:48:52 <Southern_Gentlem> non of those are actual blocking are they
17:48:59 <Southern_Gentlem> none
17:49:02 <adamw> yes they are
17:49:07 <adamw> cloud images are still technically release blocking
17:49:29 <frantisekz> adamw, I can do local cloud tests tomorrow
17:49:39 <adamw> until we decide coreos is gonna replace them or whatever, but that hasn't happened yet
17:49:40 <mboddu> Southern_Gentlem: Nope, they are not blocking
17:49:40 <adamw> thanks
17:49:46 <adamw> yes they are :P
17:49:51 <frantisekz> :D
17:49:52 <Southern_Gentlem> i meant the games, scientific-kde or the jam-kde
17:50:02 <adamw> ohhh sorry
17:50:04 <adamw> cross purposes
17:50:05 <frantisekz> no, those spins aren't blocking
17:50:18 <mboddu> ^^ which is what I thought Southern_Gentlem is asking for
17:50:19 <nirik> not blocking, but it would be nice to have them for once...
17:50:29 <adamw> desktop tests for ARM haven't been run since beta
17:50:38 <bcotton> why haven't the cloud tests been run?
17:50:51 <adamw> bcotton: i mean, because no-one did them?
17:51:31 <adamw> AD tests haven't been done yet
17:51:32 <bcotton> that would certainly explain it!
17:51:42 <adamw> sgallagh, do we have anyone doing those atm?
17:52:19 <pwhalen> adamw, I've been testing the desktop, I'll update the wiki
17:53:01 <adamw> thanks pwhalen
17:53:07 <frantisekz> pwhalen++
17:53:07 <zodbot> frantisekz: Karma for pwhalen changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:53:25 <adamw> default boot and install tests are showing empty since beta, which suggests to me i've got a wiki reporter bug for openqa, i'll look into that...the physical media tests we'll do when we have a candidate compose
17:53:44 <adamw> no-one has formally run the xen test the whole cycle
17:53:59 <adamw> raid tests need doing
17:54:06 <adamw> but mostly, we're looking decent
17:54:46 <bcotton> #info mostly, we're looking decent
17:54:50 <sgallagh> adamw: Sorry, I haven’t done them yet. I didn’t prioritize it because it was clear we were not going this week and I have a lot else on my plate
17:55:03 <adamw> sure, as long as we get them done for the candidate should be fine
17:55:13 <adamw> though you know, if it's broken it'd be good to find out :P
17:55:16 <sgallagh> I’m at a school event for my daughter right now. I’ll get on those later.
17:55:28 * sgallagh leaves
17:55:29 <bcotton> okay, so let's get to the heart of the matter
17:55:31 <bcotton> #topic Go/No-Go decision
17:55:38 <bcotton> not much of a decision to make
17:55:45 <bcotton> any objections to a "No-Go"?
17:55:48 <lruzicka> nope
17:56:06 <bcotton> #agreed Fedora 31 final is No-Go
17:56:14 <bcotton> #action bcotton to announce decision
17:56:18 <bcotton> #topic Next meeting
17:56:31 <bcotton> So normally we do the same time the following Thursday
17:56:35 <adamw> fixed the wiki reporting bug...
17:56:36 <bcotton> but i have a bit of a conflict
17:56:41 <bcotton> adamw++
17:56:43 <adamw> obvs no-go
17:56:59 <bcotton> so how do we feel about 1400 UTC on Thursday 24 October?
17:57:01 <nirik> yeah, no go
17:57:13 * nirik is going to be out next week, but everyone else have fun. :)
17:57:24 <frantisekz> bcotton, sounds good
17:57:36 <mboddu> nirik: Define fun? ;)
17:57:53 <bcotton> mboddu, adamw: 1400 UTC next Thursday work?
17:58:00 <adamw> ugh
17:58:01 <adamw> that sounds early
17:58:09 <adamw> that's uh
17:58:11 <mboddu> That works for me
17:58:11 <adamw> 7am?
17:58:14 <adamw> well i might be a bit late
17:58:15 <frantisekz> oh, I've forgot about adamw :D
17:58:19 <bcotton> adamw: yeah, unfortunately
17:58:25 <adamw> i'll do my best
17:58:28 <bcotton> but at least it means our Brno friends can do home earlier
17:58:41 <lruzicka> is that 16:00 CET?
17:58:42 <frantisekz> yeah, we'd be pretty happy about that timing :D
17:58:45 <frantisekz> yeah
17:59:01 <lruzicka> ok, no objection
17:59:03 <adamw> let's make sure the meeting is *really long*
17:59:21 <lruzicka> adamw, we can discuss the libgit bug
17:59:26 <bcotton> i'll bring some extra coffee for you, adamw
17:59:34 <mboddu> adamw: I got you covered for it :)
17:59:41 <mboddu> lruzicka: Exactly :)
18:00:01 <bcotton> #agreed The next Go/No-Go meeting will be *1400* UTC on Thursday 24 October
18:00:25 <bcotton> #action bcotton to check meeting room availability
18:00:44 <bcotton> #info The F31 Final Release Readiness meeting will be in 60 minutes in #fedora-meeting-1
18:00:49 <bcotton> #topic Open floor
18:01:03 <bcotton> anything else before we all resume banging our heads on our desks?
18:02:12 <mboddu> Nada
18:02:21 <adamw> bcotton: you stopped?
18:02:38 <lruzicka> not here
18:02:39 * Southern_Gentlem loads more bullets for the dead horses
18:02:45 <bcotton> adamw: just long enough to type
18:02:49 <bcotton> Southern_Gentlem++
18:02:49 <lruzicka> Southern_Gentlem, get a decent whip
18:03:03 <bcotton> when a problem comes along, you must whip it
18:03:08 <lruzicka> Southern_Gentlem, maybe you can beat them to achieve more
18:03:13 <bcotton> okay, sounds like we've been as productive as we know how
18:03:18 <bcotton> thanks everyone, see you next week!
18:03:21 <bcotton> #endmeeting