17:00:01 <bcotton> #startmeeting F34 Final Go/No-Go meeting\
17:00:01 <zodbot> Meeting started Fri Apr 23 17:00:01 2021 UTC.
17:00:01 <zodbot> This meeting is logged and archived in a public location.
17:00:01 <zodbot> The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:01 <zodbot> The meeting name has been set to 'f34_final_go/no-go_meeting\'
17:00:06 <bcotton> gah
17:00:09 <bcotton> good enough
17:00:18 <bcotton> #meetingname F34-Final-Go_No_Go-meeting
17:00:18 <zodbot> The meeting name has been set to 'f34-final-go_no_go-meeting'
17:00:23 <nirik> morning
17:00:24 <mboddu> .hello mohanboddu
17:00:25 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:00:28 <bcotton> #topic Roll Call
17:00:37 <coremodule> .hello2 coremodule
17:00:38 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:00:51 <Eighth_Doctor> .hello ngompa
17:00:51 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:01:31 <michel_slm> .hello salimma
17:01:32 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
17:01:49 <sumantro> .hello2 sumantrom
17:01:50 <zodbot> sumantro: sumantro 'Sumantro Mukherjee' <sumantro@outlook.com>
17:01:51 <lruzicka[m]> .hello lruzicka
17:01:53 <zodbot> lruzicka[m]: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:02:19 <pwhalen> .hello pwhalen
17:02:20 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
17:02:39 <adamw> .hello adamwill
17:02:40 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:02:51 <geraldosimiao> .hello geraldosimao
17:02:52 <zodbot> geraldosimiao: Sorry, but you don't exist
17:03:08 <geraldosimiao> .hello geraldosimiao
17:03:09 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
17:04:42 <bcotton> i'll give another minute or two to see if any more fesco members show up. we're at 1/9 right now by my count
17:05:00 <bcotton> .members fesco
17:05:01 <zodbot> bcotton: Members of fesco: churchyard cverna dcantrell decathorpe ignatenkobrain @kevin ngompa sgallagh zbyszek
17:05:23 <lruzicka[m]> .members qa
17:05:24 <zodbot> lruzicka[m]: Members of qa: a2batic aaronraimist abhi23 abhirhc abougouffa acaldwell acousticpanic @adamwill adityaramteke aernhart afcastro agarwalvarshit +agmon +ahlshe ahutsona aishvarya ajinkyaunitix akashad2519 akinsola aklmv akshat0014 akshays +akshayvyas29 akumar99 +alciregi alen alexklein5 ali4129 allanitomwesh alphacar amandacavalcante amcg amsharma anabsc anand97 anandprakash anazli anchal7299 andilinux andrzejp  (10 more messages)
17:05:32 <lruzicka[m]> oops
17:05:40 <lruzicka[m]> sorry about that
17:05:51 <bcotton> :-)
17:06:02 <bcotton> #topic Purpose of this meeting
17:06:11 <bcotton> #info Purpose of this meeting is to check whether or not F34 Final is ready for shipment, according to the release criteria.
17:06:17 <bcotton> #info This is determined in a few ways:
17:06:21 <bcotton> #info 1. No remaining blocker bugs
17:06:27 <bcotton> #info 2. Release candidate compose is available
17:06:36 <bcotton> #info 3. Test matrices for Final are fully completed
17:06:43 <bcotton> #topic Current status - blockers
17:06:49 <bcotton> #link https://qa.fedoraproject.org/blockerbugs/milestone/34/final/buglist
17:07:07 <bcotton> okay, and because i've learned my lesson, we'll start with the accepted blockers first :-)
17:07:12 <bcotton> #topic (1952431) startplasma-wayland hangs when run in basic video mode (nomodeset; VESA (BIOS) / FBDEV (UEFI) )
17:07:19 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1952431
17:07:30 <bcotton> #info Accepted Blocker, kwin, VERIFIED
17:07:36 <bcotton> yay for being VERIFIED!
17:07:45 <bcotton> #topic (1938630) include new bootloaders on Fedora 34 install media so UEFI Secure Boot enabled systems can boot from them
17:07:54 <lruzicka[m]> works on both desktops with rc2
17:08:03 <adamw> yeah, and it has certainly been carefully reviewed and tested since neal and i invented it between us twelve hours ago
17:08:10 <bcotton> :-)
17:08:15 <bcotton> 12 hours is an eternity in technology
17:08:17 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1938630
17:08:24 <bcotton> #info Accepted Blocker, shim, ON_QA
17:08:36 <bcotton> so this one is actually VERIFIED too at this point, yeah?
17:09:13 <adamw> well, there certainly are new bootloaders!
17:09:19 <adamw> and i checked my dell case is fixed
17:09:51 <lruzicka[m]> I am not using Secureboot, but I have not experienced any problems with booting.
17:10:01 <pjones> lruzicka[m]: that's an important test case as well :)
17:10:07 <bcotton> what higher form of validation is there than "works on my machine"?
17:10:23 <Eighth_Doctor> my Macs booted fine
17:10:35 <Eighth_Doctor> though I'm finishing up testing my daily driver Linux Mac now
17:11:17 <adamw> bug updated
17:11:41 <bcotton> hooray
17:11:50 <bcotton> #info BZ 1938630 is VERIFIED
17:12:01 <bcotton> #topic (1951194) [abrt] tracker: tracker_vtab_triples_init(): tracker3 killed by SIGSEGV
17:12:06 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1951194
17:12:12 <bcotton> #info Accepted 0-day Blocker, tracker, VERIFIED
17:12:20 <bcotton> our accepted 0-day blocker: also verified
17:12:30 <bcotton> which now leads us to  our proposed blocker...
17:12:35 <bcotton> #topic (1942443) Login using password failed after upgrade to Fedora 34
17:12:41 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1942443
17:12:46 <bcotton> #link https://pagure.io/fedora-qa/blocker-review/issue/317
17:12:50 <frantisekz> .hello2
17:12:51 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:12:51 <bcotton> #info Proposed Blocker, gdm, ON_QA
17:12:57 <bcotton> #info Ticket vote: FinalBlocker (+5,0,-0) (+bcotton, +kevin, +mohanboddu, +nb, +catanzaro)
17:13:06 <Eighth_Doctor> this could be a zero-day update release no?
17:13:19 <Eighth_Doctor> it doesn't impact new installs, just upgrades
17:13:24 <frantisekz> yes
17:13:27 <bcotton> so i voted for this as a blocker, but i think 0-day or "not actually a problem" may be more accurate. i can't quite get a read on the current state
17:13:27 <Eighth_Doctor> and we don't have a way to upgrade from GA media
17:13:45 <adamw> we are talking about in in #fedora-desktop
17:13:47 <adamw> confusion sort of reigns
17:13:57 <adamw> but insofar as all the issues involve upgrades, yeah, it can at least be a 0day
17:14:19 * nirik is fine with 0day based on what he knows currently about it.
17:15:07 <mboddu> Is it though?
17:15:33 <bcotton> so there's a bit of a procedural question of: if we end up being go and the bug isn't fixed on tuesday at 1400 UTC, what happens? do we kick the can day-by-day? automatically move to the following week? just hold off on pushing the button until the fix lands at 1430
17:15:40 <mboddu> Just for an instance, upgraded from f33 to f34 and rebooted without updating the system, then the user cannot login anymore
17:16:16 <bcotton> that doesn't really change whether or not it's a blocker, i just don't have any experience with how we'd handle this scenario and i'd like to understand
17:16:16 <adamw> in general, the answer has been that unless we're very sure we can have a fix pushed by release day, we say no-go at this meeting
17:16:19 <frantisekz> f33 to f34 upgradea should be fine afaik
17:16:30 <adamw> we only go with an unfixed 0day blocker if it's, like, extremely clear that we can fix it
17:17:00 <nirik> adamw: +1, thats my understanding as well.
17:17:02 <adamw> so um to step back and look at the forest not the trees for a bit
17:17:09 <adamw> i'd probably be -1 on any remaining case of this
17:17:44 <adamw> there probably are real systems out there that might/will hit it, but i mean, we don't have a perfect record of perfect upgrades for everybody
17:17:51 <adamw> we're hitting the criteria as things stand
17:18:16 <adamw> i'd like to have the fix in for release, but it's probably not blocker material aiui
17:18:26 <frantisekz> the fix should be just adding authselect -f into scriptlets if I am not mistaken?
17:18:45 <bcotton> that's kind of how i read it, but i'm not 100% clear I understand it, so I don't want to be more overconfident than i normally am
17:19:06 <bcotton> but, it sounds like we have consensus that this should be evaluated as a 0-day blocker, not a final blocker. does anyone object to that?
17:19:08 <adamw> frantisekz: that's a fairly large hammer and we probably shouldn't do it for f34 now
17:19:14 <Eighth_Doctor> I'm reasonably okay as a FESCo person to accept `authselect -f` being autorun
17:19:16 <adamw> that may happen for f35
17:19:27 <adamw> there is a known broad spectrum fix for f34 where we just make login work even if the config is in the bad state
17:20:08 <Eighth_Doctor> but regardless, as happyassassin[m] says, there seems to be a broad fix already, so I say we accept it and move on
17:20:25 <adamw> team is working on builds with the fix now, see discussion in bug
17:20:30 <nirik> so then... you're proposing we reject this as a blocker then?
17:20:38 <nirik> or there's still a 0day fix?
17:20:39 <Eighth_Doctor> yup
17:20:41 <adamw> that's what i'm proposing. i dunno what neal's proposing.
17:20:44 <Eighth_Doctor> same thing
17:20:50 <bcotton> so let's have some votes on 0-day blocker status
17:20:52 <bcotton> -1 0day
17:21:03 <frantisekz> -1 0day
17:21:08 <Eighth_Doctor> -1 0day
17:21:31 <Eighth_Doctor> (actually, what does that mean? not blocker and allow as zero day? or what?)
17:21:40 <nirik> to be clear, if there's a fix/update and it's stable before release, it will be a 0day...
17:21:47 <adamw> conan_kudo[m]: a 0day blocker is still a blocker
17:21:50 <bcotton> it means it's not a blocker but it can land in the updates on release day
17:21:55 <Eighth_Doctor> ah, okay
17:21:56 <bcotton> if there's an update
17:21:58 <adamw> to not be a blocker but still be fixed 0day, the bug needs no special status
17:22:12 <adamw> er, let's be clear here
17:22:17 <Eighth_Doctor> okay, so did I vote right for that?
17:22:21 <Eighth_Doctor> because I now don't know
17:22:33 <benzea> hmm, so, right now I am not entirely clear if the gnome-shell fix really fully fixes the issue; users might have only little time to enter the password and login with the proper fix
17:22:36 <adamw> i think the vote is right but ben's explanation is wrong. :D
17:22:45 <adamw> there's no "can land on release day" status. all bugs are that.
17:22:57 <adamw> we do a general push of updates queued for stable shortly before release.
17:22:59 <bcotton> yeah, that's what i meant
17:23:09 <bcotton> it's no different from any other bug in that regard
17:23:24 <mboddu> -1 0day, adamw convinced me
17:23:25 <nirik> yeah, -1 to giving this bug 0day blocker status
17:23:30 <adamw> ok, cool.
17:23:37 <bcotton> perhaps what i meant tosay was "it's not a blocker, but nothing prevents it from landing in the updates on release day"
17:23:55 <Eighth_Doctor> so then I think I voted correctly 🙂
17:24:37 <bcotton> proposed #agreed 1942443 - RejectedBlocker(0day) - We can't be sure no one will hit this, but it does not violate the criteria as written. There is a known broad spectrum fix for f34 where we just make login work even if the config is in the bad state
17:24:44 <mboddu> ack
17:24:50 <frantisekz> ack
17:24:50 <Eighth_Doctor> ack
17:24:53 <Southern_Gentlem> ack\
17:25:02 <lruzicka[m]> ack
17:25:09 <nirik> ack
17:25:20 <coremodule> ack
17:25:41 <sumantro> ack
17:25:51 <adamw> ack
17:25:53 <bcotton> #agreed 1942443 - RejectedBlocker(0day) - We can't be sure no one will hit this, but it does not violate the criteria as written. There is a known broad spectrum fix for f34 where we just make login work even if the config is in the bad state
17:26:04 <bcotton> #topic Current status - blockers
17:26:13 <bcotton> #info All accepted blockers are VERIFIED
17:26:30 <bcotton> #topic Current status - RC
17:26:31 <Eighth_Doctor> 🎉
17:26:46 <bcotton> #info RC2 is the current release candidate
17:27:05 <bcotton> i beliieve I saw Design and Scientific labs failed on all arches?
17:27:17 <bcotton> but everything else succeeded?
17:27:23 <nirik> no?
17:27:29 <nirik> cinnamon failed
17:27:33 <Southern_Gentlem> i think cinn failed
17:27:38 <nirik> nothing else
17:27:46 <bcotton> hm. what was i looking at then?
17:27:48 * bcotton shrugs
17:27:52 <mboddu> Only cinnamon failed
17:28:11 <nirik> and...
17:28:23 <adamw> someone said something about lxqt missing packages also
17:28:23 <nirik> actually, it failed upoading/writing.
17:28:27 <adamw> i dunno what's up with any of that
17:28:31 <Southern_Gentlem> its not
17:28:40 <nirik> there's an iso, not sure if it's incomplete tho
17:28:45 <Eighth_Doctor> the failure wasn't in the image build, just writing the image
17:28:51 <Eighth_Doctor> for cinnamon
17:28:53 <Southern_Gentlem> same as beta so no missing packages
17:28:57 <nirik> yep
17:29:10 <Southern_Gentlem> lxqt that is
17:29:19 <bcotton> ah, i was looking at Fedora-34-20210423.n.0, not Fedora-34-20210423.0
17:29:24 <bcotton> tricky
17:29:30 <nirik> bcotton: yeah, watch the n there. :)
17:29:41 * nb is curious, what is the n mean
17:29:44 <Southern_Gentlem> about 100 less packages in f34 1.2 than in my f33-20210416
17:29:54 <sumantro> n is nightly
17:29:58 <nb> oh
17:29:59 <Eighth_Doctor> ah
17:30:02 <Eighth_Doctor> I wondered about that
17:30:02 <bcotton> nb: Not the one I should have looked at
17:30:13 <mboddu> nb: nightly
17:30:14 <Southern_Gentlem> but lxqt works
17:30:22 <Eighth_Doctor> but we do technically have everything, Koji just flipped out on archiving cinnamon
17:30:38 <bcotton> #info RC2 is missing the Cinnamon Spin, which built but did not upload
17:30:40 <Eighth_Doctor> which if we re-ran that job, that would be fixed, right?
17:30:42 <nirik> I wonder if a resubmit would work.
17:30:56 <Southern_Gentlem> **fingers crossed**
17:31:36 <bcotton> only one way to find out!
17:31:47 <bcotton> anything else we want to say about RC2 before we move on to test coverage?
17:31:53 <mboddu> Eighth_Doctor: It could, but pungi wont collect the result
17:32:00 * nirik looks at the shiny shiny button.
17:32:06 <Eighth_Doctor> mboddu: we could manually yoink it, no?
17:32:12 <nirik> mboddu: yeah, we would have to manually put it in place. ;(
17:32:14 <nb> mboddu could it be put in place manually?
17:32:30 <mboddu> True ^
17:32:48 <Eighth_Doctor> for one image, that's not too bad
17:33:06 <nirik> well, and it would need fixing he checksum files. ;( so it would be a bit anoying.
17:33:11 <Southern_Gentlem> cinn is not a blocking issue so it it isnt there the respins will have it
17:33:19 <adamw> and it would make the metadata a lie.
17:33:43 <mboddu> Exactly
17:33:47 <bcotton> yeah, but if we don't have official isos, we should probably take it off the spins page for this release, which is bad for discoverability
17:33:48 <mboddu> Its not worth that much
17:34:06 <bcotton> so we'll leave it missing, is that what i'm hearing?
17:34:07 <Eighth_Doctor> it'd be kind of bad to have it missing if we know we have the artifact
17:34:10 <nirik> we could also do what we have before... stick it on alt. But that still needs websites changes.
17:34:30 <Southern_Gentlem> bcotton, will not be the first time a spin has been missing from the release
17:34:30 <Eighth_Doctor> can the metadata be altered to include the missing info?
17:34:44 <bcotton> Southern_Gentlem: oh i know, it just makes me sad
17:34:58 <adamw> conan: if someone wants to go do things to pdc, i guess.
17:35:11 * nb thinks it would be good to have the spin there (even if it ends up on alt)
17:35:18 <nirik> IMHO, we should stick it on alt and see if websites can point to it there.
17:35:30 <Eighth_Doctor> if we can do something at all, then I'm happy
17:35:31 <nirik> (which we did for some other things in the past)
17:35:40 <mboddu> The easiest way is to put it in alt and update the websites
17:35:41 <bcotton> doing that is no jankier than the rest of the spins site
17:35:45 <nb> relrod ping
17:35:56 <bcotton> okay, let's agree to that then
17:36:13 <relrod> pong
17:36:33 <bcotton> #agreed We will put the Cinnamon deliverables on alt and update the website to point there instead of the normal location
17:36:39 <nirik> ack
17:36:44 <Southern_Gentlem> ack
17:36:47 <Eighth_Doctor> ack
17:36:47 <nb> relrod they were talking about updating websites to have cinnamon on alt
17:36:53 <nb> so i pinged you
17:36:56 <mboddu> relrod: If I put the cinn spin in alt, can you update the websites to point to that location?
17:36:57 <mboddu> ack
17:37:04 <relrod> Okay.
17:37:25 <nb> ack
17:37:28 <bcotton> the edits for that are probably still in the page, just commented out from last time :-D
17:37:37 <bcotton> #topic Current status - test matrices
17:37:43 <bcotton> #link https://fedoraproject.org/wiki/Category:Fedora_34_Test_Results
17:37:43 <Southern_Gentlem> okay yes or ok that will work?
17:38:36 <relrod> Okay as in I'll make the change this weekend when I work on websites ;)
17:38:46 <bcotton> so, how 'bout them tests?
17:38:56 <adamw> we are not at full matrix coverage.
17:39:06 <adamw> even with heavy reliance on automation and transferring results from rc1, we are missing several things
17:39:17 <adamw> we don't have aarch64 usb installer boot/install testing
17:39:30 <adamw> we don't have x86_64 cloud tests run in a real cloud
17:39:30 <adamw> we don't have active directory tests run
17:39:45 <jlinton> I'm testing the aarch64/boot install as we speak, looking good so far.
17:39:54 <adamw> we don't have hardware RAID or fcoe run
17:40:07 <adamw> thanks jlinton
17:40:19 <coremodule> testing x86 cloud in a real cloud rn
17:40:23 <bcotton> that's a lot of missing coverage :/
17:40:36 <pwhalen> he also tested it in 1.1 I beleive, jlinton?
17:40:48 <adamw> i don't see results in the rc1 matrix
17:40:51 <jlinton> Yes, the previous version was fine.
17:41:00 <adamw> ok.
17:41:16 <sumantro> adamw, Cloud Test day showed positive results https://testdays.fedoraproject.org/events/112. It was off Fedora-Cloud-Base-34-20210415.n.0.x86_64
17:41:22 <adamw> yeah it's funny how you get missing coverage when the rc finishes three hours before the meeting
17:41:22 <pwhalen> adamw: in uefi usb
17:41:42 <nirik> need more bots. :)
17:41:52 <bcotton> or fewer tests
17:41:57 <lruzicka[m]> nirik: we are working on it
17:42:17 <nirik> or... when you get right down to it: less files.
17:42:17 <pwhalen> openqa is still working on aarch64 testing
17:42:18 <lruzicka[m]> nirik: but for some things even the bots fail too short
17:42:19 <adamw> the silverblue installer image does not contain the right ostree, it seems
17:42:26 <adamw> it has 20210423.n.0
17:42:37 <adamw> pwhalen: i restarted some tests that failed
17:42:53 <adamw> ditto for x86_64, which is why the desktop matrix is a wasteland
17:43:07 <adamw> oh, it's mostly done with the x86_64 reruns now.
17:43:09 <pwhalen> iot - https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20210422.0_General
17:43:19 <adamw> oh yeah, iot!
17:43:33 <pwhalen> We're going with todays compose, which I also tested and looks the same in openqa.
17:43:56 <pwhalen> I believe. pbrobinson will make the call there.
17:44:25 <mboddu> adamw: the ostree is updated by only nightlies, after we are go, we push the final stable updates and run another regular nightly compose
17:44:56 <nb> adamw are there AMIs for the RC?
17:44:57 <adamw> uh, okay? but then the gold silverblue installer image won't deploy that, will it?
17:44:59 <adamw> it deploys what's baked into it
17:45:06 <adamw> nb: yes, they are linked on the validation page as usual
17:45:18 <pwhalen> nb: yes, I tested the aarch64 ami
17:45:34 <adamw> https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Cloud , see the tables at the top - if you want something from one of the collapsed tables, hit "Expand"
17:45:58 <nb> adamw pwhalen I can spin up a x86_64 in AWS
17:46:01 <mboddu> adamw: It does have the same content, so, it should be fine
17:46:43 <adamw> the nightly doesn't have the same content. it doesn't have the things we pulled into the rc compose, right?
17:46:43 <pwhalen> nb: thats what I do as well
17:46:51 <adamw> still, silverblue is not blocking, but this just feels suboptimal.
17:47:47 <coremodule> x86 cloud in AWS looks good
17:47:54 <coremodule> adding to the matrix now
17:47:55 <mboddu> adamw: Which is why we run another nightly compose after pushing the updates whatever in the RC, ending up with same content
17:48:29 <bcotton> adamw: are you: 1. feeling suboptimal, but could live with the current state; 2. could live with the current state if we paused the proceedings for another half or hour so; 3. cannot in good conscience say "go" by the end of this meeting no matter what happens in the next 60 minutes?
17:48:32 <nirik> I think the silverblue thing is an artifact of both the nightly and the rc's using the same ref 'f34'
17:48:34 <adamw> mbod: but that content is still not in the silverblue image we release, is it? i don't see how it can be
17:48:45 <adamw> Ben Cotton: i dunno about half an hour. it's a lot of moving parts.
17:48:53 <adamw> i also am just not a fan in general of releasing things we built three hours ago
17:48:58 <adamw> we keep saying we're not going to do this then doing it
17:49:16 <lruzicka[m]> +1
17:49:35 <pwhalen> +1
17:49:39 <adamw> it's super fun cranking out udev rules at 1am and all but it does not seem like optimal software development procedure
17:49:54 <bcotton> i am in full agreement there
17:50:02 * nirik nods
17:50:10 <mboddu> adamw: Thats the concern I raised to bcotton couple of hours ago
17:50:27 <bcotton> but that's where we stand at the moment, so we have to decide one way or another based on that
17:51:28 <mboddu> RelEng wants to get the request Tue before the go/no-go meeting, but that one is always considered as a soft rule
17:51:42 <pwhalen> We had a Tuesday rule, we never held to it, but we had a brief moment when we agreed. No RC Tuesday and we slip.
17:51:58 <adamw> yeah.
17:53:06 <mboddu> FWIW, I didn't consider that rule as a hard requirement because I always trusted adamw judgment with testing
17:53:50 <mboddu> But if he is unsure, maybe I should vote no-go by referencing to that rule
17:54:53 <Eighth_Doctor> if we gave a day with the existing stuff, would we be in a better position to say GO for Tuesday?
17:55:14 <lukc> why not adjourn to a better moment to decide?
17:55:42 <bcotton> we can only compress the time between decision and release so much
17:55:48 <nirik> no.
17:55:50 <adamw> because we're already adjourned from yesterday when this is supposed to happen
17:55:56 <adamw> and other things have to happen before the actual release
17:56:03 <nirik> if we are not go now, we should slip a week. ;)
17:56:04 <mboddu> Eighth_Doctor: We need to push it to mirrors, which should be done by yesterday, we already pushed it, so... not a good idea to push it further
17:56:25 <nb> do we think we could get enough testing done in a hour or so? then we could still make the decision today?
17:56:27 <nirik> also any delay now results in weekend work for qa/releng/websites.
17:56:36 <nb> nirik true
17:57:19 <Eighth_Doctor> would an hour or two make a positive difference?
17:57:49 <mboddu> I dont know AD tests are run by Steve Gallagher and he is on PTO
17:57:50 <cmurf> pwhalen++
17:57:51 <zodbot> cmurf: Karma for pwhalen changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:57:57 <nb> Eighth_Doctor that's what i was wondering
17:57:58 <mboddu> Does anyone else can run AD tests?
17:58:01 <nirik> FWIW: cinnamon finished when resubmitted: https://koji.fedoraproject.org/koji/taskinfo?taskID=66554032
17:58:14 <nb> I am not sure what AD tests require - maybe?
17:58:19 <tflink> mboddu: he also said he wasn't sure if he'd have the bandwidth to do those tests this cycle
17:58:23 <Eighth_Doctor> they require an Active Directory server setup
17:58:29 <mboddu> nirik: Oh, since its going to alt, I thought I could just grab the results from koji tasks, but sure :)
17:58:34 * tflink was looking at them but haven't gotten very far
17:58:42 <nb> Eighth_Doctor well, I have our prod AD system at work
17:58:42 <tflink> them -> AD tests
17:59:04 <nirik> mboddu: the failed task had a incomplete iso... would not have worked. :) Also, we should get someone to test that this one does before we do anything with it. :)
17:59:28 <mboddu> tflink: Ohhh, thanks for the update
17:59:29 <bcotton> adamw: would a brief delay (say 45-60 minutes) be useful, or should we move to the decision part of the process now?
17:59:36 <mboddu> nirik: Okay, thanks
17:59:50 <adamw> an hour would let us clarify things a bit more.
17:59:50 <bcotton> if it's useful, we can wait. if it won't change anything, i don't want to waste everyone's time
17:59:58 <adamw> it doesn't look like we're going to get AD tests unless anyone else can do it
18:00:18 <tflink> I'm starting on them but I don't know if I'll be able to get them done in an hour
18:00:19 <adamw> i just tried to remote into sgallagh's setup but it's not allowing me in so i guess he didn't leave it up for me to use or anything
18:00:25 <bcotton> okay
18:00:35 <nirik> reconvene in an hour?
18:00:50 <bcotton> so it's currently 1800 UTC. Let's come back at 1900 UTC and see where we stand
18:01:09 <lruzicka[m]> on the other hand, I think we have tested quite a lot with the latest compose. I could not do the Cloud (except for local), AD and hardware, like FcoE
18:01:10 <bcotton> i'll leave the meeting running for keeping the historical record easier to follow
18:01:10 <adamw> tflink: just doing join_sssd and domain_client_authenticate would be fine really, if that works and hte other two work on freeipa we usually consider that okay
18:01:28 <sgallagh> adamw: It should be working, but I cannot test. I’m currently on a phone in the middle of the woods.
18:01:37 <adamw> i might be able to do hardware raid, i have to open my test box and look at what's in it
18:01:43 <Eighth_Doctor> that does kind of hinder doing such tests indeed :P
18:01:43 <bcotton> sgallagh: get off the phone and go be in the woods :p
18:01:46 <tflink> but I'm just getting started setting up AD using a trial windows server
18:01:50 * mboddu grabs lunch, bbiab
18:01:56 <bcotton> #topic Break until 1900 UTC
18:02:07 <nb> tflink I will try to see if i can do it with my AD
18:02:11 <coremodule> tflink++
18:02:11 <zodbot> coremodule: Karma for tflink changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:02:15 <nb> tflink where do i find the testcases?
18:02:19 <adamw> sgallagh: the virt-viewer command you gave me just says "Unable to connect to libvirt with URI: (the uri)"
18:02:20 <sgallagh> Oh, crap. There was a power outage in the Westford office last week. See if you can find someone to power on the box under my desk
18:02:21 <adamw> anyhoo
18:02:34 <adamw> eh, tflink's on it
18:02:37 <adamw> thansk though
18:02:39 <sgallagh> Okay, thanks.
18:02:41 * cmurf will ask a Windows person how difficult it is to have a Windows AD server in a VM image we can fallback on, just spin it up in a nano AWS instance or whatever
18:02:52 <sgallagh> I’ve gotta go. Kids are running away.
18:02:57 <Eighth_Doctor> we could ask BitIntegrity to make this a thing for us :)
18:03:03 <adamw> nb: https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Server
18:03:07 <tflink> nb: https://fedoraproject.org/wiki/Test_Results:Fedora_34_RC_1.2_Summary#Domain_joining_tests:_Active_Directory
18:03:08 <cmurf> or possibly even just qemu-kvm and stick it on DMZ
18:03:13 <adamw> https://fedoraproject.org/wiki/QA:Testcase_realmd_join_sssd
18:03:41 <adamw> cmurf: we have licensing issues with that.
18:03:47 <cmurf> which part?
18:03:59 <adamw> having an AD server in a VM image...
18:04:06 <Eighth_Doctor> even from an eval copy of Windows?
18:04:10 <cmurf> ?
18:04:12 <cmurf> yeah
18:04:14 <cmurf> they're free
18:04:15 <adamw> there's an RH project kicking around somewhere for this sort of thing but i never get the roundtuits to look into it
18:04:27 <cmurf> Windows Enterprise 10, 90 days free, no license
18:04:37 <adamw> for a start, depends whether the kind of usage you want to do is allowed under the eval terms
18:04:43 <adamw> which i dunno, ianal
18:05:00 <adamw> anyway
18:05:02 <adamw> out of scope
18:05:19 <adamw> anyone have an FCOE setup lying around under their desk?
18:05:38 <lruzicka[m]> I will reconnect from a different room, will be right back.
18:05:55 * Eighth_Doctor snorts
18:06:08 <cmurf> i think we need to deprecate these criterion unless some interested party has the roundtuits to actually setup the test environments
18:06:23 <cmurf> including FCOE setup under a desk
18:06:31 <coremodule> ^^what cmurf said. also, the xen criteria
18:06:50 <cmurf> like, we've had this issue at the last minute for the past 5 years
18:07:07 <coremodule> or do what we did with xen and make it an optional testcase
18:07:18 <cmurf> FCOE, SAS, AD, xen, optical boot
18:08:00 <adamw> optical boot is optional
18:08:06 <adamw> oh. i see
18:08:14 <adamw> lnie usually does fcoe
18:08:18 <bcotton> more like optional boot, amirite?
18:08:29 <cmurf> we made optical boot optional, which hilariously the top complainer didn't test like he said he would, and yet i incidentally tested it earlier in this release cycle
18:09:17 <cmurf> but yeah i think we said if things are only being hero tested at the last minute for a couple of releases then they probably aren't that important and should be dropped
18:10:15 <coremodule> so... cmurf are you going to start the proposal on the list or am I?
18:10:41 <coremodule> :) because I do agree
18:11:23 <nb> I agree too
18:11:30 <nb> if there are not enough people willing to test, they should be optional
18:12:18 <cmurf> coremodule: go do it :)
18:12:41 <cmurf> we could say they are blockers if a bug is discovered at least a week prior to go/no-go
18:13:15 <adamw> we have a hardware raid pass from 0418.n.0
18:13:25 <adamw> that's probably recent enough...let me see what changed since
18:13:43 <cmurf> does hardware raid ever fail?
18:13:46 <cmurf> it's just a block device
18:13:57 <lruzicka> .hello2
18:13:58 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
18:14:06 <lruzicka> back again
18:15:05 <adamw> cmurf: if the kernel driver breaks, sure.
18:15:20 <adamw> that's what we're testing, not whether anaconda can write to a block device.
18:15:34 <cmurf> oh for the hardware raid card?
18:16:11 <cmurf> there's dozens of those
18:18:32 <adamw> look i never said any of this made sense
18:18:42 <adamw> if you're looking for a software project that makes sense please apply elsewhere
18:19:22 * bcotton updates the About Us page...
18:19:29 <cmurf> i'm not sure what we could do about it now anyway with 5.11.12 being the kernel we're using, if it's escaped notice upstream i'm not really sure it matters anymore
18:22:16 <adamw> we also don't have checks in any boxes for ARM disk image deployment on hardware
18:22:41 <adamw> i'm assuming someone has actually tested on hw and that's an oversight?
18:22:47 <coremodule> yee
18:22:54 <coremodule> ill add in what ive done
18:23:19 <adamw> thanks
18:23:37 <adamw> i'm grabbing the workstation image to try again with this jetson i couldn't make do anything before...
18:23:59 <nb> mattdm someone should probably contact VMware and ask them to put "Fedora Linux" instead of "Red Hat Fedora"
18:24:37 <coremodule> adamw, my jetson is really picky about which monitor it likes to work with. I have two dell 20" monitors that are a year or two apart, the jetson works great with one and never produces and image to the screen on the other. ymmv
18:25:11 <coremodule> over hdmi, not displayport
18:25:50 <adamw> huh, that might've been a factor
18:26:13 <nb> mattdm I noticed that when I went to set up a Fedora VM and VMware asked me which OS it was
18:32:01 <cmurf> coremodule: i will bet a bag of donuts that one of those displays is spitting out bogus EDID information, and it makes the video driver mad
18:33:18 <cmurf> or possibly even mutter, i'm not sure how much mutter relies on EDID info
18:34:28 <Southern_Gentlem> yes because the eval license is only good for 180 days at the most (thinking 120)
18:36:28 <tflink> yeah, it'll be worth looking into either getting ahold of a windows server license or figuring out a way to automate the setup on top of a fresh eval install
18:36:49 <tflink> or the vm route, none of this is new but something about a lack of 'roundtoits
18:37:40 <Eighth_Doctor> in theory, eval + sysprep + ansible could do that autosetup thingy for tests
18:37:51 <Eighth_Doctor> but I dunno how AD setups work
18:37:58 <adamw> as i said, there is an actual project for this by some rh'ers
18:38:00 <adamw> or there was
18:38:04 <adamw> i just haven't had time to look into it lately
18:38:52 <tflink> adamw: if you have more information about it, you can forward me the information and I'll look into it for future releases
18:39:10 <pwhalen> adamw: I havent been able to yet.
18:39:14 <pwhalen> (test on hw)
18:41:36 <pwhalen> adamw: did you follow the guide on pbrobinsons blog to flash your nano?
18:42:08 <adamw> i don't think i saw that
18:43:58 <pwhalen> adamw: https://nullr0ute.com/2020/11/installing-fedora-on-the-nvidia-jetson-nano/
18:44:12 <adamw> thanks
18:45:50 <Eighth_Doctor> I really wish VMware would give me the option to do Fedora with UEFI like it does for RHEL
18:46:06 <Eighth_Doctor> it's annoying having to edit random files to get a Fedora VM to boot with UEFI
18:46:25 <pjones> Use kvm+libvirt+virsh instead?
18:47:41 <nb> I keep getting "KDC has no support for encryption type"
18:47:56 <coremodule> workstation+server look good on aarch64 hw
18:48:01 <nb> when I try realmd join --user=username DOMAIN.EDU
18:48:49 <adamw> nb: oh dear. er, could be the systemwide policy thing?
18:49:11 <adamw> god what is that thing called my brain is mush
18:49:39 <adamw> oh yeah that's it
18:49:40 <adamw> uh
18:49:47 <adamw> if you do update-crypto-policies --set LEGACY
18:49:49 <adamw> does that help?
18:50:12 <Eighth_Doctor> <pjones "Use kvm+libvirt+virsh instead?"> that's hard on a Mac :)
18:50:17 <pwhalen> thanks coremodule
18:50:42 <pjones> Eighth_Doctor: boy you are just all up in "closed source example story", aren't you? ;)
18:50:50 <Eighth_Doctor> 😆
18:51:13 <Eighth_Doctor> lots of folks use Fedora in VMware Fusion, so I make it a point to test it continuously
18:51:24 <Eighth_Doctor> every time it breaks, I get emails about it on the kde@ list and other places
18:51:27 <coremodule> testing minimal on aarch64 hw now
18:53:10 <jlinton> I'm going to mark the test matrix too for USB installed aarch64, I've been doing it in graphical mode, and so far so good (honeycomb+rpi)
18:53:18 <Eighth_Doctor> 👍️
18:54:02 <nb> adamw apparently that only happens when I use our unprivileged "setup" account.  When I use my Domain Admin account it works
18:54:17 <nb> so that test appears to be a pass.  Appears there is something wonky with our setup accoutn
18:54:26 <nb> our = work
18:55:30 <bcotton> 5 minutes!
18:56:01 <adamw> nb: cool, well, as long as you can make it work :D
18:56:15 <lukc> adamw: crypto-policies --set DEFAULT:AD-SUPPORT
18:56:42 <lukc> update- ...
18:57:11 <adamw> ah, thanks, i just suggested legacy as a big gun for testing purposes
18:57:16 <lukc> nb: login with AD-account worked afterwards?
18:57:28 <nb> lukc do i have to tell it to allow a particular AD user to login?
18:57:44 <nb> when I try username by itself, it fails, but when I try username@domain.edu it says System Error
18:58:54 <lukc> realm permit user@domain
18:59:31 * mattdm shows up, fresh from getting anti-covid jab #1
18:59:35 <adamw> that windows deployment thing i'm vaguely remembering, btw, is https://github.com/rhpit/paws
18:59:44 <nb> oh ok
18:59:50 <bcotton> welcome, mattdm and antibodies
19:00:10 <mattdm> nb can you email me a screenshot of the vmware "Red Hat Fedora" thing (to mattdm @ redhat com) please?
19:00:19 <adamw> seems like it wasn't touched since 2018, though
19:00:26 <Eighth_Doctor> happyassassin[m]: shame it looks kinda of dead :(
19:00:27 <nb> mattdm sure, will do in a bit
19:00:34 <mattdm> nb thanks!
19:00:45 <Eighth_Doctor> hmm, I should check to see if VMware Workstation still does that too
19:00:46 * bcotton gavels the room back to order
19:00:50 <Eighth_Doctor> it did the last time I checked a while back
19:00:51 <nb> lukc adamw works once I did realm permit
19:01:02 <lukc> nb++
19:01:02 <zodbot> lukc: Karma for nb changed to 18 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:01:04 <bcotton> #topic Current status - test matrices
19:01:10 <tflink> nb++
19:01:10 <zodbot> tflink: Karma for nb changed to 19 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:01:14 <bcotton> #link https://fedoraproject.org/wiki/Category:Fedora_34_Test_Results
19:01:15 <nb> AD Tests both pass - I will update the wiki
19:01:41 <tflink> and I'm still messing with windows - much faster when you already have an AD domain set up :)
19:01:43 <coremodule> just waiting on the aarch64 minimal image card to write so i can mark all required hw aarch64 tests as good
19:01:49 <Eighth_Doctor> 🎉
19:02:20 <bcotton> it seems like many tests have passed in the last hour
19:03:49 <mattdm> I like 70% of that sentence
19:03:59 <adamw> yeah. let me survey the matrixes again
19:04:20 <nirik> it's all around us
19:05:01 <bcotton> sailing the matrices
19:05:09 <coremodule> all required aarch64 hw disk image deployment tests pass
19:05:36 <coremodule> pwhalen, jlinton wonder if either of you have tried the armhfp disk image deployment tests on real hw?
19:05:59 <pwhalen> not for rc1.2
19:06:06 <jlinton> I don't actually have any 32-bit hardware, only 64-bit, and all my HW is UEFI...
19:06:10 <jlinton> Lol
19:06:37 <Eighth_Doctor> my 32-bit hardware is kinda dead now :/
19:06:53 <nb> I think I have an old netbook that runs some 32-bit atom thing
19:07:04 <nb> out in my storage building, but i think it's intel 32
19:07:19 <coremodule> nb, if its the atom, yeah it's intel x86
19:07:52 <adamw> okay, so, yeah, coverage is now rather better
19:07:53 <nirik> I did a 32bit arm f34 install a few days ago, but that was virt-install, not disk image
19:07:59 <adamw> we are only missing dribs and drabs of the kind we've been okay with before
19:08:07 <mboddu> adamw: How are you feeling with the test coverage?
19:08:22 <adamw> still missing fcoe, some aarch64 server tests are queued on openqa (but they have passed on every other recent build so should also pass when they run)
19:08:37 <mattdm> yall we can get you hardware if you need it just let me know
19:08:44 <adamw> we are still relying quite heavily on rc1 results which isn't optimal, but, there's no reason really the change to rc2 should've broken them
19:08:56 <mattdm> quote for the release announcement "we are only missing dribs and drabs of the kind we've been okay with before"
19:09:06 <bcotton> +1
19:09:12 <Eighth_Doctor> 🤪
19:09:16 <adamw> "this OS got a whole five hours of testing, install with confidence"
19:09:25 <mboddu> Haha :)
19:09:39 <Eighth_Doctor> well, we can spruce that up with "150 man hours in only five hours!"
19:09:39 <mboddu> adamw approved ;P
19:09:56 <adamw> Fedora 34 "What Could Possibly Go Wro-"
19:10:32 <Eighth_Doctor> ⏲️
19:10:37 <adamw> so, i kinda have to say that test coverage is basically sufficient
19:10:38 <pbrobinson> Eighth_Doctor: People Hours....
19:10:44 <adamw> but i'm still not happy with the extreme time crunch here
19:11:00 <adamw> i would be much happier if kamil had had a day to try and brea kit
19:11:12 <bcotton> "extreme time crunch" is something that should only appear on our Taco Bell order
19:11:33 <Eighth_Doctor> but Kamil always breaks it :P
19:11:50 <lukc> but not always in a day ;-)
19:11:57 <bcotton> i can #action bcotton to start a conversation about how to fix the tendency to put ourselves in this position
19:12:07 <coremodule> lol ill take my extreme time crunch with a mountain dew baja blast please
19:12:16 <Eighth_Doctor> oh god, now I feel sick
19:12:18 <bcotton> i don't have answers, but we can at least have the conversation :-)
19:12:23 <Eighth_Doctor> Mountain Dew....
19:12:43 <mattdm> Something to do with 'trying to put out a whole os release every six months'
19:12:50 <nirik> perhaps we should make the 'no rc by wed' a auto slip
19:13:01 <mboddu> ^ agreed
19:13:02 <pwhalen> nirik: I would really like to see that.
19:13:03 <bcotton> so to wash down our Extreme Time Crunch, Mountain Dew we want to move on to the decision now?
19:13:39 <nirik> you missed 'Bel Grande!' at the end, but not sure they do that anymore.
19:13:39 <bcotton> not all late RCs are created equal, but that might be the best way. we don't need to solve it this minute, though. we have six whole months to not solve it
19:13:46 <tflink> nirik: wasn't that already an auto slip?
19:13:47 <coremodule> We're gonna need Fire sauce for the decision.
19:14:09 <tflink> or was it a "we should slip if this happens" instead of an automatic thing
19:14:10 <bcotton> #topic Go/No-Go decision
19:14:11 <mboddu> tflink: We have been thinking/saying it, but never done it
19:14:12 <nirik> tflink: not really, kinda a wishy washy we should do this... I don't think we formally ever decided it.
19:14:13 <bcotton> .fire sauce
19:14:13 <zodbot> adamw fires sauce
19:14:20 <coremodule> lol
19:14:23 <nb> lol
19:14:27 <Eighth_Doctor> .fire dew
19:14:27 <zodbot> adamw fires dew
19:14:31 <nb> .fire the sauce
19:14:31 <zodbot> adamw fires the sauce
19:14:34 <bcotton> FESCo?
19:14:53 <Eighth_Doctor> As a FESCo monkey, I say +1 to GO
19:15:03 <nirik> I'm also a bit unhappy with the amount of testing, but +1 to go
19:15:03 <mattdm> :)
19:15:09 <bcotton> #info FESCo is GO
19:15:11 <bcotton> releng?
19:15:17 <mboddu> I will vote after QA
19:15:39 <bcotton> aw, that's no fun
19:15:43 <mboddu> Or if QA says its GO, I am okay with GO
19:15:48 <bcotton> if QA is no-go, it doesn't matter what you say anyway :p
19:15:52 <nb> lol
19:15:57 <mboddu> Right :D
19:16:02 <bcotton> QA?
19:16:24 <lruzicka> I will fall with my leader. Lets adamw have his say.
19:16:24 <mattdm> *crickets*
19:16:29 * bcotton now recalls the "North Carolina yields to South Carolina" bit from the movie "1776"
19:16:31 <mboddu> Now the million dollar question... tick tick tick....
19:16:38 <Eighth_Doctor> ⏲️
19:16:41 <adamw> sorry
19:16:43 <nb> drum roll
19:16:45 <bcotton> lruzicka: now's your chance to stage the coup
19:16:47 <adamw> was reading very important pokemon things
19:16:52 <Eighth_Doctor> 🥁
19:16:56 <bcotton> #info QA is catching them all
19:17:08 <coremodule> we wanted to be the very best
19:17:09 <nb> 🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁v
19:17:11 <adamw> i guess according to policy we have to vote go
19:17:14 <mattdm> note: if release slips, blame pokemon
19:17:28 <Eighth_Doctor> 🎶 Born to be a leader! Born to be very best! 🎶
19:18:00 <mattdm> adamw: so if it weren't the policy you would vote no?
19:18:02 <nirik> bcotton: new york abstains.... courteously
19:18:06 <mattdm> (serious question)
19:18:08 <Eighth_Doctor> well, "the very best" :P
19:18:10 <adamw> mattdm: i would vote to go back to bed
19:18:13 <mboddu> adamw: no pressure, but in a way you are now voting for releng as well :D
19:18:16 <mattdm> fair :)
19:18:20 <bcotton> nirik++
19:18:26 <relrod> adamw++
19:18:27 <zodbot> relrod: Karma for adamwill changed to 17 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:18:38 <nb> adamw++
19:18:38 <zodbot> nb: Karma for adamwill changed to 18 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:18:49 <bcotton> okay then
19:18:51 <mattdm> FPL has a perpetual "unless it's gonna make me wear a brown bag over my head for a month, ship it!" vote
19:18:51 <lruzicka> from my own perspective, I am ok with what I have been using for some time already.
19:19:01 <mboddu> " i would vote to go back to bed" I will definitely vote GO on that :)
19:19:23 <mattdm> .fire adamw into bed
19:19:23 <zodbot> adamw fires adamw into bed
19:19:26 <bcotton> #info QA is go
19:19:34 <bcotton> #info Releng is GO
19:19:43 <bcotton> #agreed Fedora Linux 34 Final is GO
19:19:50 <bcotton> #info Fedora Linux 34 Final will release on 2021-04-27
19:19:50 <mattdm> Wheeeeeee!
19:19:52 <Eighth_Doctor> 🥳
19:19:57 <bcotton> #action bcotton to announce decision
19:20:03 <Southern_Gentlem> 1.2 correct
19:20:08 <sumantro> yes
19:20:08 <Eighth_Doctor> 🎊
19:20:10 <nirik> may god(s) have mercy on our souls.
19:20:13 <bcotton> #action bcotton to start a discussion on how to avoid the Extreme Time Crunch Burrito for F35+
19:20:23 <mboddu> Well, fedora release party will happen after the release, so, there's that
19:20:27 <Eighth_Doctor> that would be nice
19:20:27 <bcotton> #topic Open floor
19:20:34 <Eighth_Doctor> I'm exhausted now :)
19:20:34 <bcotton> Anything else we need to discuss before closing?
19:20:38 <coremodule> OH WAIT I FOUND A BUG
19:20:47 <lukc> lol
19:20:47 <bcotton> i'll note that fixing the process is explicitly out of scope for this open floor
19:20:47 <coremodule> ...just kidding!
19:20:47 <mattdm> .fire coremodule
19:20:47 <zodbot> adamw fires coremodule
19:20:49 <mboddu> coremodule: Its not a blocker, dont worry
19:20:52 <bcotton> too many of us need to sleep first
19:20:53 <nb> well, I hope you are joking
19:20:54 <Eighth_Doctor> 🪦
19:20:57 <sumantro> :D
19:20:59 <nb> coremodule no changing our mind after GO decision :)
19:21:00 <lruzicka> coremodule, last minute blocker
19:21:48 <mboddu> bcotton: So, no-go if we dont have a compose by Wed morning?
19:21:48 <Southern_Gentlem> i thought that was someone elses job
19:21:53 <mboddu> Should we decide on that?
19:22:07 <Eighth_Doctor> we should probably have a separate policy discussion about this
19:22:12 <adamw> like we decided on it before?
19:22:16 <Eighth_Doctor> because we had down the wire things for two Fedora releases before
19:22:21 <Eighth_Doctor> *now, not before
19:22:35 <Southern_Gentlem> we always will
19:22:42 * bcotton points mboddu to the "i'll note that fixing the process is explicitly out of scope for this open floor" sign
19:23:01 <lruzicka> I support the idea to have a policy meeting for this.
19:23:06 <mboddu> bcotton: Oh, I missed it, sorry
19:23:28 <nb> IMHO even if we make an auto-slip policy, we will still be tempted to make an exception if the situation arises
19:23:32 <Eighth_Doctor> once is eck, twice is ugh, and thrice is a pattern
19:23:35 <bcotton> yeah, this should be a long, community-wide discussion
19:23:47 <Eighth_Doctor> let's not get to "thrice is a pattern"
19:23:57 <tflink> aren't we way past thrice at this point?
19:24:02 <Southern_Gentlem> Eighth_Doctor, its been a pattern for a much longer time than that
19:24:09 <Eighth_Doctor> I don't think we had this problem in F32
19:24:11 <bcotton> what's the worth for the 34th time something happens?
19:24:13 <mboddu> tflink: At least not continuously
19:24:16 <bcotton> s/worth/word/
19:24:29 <Eighth_Doctor> the controversy that cycle was the artwork
19:24:52 <Eighth_Doctor> F33 was secure boot, and F34 was... well, sddm and secure boot
19:25:01 <Southern_Gentlem> well we had alot of outside things beyound our control shim
19:25:14 <bcotton> okay, i think we've done all we can do here today
19:25:23 <Southern_Gentlem> it go so lets go
19:25:26 <bcotton> i'll send the announcement and we can all get ready for our happy fun release day
19:25:42 <Eighth_Doctor> 🎊 🎉
19:25:43 <sumantro> yaay
19:25:46 <bcotton> thanks everyone for the work as always, and the extra long meeting this time
19:25:47 <mattdm> bcotton++
19:25:49 <mattdm> adamw++
19:25:50 <zodbot> mattdm: Karma for adamwill changed to 19 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:25:52 <mattdm> Eighth_Doctor++
19:25:54 <mattdm> Southern_Gentlem++
19:25:56 <mattdm> mboddu++
19:25:59 <mattdm> sumantro++
19:25:59 <zodbot> mattdm: Karma for sumantro changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:00 <Southern_Gentlem> adamw++
19:26:01 <mattdm> tflink++
19:26:02 <zodbot> mattdm: Karma for tflink changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:04 <nb> mattdm++
19:26:05 <nb> bcotton++
19:26:08 <mattdm> lruzicka++
19:26:08 <zodbot> mattdm: Karma for lruzicka changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:09 <Eighth_Doctor> mattdm: you'll need to use my actual fas name :P
19:26:09 <nb> Eighth_Doctor++
19:26:12 <nb> Southern_Gentlem++
19:26:12 <zodbot> nb: Karma for jbwillia changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:15 <mattdm> lukc++
19:26:15 <nb> ngompa++
19:26:18 <zodbot> mattdm: Karma for lukc changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:20 <nb> tflink++ sumantro++
19:26:21 <zodbot> nb: Karma for ngompa changed to 12 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:24 <zodbot> nb: Karma for tflink changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:27 <mattdm> ngompa++
19:26:27 <zodbot> nb: Karma for sumantro changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:30 <zodbot> mattdm: Karma for ngompa changed to 13 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:26:32 <nb> COOKIE PARTY!
19:26:32 <bcotton> #endmeeting