17:00:34 <bcotton_> #startmeeting F34 Beta Go/No-Go meeting
17:00:34 <zodbot> Meeting started Thu Mar 11 17:00:34 2021 UTC.
17:00:34 <zodbot> This meeting is logged and archived in a public location.
17:00:34 <zodbot> The chair is bcotton_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:34 <zodbot> The meeting name has been set to 'f34_beta_go/no-go_meeting'
17:00:35 <bcotton_> #meetingname F34-Beta-Go_No_Go-meeting
17:00:35 <zodbot> The meeting name has been set to 'f34-beta-go_no_go-meeting'
17:00:42 <bcotton_> #topic Roll Call
17:00:48 <frantisekz> .hello2
17:00:50 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:00:55 <nirik> morning
17:00:59 <mhroncok> .hello churchyard
17:01:00 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:01:09 <mhroncok> nirik: morning
17:01:34 <Southern_Gentlem> .hello2 jbwillia
17:01:35 <zodbot> Southern_Gentlem: Sorry, but you don't exist
17:01:40 <Southern_Gentlem> .hello jbwillia
17:01:41 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
17:02:14 <copperi[m]> .hello2
17:02:17 <zodbot> copperi[m]: Sorry, but you don't exist
17:02:23 <pwhalen> .hello2
17:02:24 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
17:03:18 <copperi> .hello2
17:03:19 <zodbot> copperi: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
17:04:12 <bcotton_> well i suppose it's time to do this thing
17:04:19 <bcotton_> #topic Purpose of this meeting
17:04:20 <bcotton_> #info Purpose of this meeting is to check whether or not F34 Beta is ready for shipment, according to the release criteria.
17:04:22 <bcotton_> #info This is determined in a few ways:
17:04:28 <bcotton_> #info 1. No remaining blocker bugs
17:04:29 <bcotton_> #info 2. Release candidate compose is available
17:04:31 <bcotton_> #info 3. Test matrices for Beta are fully completed
17:04:37 <bcotton_> #topic Current status - blockers
17:04:38 <bcotton_> #link https://qa.fedoraproject.org/blockerbugs/milestone/34/beta/buglist
17:04:49 <bcotton_> bad news! the number is not 0. so let's take a look at them...
17:05:03 <bcotton_> #info 2 Proposed Blockers
17:05:04 <bcotton_> #info 5 Accepted Blockers
17:05:10 <bcotton_> #topic (1937308) First login attempt fails on laptop with fingerprint reader
17:05:11 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1937308
17:05:13 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/296
17:05:14 <bcotton_> #info Proposed Blocker, gdm, MODIFIED
17:05:39 * nirik voted in ticket already
17:05:40 <bcotton_> #info In the ticket, bcotton & kevin are +1, sgallagh and nb are -1
17:05:47 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/296
17:05:59 * mhroncok just voted there as well
17:06:02 <mhroncok> +1 it was
17:06:17 <frantisekz> +1
17:06:19 <Southern_Gentlem> +BetaFE -1 Blocker
17:06:34 <nirik> as a side note I was wondering if we should make the beta critera to be able to login with any one of the methods, and final require them all (I think we do this for some other things)
17:06:36 <bcotton_> so my take is that this is a blocker, but worth waiving under the late blocker exception becaues it's a Beta
17:06:41 <Southern_Gentlem> +Fblocker
17:07:19 <bcotton_> it's annoying, but not functionally harmful
17:07:48 * nirik wonders where adamw is. He was around eariler.
17:08:40 <adamw> i'm here
17:08:40 <adamw> oh, we started?
17:08:40 <adamw> i'm sure this meeting used to be like two hours later.
17:08:44 <bcotton_> so by my count, we're at +4, 0, -3
17:09:03 <bcotton_> adamw: it's usually an hour later but due to calendar quirks we're running it outside of DST for once :-)
17:09:15 <adamw> nirik: note I don't think this is about the method, actually.
17:09:30 <adamw> it's not "it breaks if you try to log in with a fingerprint"
17:09:43 <nirik> "Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. "
17:09:57 <adamw> the presence of the fingerprint reader is key, but you don't actually have to be trying to use it.
17:10:31 <nirik> well, "the mechanisms offered" sounds to me like it should work with all the things offered, but I guess it's wavy
17:10:34 <adamw> i'm definitely +1 FE on this, really meh about blocker
17:11:00 <adamw> what i meant by 'mechanisms' there was really things like 'menu options'
17:11:09 <adamw> i think when i wrote it, fingerprint readers weren't really a thing :P
17:11:19 <Southern_Gentlem> myself its a blocker if we have something else otherwise it shouldnt stop the beta release
17:11:28 <nirik> BTW, for the record, cloing bugs is bad. don't clone bugs. :)
17:11:29 <bcotton_> is anyone who is -1 on this willing to be +1 with the knowledge can we can choose to waive it
17:11:38 <adamw> it's basically trying to say "if the desktop has a "reboot" button it has to work, but we don't actually require it to have one"
17:11:42 <pwhalen> +1 blocker, also +1 to waiving it under the late blocker exception
17:11:43 <mhroncok> Southern_Gentlem: that's a blocker and we can waive it
17:11:55 <adamw> Southern_Gentlem: if you don't think it should block the release, then your vote is -1 blocker :)
17:12:03 <pwhalen> +1 FE for sure
17:12:08 <Southern_Gentlem> adamw, idid
17:13:06 <bcotton_> okay, i think we're at +5, 0, -3 now. i'd like a little more consensus if possible
17:13:17 <lruzicka[m]> .hello lruzicka
17:13:19 <zodbot> lruzicka[m]: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:14:19 <bcotton_> Southern_Gentlem: i'm confused by your statements. you say it's a blocker if we have something else, but you also say it's not a blocker. which to me sounds like +1 and you'd be +1 to waive it
17:14:39 <lruzicka[m]> which bug are we talking about, please?
17:14:55 <bcotton_> lruzicka[m]:  https://bugzilla.redhat.com/show_bug.cgi?id=1937308  First login attempt fails on laptop with fingerprint reader
17:14:57 <mhroncok> https://bugzilla.redhat.com/show_bug.cgi?id=1937308
17:15:12 <lruzicka[m]> thanks
17:15:33 <Southern_Gentlem> bcotton i do not think its a -1 blocker but i can see why others go the other way
17:16:11 <Southern_Gentlem> for Final yes its a blocker
17:17:08 <bcotton_> lruzicka[m]: thoughts?
17:17:19 <adamw> i guess i'd probably have to say -1 blocker, strictly, as if this were the last blocker we'd probably fudge it for a beta and say 'eh we can just tell people about it'
17:17:24 <lruzicka[m]> How does it look like when I "want to log for the second time" when the first attempt has "frozen" ?
17:17:33 <lruzicka[m]> I do not have fingerprint readers
17:17:39 <adamw> the criterion isn't clearly violated because you can login, as long as you hit esc and try again...
17:18:00 <adamw> from the description it sounds like you get a spinner that spins eternally, and you have to hit esc to get back to the password entry box
17:18:07 <lruzicka[m]> in that case, I am -1 beta blocker, +1 final blocker, +1 common bugs
17:18:08 <nirik> I guess I could change my vote given the explanation of the critera more... but I think perhaps we should revisit it after beta. ;)
17:18:28 <frantisekz> yeah, -1 Beta Blocker, +1 BetaFE then
17:18:30 <Southern_Gentlem> also on first boot how does the fp reader have your creds
17:18:58 <lruzicka[m]> Southern_Gentlem: it does not and that is the problem, I believe
17:19:25 <bcotton_> proposed #agreed BZ 1937308 - RejectedBlocker(Beta) - There is insufficient consensus that this is a blocker (and those who want to say it is also want to waive it), so we will leave it for FinalBlocker consideration
17:19:35 <nirik> ack
17:19:40 <Southern_Gentlem> ack
17:19:44 <pwhalen> ack
17:19:45 <lruzicka[m]> ack
17:19:49 <adamw> i asked benzea to join
17:19:49 <frantisekz> ack
17:19:51 <copperi> ack
17:19:53 <adamw> but it looks like ya'll went on ahead
17:20:12 <adamw> i guess ack
17:20:33 <bcotton_> even if we're no-go today, it doesn't seem like there's an appetite for calling it a blocker for next week. and it already has an FE
17:20:49 <bcotton_> #agreed BZ 1937308 - RejectedBlocker(Beta) - There is insufficient consensus that this is a blocker (and those who want to say it is also want to waive it), so we will leave it for FinalBlocker consideration
17:21:01 <bcotton_> #topic (1924908) Gnome session fails to start with "Oops, something went wrong" on first boot
17:21:02 <Southern_Gentlem> lruzicka[m], i would be more of a blocker if it did
17:21:03 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1924908
17:21:04 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/240
17:21:06 <bcotton_> #info Proposed Blocker, mutter, POST
17:21:45 <bcotton_> no blocker votes on this one yet, so i guess we'll all look at it now
17:22:24 <copperi> I get that message on every boot
17:22:28 <nirik> how long is the 'on no' state?
17:22:34 <lruzicka[m]> Yeah this is something which looks terrible but in the end does not have any impact on the usage
17:22:39 <frantisekz> about 2 minutes nirik
17:22:48 <lruzicka[m]> nirik: from 30 secs to 2 minutes, I guess
17:22:53 <frantisekz> oh, until you go through the initial setup
17:23:05 <nirik> hum, thats longer than many people might wait.
17:23:10 <mhroncok> this indeed look bad but is harmless
17:23:14 <lruzicka[m]> yeah, then you go through the initial setup and problem solved
17:23:15 <bcotton_> yeah 2 minutes might as well be "forever"
17:23:20 <mhroncok> I think we can afford that in beta, but not final
17:23:24 <frantisekz> you see only wallpaper, for like 2 minutes, then gis starts up and there is oh no until you finish the process
17:23:35 <adamw> it's harmless as long as you don't assume it's broken and give up
17:23:42 <frantisekz> there is a fix for it already
17:23:46 <adamw> yeah, for me i just see wallpaper when it's hung
17:23:51 <lruzicka[m]> I have never had to wait 2 minutes, but I saw a bug report today which complained about 2 minutes. Mine took like 30 seconds
17:23:51 <adamw> but it sounds like it might not be the same for everyone?
17:23:52 <nirik> "fedora didn't even boot" power-switch. ;(
17:24:16 <copperi> I don't have delays, only message
17:24:31 <frantisekz> I think it would work just fine on gpus blacklisted for wayland
17:24:37 <bcotton_> i kinda feel like i need to be +1 just for the reputational impact, but i'm willing to be talked out of that
17:25:11 <frantisekz> adamw, bcotton, what are chances for spinning a new compose and repeating go/no-go tomorrow?
17:25:22 <bcotton_> depends on the other blockers
17:25:26 <lruzicka[m]> I am probably sort of fine with both, so I am not going to talk it out of you.
17:25:36 * nirik is still on the fence.
17:25:38 <frantisekz> (also, silverblue x86 is missing, that isn't ideal either)
17:25:52 <bcotton_> if we're good otherwise, i'd be fine with a new RC that only differs with the fix for this
17:26:07 <bcotton_> but we can't really make that call yet
17:26:23 <adamw> i did not check new proposed blockers overnight yet
17:26:24 <frantisekz> mhm, punt this one, look at the others and get back here?
17:26:31 <cmurf> i'm not even sure we have a criterion for this for final let alone beta, but i agree that it looks bad
17:26:39 <bcotton_> adamw: this is 2 of 2 proposed blockers
17:26:48 <adamw> when i went to bed last night this was the thing that made me not request a new candidate
17:26:59 <adamw> whether we accept it as blocker or not i kinda wanted to fix it in the next spin if there was gonna be one
17:27:54 <bcotton_> so it seems like we probably want to call this a blocker and then figure out options after we review the accepted blockers?
17:28:17 <nirik> I guess it technically doesn't break the critera... since you _do_ get a screen after a wait... but bah
17:28:31 <cmurf> exactly
17:28:33 <Southern_Gentlem> yeah lets come back to this one
17:28:44 <cmurf> it has a bad scent to it
17:28:57 <lruzicka[m]> But it really looks awful - however we are still just Beta.
17:29:05 <nirik> I don't see any other proposed blockers...
17:29:18 <adamw> note, we do already have an accepted blocker that isn't fixed in rc12
17:29:19 <adamw> rc1*
17:29:23 <adamw> are people not aware of that?
17:29:32 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1937550
17:29:37 <adamw> it was accepted via ticket vote
17:29:47 <adamw> if we wanted to ship RC1, as well as rejecting everything here, we'd have to waive that
17:29:50 <bcotton_> adamw: i guess i should have started with accepted blockers to save time :-)
17:29:53 <cmurf> haha
17:30:10 <cmurf> so fix mutter and repor-cli and ship it
17:30:14 <cmurf> rc2
17:30:15 <bcotton_> but for now...
17:30:19 <bcotton_> proposed #agreed BZ 1924908 - AcceptedBlocker(Beta) - This bug does not strictly violate any release criteria, but the first-use experience is bad enough that we don't want to ship it.
17:30:24 <adamw> btw, i win the trifecta on that one: I caused, discovered and fixed it. :P
17:30:32 <adamw> nack
17:30:34 <bcotton_> (with the knowledge that we can try again tomorrow possibly)
17:30:35 <adamw> i do not like that
17:30:39 <adamw> makes a mockery of the process
17:31:25 <cmurf> i think we can call it a freeze exception, and agree this one FE should go in along with the fix for report-cli blocker
17:31:28 <mhroncok> ack
17:31:31 <cmurf> FE's don't *have* to go in
17:31:39 <bcotton_> no, i make a mockery of the process. but i think it's within the spirit of the process to say "there are bad things we haven't considered but are worth being blockers"
17:32:07 <adamw> if people really want to take it as a blocker but don't believe it breaks a specific criterion, we either need to propose and accept in principle a change to the criteria, or agree that it violates one of the catchalls
17:32:12 <adamw> bcot: it is not
17:32:15 <mhroncok> fesco has that power, I don't think why bcotton shoudn't have it as well :D
17:32:18 <adamw> the whole point of the blocker process is that we don't do that
17:32:21 <lruzicka[m]> Well, do we need to have blockers to block? Ain't no blockers just one critarion?
17:32:26 <adamw> that's why we spent a lot of time and effort coming up with a concrete set of rules
17:32:41 <cmurf> i agree with adam
17:32:44 <bcotton_> mhroncok: the less power i have, the better ;-)
17:32:46 <nirik> yeah, so lets reject that as a blocker, but +1 FE, and do a rc2 for that and the report thing
17:32:57 <adamw> the established precedent is, if we think something should be a blocker but the criteria don't cover it, we come up with a proposal-in-principle to change the criteria
17:33:14 <nirik> but that means anaconda and gnome change, so a lot of testing to redo...
17:33:26 <cmurf> lorax
17:33:30 <cmurf> and i already tested it :D
17:33:33 <adamw> i would be fine if someone said "let's change the criterion to say whatever's supposed to happen on first boot should happen within a reasonable timeframe and without showing alarming error messages"
17:33:37 <adamw> i would probably +1 a proposal along those lines
17:33:45 <adamw> but i'm not in favour of taking this bug as a blocker without doing that
17:34:18 <cmurf> yeah i'm -1 beta blocker
17:34:27 <mhroncok> let's change the criterion to say whatever's supposed to happen on first boot should happen within a reasonable timeframe and without showing alarming error messages
17:34:53 <Southern_Gentlem> define reasonable timeframe
17:35:03 <Southern_Gentlem> 2minutes?
17:35:04 <nirik> mhroncok: sounds reasonable... :)
17:35:05 <cmurf> there's a devel@ thread for this :P
17:35:09 <lruzicka[m]> Southern_Gentlem: we can have a discussion any time, what that is
17:35:09 <adamw> i knew that was coming :P
17:35:21 <mhroncok> to be fair, it was a bait
17:35:24 <adamw> i'd say that's the kind of thing we could work out in detail on the mailing list though
17:35:42 <bcotton_> i'm not sure i like writing that criterion on the fly, because it seems like there's a lot of nuance we'd want to consider. i'd rather go with the "let's reject this" route and see where we are after reviewing the accepted blockers
17:35:45 <adamw> i'm +1 in principle to mhroncok's proposal, or else i'm also fine with this being -1 blocker +1 fe
17:35:57 <cmurf> exactly it's not ever been something we just wedge into the release criteria following 10 minutes of discussion at blocker review
17:36:00 <lruzicka[m]> it's your proposal, adam, anyway
17:36:19 <bcotton_> i do think there's room for a "this makes us look really bad" fuzzy criterion, but i respect adam's arguments against it
17:36:22 <adamw> yup, but that doesn't mean i'm +1 :D
17:36:35 <lruzicka[m]> Are we generally agreed that the message is too bad for a Beta release?
17:36:50 <Southern_Gentlem> +1 proposal  - 1 blocker +fe
17:37:02 <mhroncok> I think this should eb a final blocker and we need that criterion to happen before final
17:37:12 <mhroncok> if not, wa can always ask fesco
17:37:13 <nirik> I think it's a bad look, but we should adjust the critera to avoid it next time. ;)
17:37:13 <cmurf> -1 blocker, +1 FE, bring in this specific FE and the report-cli blocker fix, and make an rc2
17:37:16 <lruzicka[m]> When we are +1 proposal, then we need be +1 blocker :D
17:37:35 <bcotton_> proposed #agreed BZ 1924908 - RejectedBlocker(Beta) - This bug does not violate any release criteria, but we should develop a criterion to address it prior to F34 Final
17:37:35 <cmurf> and it's reasonable to have a final release criteria for excessive delays on first boot
17:37:43 <mhroncok> ack
17:37:44 <nirik> ack
17:37:45 <frantisekz> ack
17:37:46 <Southern_Gentlem> ack
17:37:48 <copperi> ack
17:37:50 <lruzicka[m]> wait
17:38:01 * bcotton_ waits
17:38:10 <lruzicka[m]> so does this mean, we are letting it through into Beta and make sure this will go away on Final?
17:38:22 <nirik> no
17:38:24 <mhroncok> that is my understanding
17:38:29 <mhroncok> but we also have a FE
17:38:37 <bcotton_> potentially. it does have an FE, so if we don't ship RC1, then it can be fixed for Beta
17:38:42 <adamw> what happens depends on other factors
17:38:45 <lruzicka[m]> so we hope to make another RC before we ship to go it away now?
17:38:48 <nirik> it means we aren't considering it a blocker, but it is a FE... which we can pull in. if we want
17:39:42 <lruzicka[m]> but if we dont, this stays in Beta right? Because I really do not know what to think, cause this only looks bad but is not bad.
17:39:51 <lruzicka[m]> I guess I nod to whatever the majority says.
17:40:11 <bcotton_> any nacks to the proposal above?
17:40:18 * bcotton_ looks at adamw in particular
17:40:25 <Southern_Gentlem> looks bad, but no really reason to kill it
17:41:06 <lruzicka[m]> so the global understanding is that if this "stays in" we are still fine about it for Beta?
17:41:25 <bcotton_> i can live with it. i'm not sure i'd call it "fine" :-)
17:41:30 <adamw> ack
17:41:34 <Southern_Gentlem> lruzicka[m], come up with criteria
17:41:36 <lruzicka[m]> ok, then I am ack
17:41:43 <bcotton_> #agreed BZ 1924908 - RejectedBlocker(Beta) - This bug does not violate any release criteria, but we should develop a criterion to address it prior to F34 Final
17:42:01 <bcotton_> adamw: want the #action to propose the criterion in question since you volunteered a first draft?
17:42:12 <lruzicka[m]> Southern_Gentlem: the adam/mrohncok criterion seems fine with me, just expected to place in the Beta frame
17:42:14 <lruzicka[m]> :D
17:42:18 * bcotton_ is not wearing the #action bcotton t-shirt today
17:42:26 <mhroncok> #action bcotton to develop a criterion to address it prior to F34 Final or to delegate it properly
17:42:28 <mhroncok> I am
17:42:38 <cmurf> lol
17:42:38 <mhroncok> :D
17:42:45 <nirik> handy!
17:42:48 <bcotton_> hmm...can non-chairs #action?
17:42:51 <bcotton_> i guess we'll find out :-)
17:42:58 <mhroncok> yes
17:43:09 <bcotton_> .fire mhroncok
17:43:10 <zodbot> adamw fires mhroncok
17:43:11 <lruzicka[m]> zodbot thinks different
17:43:24 <mhroncok> ok, now you got me. not sure
17:43:29 <bcotton_> okay, let's move on to the accepted blockers already in progress
17:43:38 <bcotton_> #topic (1933454) /etc/resolv.conf is not a symlink
17:43:39 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1933454
17:43:41 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/265
17:43:42 <bcotton_> #info Accepted Blocker, anaconda, ON_QA
17:44:15 <bcotton_> is this one in the RC? and if so, has anyone verified it?
17:44:40 <adamw> yeah, this is in the RC
17:44:40 <bcotton_> i'm guessing it isn't since it only hit
17:44:41 <cmurf> itis in the rc i have verified it
17:44:51 <bcotton_> whoops, i meant to correct myself instead of hitting enter
17:44:53 <adamw> cmurf and I verified the fix with the live image openQA built
17:44:57 <bcotton_> oh well. i am wrong for eternity
17:45:03 <adamw> ...and i guess cmurf verified it with the RC :) so nothing much to do here
17:45:20 <bcotton_> #info Fix is verified in RC1
17:45:36 <lruzicka[m]> in my RC installed, this is a symlin
17:45:37 <lruzicka[m]> k
17:45:42 <bcotton_> #topic (1935331) unable to login on laptop with fingerprint reader
17:45:43 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1935331
17:45:45 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/292
17:45:47 <bcotton_> #info Accepted Blocker, authselect, ON_QA
17:45:54 <cmurf> i'm running unmodified RC1 right now on the laptop i'm typing on :P so... cheater!
17:47:01 <cmurf> was this fixed with authselect-1.2.2-5 or -6? doesn't matter, rc1 has -6 on it
17:47:17 <lruzicka[m]> didn't we say this had been fixed?
17:47:38 <bcotton_> we did now
17:47:40 <bcotton_> #info Fix is verified in RC1
17:47:55 <bcotton_> #topic (1937550) Crash reporting does not work in text installer mode due to missing report-cli
17:47:57 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1937550
17:47:58 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/297
17:48:00 <bcotton_> #info Accepted Blocker, lorax, MODIFIED
17:48:33 <nirik> this is the one not in rc1
17:48:41 <cmurf> fix is not in rc1, but i tested it by adding just /usr/bin/report-cli to rc1 and then it works
17:48:54 <adamw> yeah, i found this in RC1 testing
17:49:10 <adamw> openQA will have built an image with the fix included by now, i meant to confirm that it was fixed last night but didn't get the roundtuits
17:49:18 <adamw> cmurf's test strongly indicates it ought to be fixed, though
17:49:25 <bcotton_> adamw: is that something you can check quickly now?
17:49:55 <Southern_Gentlem> bcotton_, is this the last on the list ?
17:50:56 <bcotton_> Southern_Gentlem: there's one more not in VERIFIED
17:51:06 <Southern_Gentlem> ok
17:51:51 <Southern_Gentlem> can we move on to it while waiting for adamw report on this
17:52:06 <adamw> bcotton_: it'll take a bit of time as i need to download the image
17:52:06 <adamw> starting it now
17:52:07 * pwhalen marks it verified
17:52:09 <adamw> so let's move on for now
17:52:10 <bcotton_> that's why i asked adamw if it could be checked quickly
17:52:14 <bcotton_> okay, cool
17:52:21 <adamw> it's not really important to check it right now anyway, is it? since the fix isn't in the rc
17:52:29 <bcotton_> fair enough
17:52:38 <bcotton_> #topic (1930977) [abrt] gnome-shell: nouveau_fence_signalled(): gnome-shell killed by SIGSEGV
17:52:39 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1930977
17:52:41 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/241
17:52:42 <bcotton_> #info Accepted Blocker, mesa, VERIFIED
17:52:50 <bcotton_> this is VERIFIED, nothing more to see
17:52:57 <bcotton_> #topic (1936991) Failed to post KMS update: drmModeAtomicCommit: Invalid argument
17:52:59 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1936991
17:53:00 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/294
17:53:02 <bcotton_> #info Accepted Blocker, mutter, ON_QA
17:53:13 <pwhalen> Now VERIFIED
17:53:27 <bcotton_> magic!
17:53:37 <bcotton_> #info This is now VERIFIED
17:53:59 <bcotton_> oh look, a new proposed blocker
17:54:06 <Southern_Gentlem> no easy fixes for these 2 exist correct ?
17:54:10 <bcotton_> #topic (1937785) Fedora install failed with qemu on a P9 PowerPC "couldn't claim memory"
17:54:11 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1937785
17:54:13 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/301
17:54:15 <bcotton_> #info Proposed Blocker, grub2, NEW
17:54:48 <lruzicka[m]> Hah, a late time blocker :D
17:54:49 <adamw> uh, ppc64le still isn't blocking, is it?
17:54:58 <bcotton_> i just looked, it is not
17:54:58 <Southern_Gentlem> -1 blocker not a release blocking arch
17:55:00 <bcotton_> that makes it easy
17:55:09 <adamw> yup
17:55:10 <adamw> -1
17:55:11 <pwhalen> I don't this can be a blocker, but :(
17:55:11 <frantisekz> -1
17:55:15 <adamw> per https://fedoraproject.org/wiki/Releases/34/ReleaseBlocking we only block on x86_64 and aarch64
17:55:18 <adamw> +1 FE
17:55:21 <lruzicka[m]> -1
17:55:21 <pwhalen> -1 blocker
17:55:31 <nirik> -1 blocker, +1 FE
17:55:33 <mhroncok> +1 FE, -1 blocker
17:55:34 <Southern_Gentlem> +1 fe
17:55:42 <copperi> -1 +1 fe
17:55:58 <pwhalen> +1 fe
17:56:01 <lruzicka[m]> +1 fe because this is what he wanted to request anyway
17:56:09 <bcotton_> proposed #agreed BZ 1937785 - RejectedBlocker(Beta), AcceptedFE(Beta) - ppc64le is not a blocking architecture, but this is worth fixing if we can
17:56:13 <frantisekz> ack
17:56:16 <Southern_Gentlem> ack
17:56:18 <lruzicka[m]> ack
17:56:25 <copperi> ack
17:56:33 <mhroncok> ack
17:56:42 <adamw> ack
17:57:05 <bcotton_> #agreed BZ 1937785 - RejectedBlocker(Beta), AcceptedFE(Beta) - ppc64le is not a blocking architecture, but this is worth fixing if we can
17:57:26 <bcotton_> #topic Current status - blockers
17:57:42 <bcotton_> so... this basically leaves us with just the lorax blocker, right?
17:57:46 <Southern_Gentlem> ok i am lost what about the gnome-shell and mutter before?
17:57:48 <nirik> so we have to decide that one blocker right?
17:58:13 <pwhalen> Southern_Gentlem: those are verified
17:58:39 <Southern_Gentlem> which means fix exist and in rc1?
17:58:55 <nirik> fix exists, in rc1 and verified to actually fix the issue. :)
17:59:01 <Southern_Gentlem> ok
17:59:16 <bcotton_> #info One accepted blocker remains
17:59:34 <bcotton_> #topic Current status - test matrices
17:59:35 <bcotton_> #link https://fedoraproject.org/wiki/Category:Fedora_34_Test_Results
17:59:41 <Southern_Gentlem> and thats the one adamw is checking on?
17:59:46 <bcotton_> yes
17:59:55 <adamw> right
17:59:56 * nirik runs for more coffee
18:00:01 <adamw> so for matrices, uh
18:00:56 <adamw> we're missing a couple of base tests on aarch64
18:01:10 * pwhalen looks
18:01:14 <adamw> (though it's extremely unlikely either is broken)
18:01:34 <adamw> i'm trying to remember why we don't have package install/remove automated...oh well
18:02:16 <lruzicka[m]> I thought we did have it, but if not, I will take it
18:02:32 <pwhalen> *sigh* Sorry, I missed those
18:02:34 <lruzicka[m]> to make it before final
18:03:01 <adamw> we're missing the same couple tests on cloud local, and we don't have any non-local cloud tests for x86_64
18:03:59 <adamw> we're missing a couple of AD tests, though alciregi did one at least and chances of the other two working if that one works and the other two work for freeipa is high
18:04:08 * pwhalen is running the add/remove now
18:04:32 <adamw> so we're not quite at full coverage but fairly close, and we could knock out most of the missing tests quickly. but probably not worth rushing to do them unless someone seriously wants to propose waiving the blocker and releasing rc1
18:05:48 <bcotton_> i mean, it's not the worst blocker in the world. but i'd rather get an rc2, i think
18:05:55 <Southern_Gentlem> i do want to propose we table this meeting til 2pm EST tomorrow and see if we can do a rc2 to solve the issues
18:06:03 <adamw> i personally would quite like to fix a lot of the bugs for an rc2
18:06:09 <adamw> even if that means not rushing to do it tomorrow
18:06:20 <adamw> let's close out this topic first though?
18:06:28 <bcotton_> agreed
18:06:39 <bcotton_> any questions or comments on the test matrices?
18:07:44 <bcotton_> hearing none...
18:07:50 <bcotton_> #topic Current status - RC
18:08:09 <bcotton_> #info RC1 is the current candidate
18:08:28 <bcotton_> are silverblue and python classroom lab missing on all arches or just some?
18:09:28 <Southern_Gentlem> is silverblue a blocker
18:09:38 <adamw> no, it's still not a release-blocking image
18:09:40 <nirik> silverblue is only missing on x86_64
18:09:51 <adamw> did we figure why it's missing yet?
18:10:49 * nirik looks
18:11:22 <adamw> and to be clear: https://bugzilla.redhat.com/show_bug.cgi?id=1937550 is not fixed in RC1 and is an accepted blocker
18:11:26 <adamw> so unless it gets waived we cannot ship RC1
18:11:28 <nirik> installing flatpaks...
18:11:46 <adamw> i found the error there but didn't get past that
18:11:49 <nirik> but I am not sure why. Possibly a transitory thing because aarch64 worked
18:11:50 <adamw> posted it in the failed-composes ticket
18:12:09 <bcotton_> #info Silverblue is missing on x86_64 due to a failure during flatpak installs
18:12:28 <bcotton_> #info Python Classroom Lab is also missing
18:12:45 <bcotton_> #info RC 1 does not contain a fix for accepted blocker BZ1937550
18:12:49 <Southern_Gentlem> i3 still doesnt have wireless support
18:13:18 <mhroncok> > Python Classroom Lab is also missing
18:13:20 <mhroncok> not again
18:14:08 <nirik> the only python classroom thats missing is the arm one
18:14:10 <nirik> armv7
18:14:16 <mhroncok> yes, that is OK
18:14:32 <mhroncok> I was not able to decipher the problem
18:14:35 <nirik> and I think thats also been failing in rawhide/branched... but I am not sure why
18:14:38 <Southern_Gentlem> so are we pushing a week or going to try tomorrow
18:14:39 <mhroncok> there is a screenshot with no error on it
18:14:44 <kalev> do you guys have a link to the failed silverblue? I can't find it in https://pagure.io/releng/failed-composes/issues
18:15:12 * mhroncok is fine to srop the armv7 lab and switch to aarch, just didn't get to it
18:15:15 <mhroncok> *drop
18:15:17 <nirik> kalev: https://koji.fedoraproject.org/koji/taskinfo?taskID=63475299
18:15:23 <kalev> nirik: thanks
18:15:51 <bcotton_> anything else on the RC before we figure out what to do about it?
18:16:34 <kalev> that's a configuration error somewhere in pungi, someone sedded f33/f34/ wrongly so it's trying to install a nonexistant f34 flatpak runtime
18:16:51 <nirik> kalev: ha. whoops
18:16:56 <bcotton_> yay, an easy fix!
18:17:00 <bcotton_> #topic Go/No-Go decision
18:17:14 <bcotton_> okay, so before we get too far down the rabbit hole...
18:17:25 <bcotton_> does anyone want to propse that we waive BZ 1937550 and ship RC1?
18:17:38 <bcotton_> (i do not, but i want to give others the option)
18:18:18 <kalev> next time, I think it would be nice to have an earlier compose attempt even if all blockers aren't lined up, so that there's time to fix issues like this that only show up when a compose is done :)
18:18:21 * Southern_Gentlem shakes head NO
18:18:37 <kalev> (that was re the silverblue failure)
18:18:56 <bcotton_> agreed, kalev
18:18:59 <nirik> bcotton_: I don't. I guess we could under the 'it was too soon' rule, but I don't personally want to.
18:19:25 <bcotton_> okay, no one is jumping up to do this, so the next question becomes what do we do for RC2
18:19:49 <bcotton_> i'd be okay with trying again tomorrow if it only contained a fix for the lorax issue. the more we add, the less okay i am with that
18:19:49 <lruzicka[m]> I'll say, do not rush it.
18:20:01 <Southern_Gentlem> i think we push a week so we there is time for the rc2 and it to be tested
18:20:24 <mhroncok> well, we want to add the intial gnome error message fix if possible, right?
18:20:30 <copperi> I am+1 on adamw's earlien proposal
18:20:31 <bcotton_> yeah, the "early target date" is generally pretty aspirational
18:20:41 <adamw> yeah honestly i would like to fix a lot of the FEs
18:20:43 <bcotton_> mhroncok: i certainly would like to get that in
18:20:45 <adamw> and even consider pulling in the newer plasma
18:20:45 <adamw> and get silverblue in
18:20:47 <nirik> The only reason I would want to do a quick rc2 and try soon is our auth system rollout... but we can see about pushing that a week too I guess.
18:20:52 <pwhalen> I would prefer we not ask for hero testing by tomorrow. If we can roll over the results with a target change, ok. if not we should slip a week and pull in the other FE's
18:21:02 <adamw> honestly i feel like i whiffed a bit on rc1 and should've got some fixes in it that we didn't, i'd like to take a bit of time and get a better build
18:21:36 <Southern_Gentlem> rc1==NO-GO
18:21:50 * pwhalen updated add/remove package test for aarch64 workstation
18:21:59 <lruzicka[m]> +1 to take time, let's say until Tuesday and then make RC2 on Tusday night to have like 2 days of testing
18:21:59 <Southern_Gentlem> adamw, nope you can only do what you can do
18:22:20 <adamw> Southern_Gentlem: i kinda forgot to look through the FEs carefully when requesting rc1 :( there was stuff we could've got in that i missed
18:22:34 <Southern_Gentlem> adamw, you are only human
18:22:39 <adamw> we can probably do an RC sooner than tuesday, i'll try and get it today or tomorrow
18:22:54 <adamw> but i'd want to put in quite a lot of change, more than we could safely hero-test
18:23:01 <bcotton_> is there anyone here *not* in favor of waiting until next week (i.e. really really wants to try again tomorrow)
18:23:05 <nirik> yeah, rc2 as soon as we can reasonably
18:23:10 * pwhalen wipes sweat from his brow
18:23:36 <nirik> pwhalen: does anything on the python classroom leap out: https://koji.fedoraproject.org/koji/taskinfo?taskID=63480680 seems like it booted and then just never started anaconda?
18:23:46 <adamw> we haven't been through the FEs in detail but there's like four or five others which are "well, it's not a BLOCKER, but...it'd really be good to fix it" kinda things
18:25:09 <bcotton_> #agreed Fedora Linux 34 Beta is NO-GO
18:25:10 <bcotton_> #info The next F34 Beta Go/No-Go meeting will be Thursday, 2021-03-18 at 1700 UTC
18:25:12 <bcotton_> #info F34 Beta shifts to target release date #1: Tuesday 2021-03-23
18:25:24 <bcotton_> #action bcotton to announce decision
18:25:36 <bcotton_> #topic Open floor
18:25:38 <bcotton_> Anything else we need to discuss before closing?
18:26:11 <bcotton_> (also: note that since much of the Americas changes to daylight saving time on Sunday, the next meeting will feel an hour later for many of you)
18:26:23 <nirik> I'll see if we can't push the new account system rollotu back. Will see what pushback I get on that. ;)
18:26:53 <mhroncok> nirik: I assumed beta freeze implies for infra as well, no?
18:27:02 <lruzicka[m]> I have found a problem with Abrt today: https://bugzilla.redhat.com/show_bug.cgi?id=1936898
18:27:20 <lruzicka[m]> have you seen it and is it worth an FE for Beta?
18:27:35 <nirik> yeah, but they have a number of scheduling things to balance and they were planning on next week. ;( will see.
18:27:40 <pwhalen> nirik: 00:04:48,552 ERR anaconda:anaconda: ui.tui.hubs.summary: Not enough space in file systems for the current software selection. An additional 2.74 GiB is needed.
18:27:44 <lruzicka[m]> no, not this one: https://bugzilla.redhat.com/show_bug.cgi?id=1937783
18:27:52 <nirik> pwhalen: ah ha. easyfix
18:28:02 <pwhalen> heh :)
18:28:08 <mhroncok> nirik: do I need to do anything?
18:28:08 <lruzicka[m]> this one is more important (1937783)
18:28:10 <bcotton_> nirik: i am happy to flex on anyone who argues against you :-)
18:28:58 <bcotton_> lruzicka[m]: if you nominated it, i'd give it a +1FE
18:29:06 <nirik> mhroncok: yeah, add space in the kickstart...
18:29:37 <lruzicka[m]> bcotton_: II nominated it for final blocker, but could renominate for beta FE, too
18:31:14 <bcotton_> okay, it sounds like we're done here
18:31:19 <bcotton_> thanks everyone for a valiant effort :-)
18:31:42 <adamw> thanks for trying to impose order on chaos, bcotton :P
18:31:42 <lruzicka[m]> no problem
18:31:43 <frantisekz> thanks bcotton for leading the meeting :)
18:31:46 <bcotton_> we'll try this again next week
18:31:54 <adamw> i will try and put together an rc2 request tonight or tomorrow
18:31:57 <lruzicka[m]> ok, see you then
18:31:59 <bcotton_> #endmeeting