17:00:28 #startmeeting F33 Final Go/No-Go meeting 17:00:28 Meeting started Thu Oct 22 17:00:28 2020 UTC. 17:00:28 This meeting is logged and archived in a public location. 17:00:28 The chair is bcotton_. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:28 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:28 The meeting name has been set to 'f33_final_go/no-go_meeting' 17:00:29 #meetingname F33-Final-Go_No_Go-meeting 17:00:29 The meeting name has been set to 'f33-final-go_no_go-meeting' 17:00:36 #topic Roll Call 17:00:40 .hello2 17:00:41 .hello ngompa 17:00:44 coremodule: coremodule 'Geoffrey Marr' 17:00:47 King_InuYasha: ngompa 'Neal Gompa' 17:00:48 .hello2 17:00:49 pwhalen: pwhalen 'Paul Whalen' 17:00:50 morning 17:00:55 hey 17:00:58 * nirik gets some coffee. 17:01:07 this may end up being the most well-attended go/no-go meeting in recent memory 17:01:15 .hello jbwillia 17:01:16 Southern_Gentlem: jbwillia 'Ben Williams' 17:01:34 .hello2 17:01:35 frantisekz: frantisekz 'František Zatloukal' 17:01:48 * sumantro is here 17:01:51 .hello mohanboddu 17:01:52 mboddu: mohanboddu 'Mohan Boddu' 17:02:04 .hello sumantrom 17:02:05 sumantro: sumantrom 'Sumantro Mukherjee' 17:02:19 .hello2 17:02:19 sgallagh: sgallagh 'Stephen Gallagher' 17:02:23 I remember bcotton_ saying ship it :P 17:02:59 I am here :) 17:03:05 .hello chrismurphy 17:03:06 cmurf: chrismurphy 'Chris Murphy' 17:03:56 i'm going to go ahead and start....the process while people join 17:04:01 because this may take a while :-) 17:04:12 .hello2 17:04:13 #topic Purpose of this meeting 17:04:13 x3mboy: x3mboy 'Eduard Lucena' 17:04:14 #info Purpose of this meeting is to check whether or not F33 Final is ready for shipment, according to the release criteria. 17:04:15 .hello lruzicka 17:04:16 #info This is determined in a few ways: 17:04:17 #info 1. No remaining blocker bugs 17:04:18 lruzicka2: lruzicka 'Lukáš Růžička' 17:04:19 #info 2. Release candidate compose is available 17:04:20 #info 3. Test matrices for Beta are fully completed 17:04:31 ^ Final ? 17:04:35 DOH 17:04:38 #undo 17:04:38 Removing item from minutes: INFO by bcotton_ at 17:04:20 : 3. Test matrices for Beta are fully completed 17:04:46 #info 3. Test matrics for Final are fully completed 17:05:18 okay, let's do this 17:05:27 #topic Current status - blockers 17:05:28 #link https://qa.fedoraproject.org/blockerbugs/milestone/33/final/buglist 17:05:38 Before we start discussion, I'm going to set expectations 17:05:58 good call :) 17:06:00 I know this was a very contentious discussion in the FESCo meeting yesterday, so I'll just remind everyone of the Friends foundation 17:06:14 +1 17:06:33 Yeah. This is a situation where I have an opinion, but I know it's a hard call and I have a lot of respect for the other point of view and those of you who hold it :) 17:06:36 try to keep your comments short and on-topic and let's make sure we're taking turns to let people speak 17:07:11 * Southern_Gentlem gets popcorn 17:07:14 * sgallagh puts away the megaphone and looks sad. 17:07:39 and i'll say this ahead of time because i don't want it to seem like a last minute thing, but traditionally blockers require a clear consensus (generally understood to be a net +3 or so) and the default state is not a blocker 17:07:51 so having said that, let's actually look at the blockers 17:08:15 #info 1 Proposed Blockers 17:08:16 #info 0 Accepted Blockers 17:08:18 #info 0 Accepted 0-day Blockers 17:08:26 #topic (1883609) Secure Boot fails to boot F33 Beta image 17:08:27 #link https://bugzilla.redhat.com/show_bug.cgi?id=1883609 17:08:28 #link https://pagure.io/fedora-qa/blocker-review/issue/135 17:08:30 #info Proposed Blocker, shim, ASSIGNED 17:08:48 #info Vote in ticket is currently FinalBlocker (+7, 1, -6) 17:09:38 so....anyone want to change some minds? 17:09:40 is that the votes from the revoting recently? or includes eariler ones? 17:10:00 ? 17:10:11 The revote reset the count. So it's current. 17:10:13 nirik: this is since the vote was reset yesterday 17:10:14 Is it useful for me to repeat my points from the ticket? 17:10:35 ok 17:10:35 yes 17:10:56 i will note, though that the fact that Ubuntu is stopping the rollout of the dbx was not shared until after several votes (in both directions) were lodged 17:11:13 mattdm: standby. Southern_Gentlem: did you have a question? 17:11:31 let mattdm go he may answer my question 17:11:43 ack. mattdm, all you your Popeliness 17:11:47 lol 17:11:53 So I think there's no good answer here. 17:12:00 But, I'm leaning towards "ship it" 17:12:06 The basic thing is: 17:12:12 Fedora 32 already has this problem. 17:12:26 If we don't ship, we're in the same state of "brokeness" 17:12:28 So why not ship? 17:12:57 We can produce updated images later. Southern_Gentlem proves it is possible :) 17:13:02 so... to me, the fact that Ubuntu *finally* pulled the update makes me more comfortable with releasing now 17:13:09 ? 17:13:23 we do not have the capability to produce all the images post-GA, but we should develop that facility 17:13:34 . 17:13:38 with respins! i mean, not quite the same, but it's not like it's a mystery 17:13:46 mattdm: actually it is 17:13:54 I don't even *know* how half our images are made 17:14:00 Let's not get too far off-topic. 17:14:13 I take it as granted that we have the ability to solve that. It's work, not a mystery. 17:14:15 well, I was looking into that and I think it might not be as hard as I was thinking. 17:14:17 nirik has indicated that it should be doable, 17:14:19 anyway, I'm willing to change to -1 FinalBlocker now, with the proviso we have a Fedora Magazine article explaining this 17:14:34 bcotton, I want to go -1 from 0 17:14:35 we need it anyway now that all old-world keys are busted 17:14:39 sumantro: ack 17:14:44 King_InuYasha: I'll second the magazine article request 17:14:48 . 17:14:55 Do we have any volunteers to _write_ said article? 17:14:58 mhroncok: ? 17:15:02 so what is the timeline from upstream of getting the new shim? is that known? 17:15:04 (not sure if this is the established way to get some space) 17:15:08 Southern_Gentlem: no 17:15:19 Southern_Gentlem: no, but pjones was optimistic about a two-week timeline 17:15:24 We can reproduce the images and put them somewhere for people to access 17:15:31 optimistic but no guarantees. 17:15:41 sumantro: you were a 0 in the ticket 17:15:50 it might also be a rare instance where we update the GA repositories post-GA to add an updated package 17:15:51 i can do respins in 2 weeks if needed 17:15:51 * cmurf raises hand 17:15:56 sumantro: He said he wanted to switch to -1 17:15:58 Southern_Gentlem++ 17:16:02 bcotton yes, and I want to go FinalBlocker -1 17:16:05 err, bcotton_ 17:16:09 sumantro: sorry, i read that backwards 17:16:13 also not releaseing and holding 2-4 weeks really gets us anything 17:16:14 if we need to, we should make a new point release compose... IMHO. 17:16:21 mboddu: can we actually respin the GA? so the newer images will be available through Media Writer, from default getfedora links and so on...? 17:16:21 mhroncok and cmurf would like to interject. Let's allow them to 17:16:25 okay. let's let mhroncok go 17:16:35 I have a concern. We have an ability to block here and now and make sure we fix the problem or else we don't release Fedora. That's strong enough motivation to actually fix it and fix it in time. Once we vote -blocker and ship, the "we need to fix this AND release new media" problem has no process and I am afraid that it will be a huge pain. 17:16:53 if we are OK with that challenge, we shoudl ship 17:16:57 I will also go with -1 blocker since Ubuntu pulled the update as well, FYI bcotton_ I haven't voted on that ticket so far 17:16:59 OOOh. I want that NEVER to be the reason to block. 17:17:00 Wrong hammer. 17:17:13 mboddu: ack 17:17:14 but I don't think that "always release on time" is a good enough reason not to slip 17:17:28 eom 17:17:39 mhroncok: thanks. cmurf, go ahead 17:17:43 did anyone ask pjones whether it's possible to just resign the current (old 2018 built) shim? and does it matter if it's an option? 17:17:52 I think we have enough motivation to fix that without "we're withholding all other features for everyone so get with it" as a motivator 17:18:00 frantisekz: Probably not, its not that it cant be done, but it will be very tricky and messy 17:18:02 cmurf: He's been asked, but has not replied. 17:18:21 -1 FB THTF 17:18:39 THTF? 17:18:47 too hard to fix 17:18:48 To Help The Fedora 17:18:55 ha! 17:19:01 seems like a safe fast option that totally obviates the problem 17:19:08 cmurf: not quite 17:19:25 can this be fixed post release 17:19:27 I don't know this for sure, but I think one of the changes with shim is that it can be signed with two signatures 17:19:33 I am against 'respinning' f33... but I think we can do a 33.1 (or whatever seperate/different version) with some pain, but possible. It would need desire to do it, qa, etc. 17:19:47 Southern_Gentlem: It can be fixed for current installs, but the install media can't be changed post-release. 17:20:07 well, we *could* change the media if we really needed to 17:20:24 but somebody would need to own this problem 17:20:28 and part of the problem is that we don't know if it will be a problem before f34 is released. "no earlier than Q2" is right in the "well maybe but maybe not" for our schedule 17:20:31 sgallagh, well thats why the respin sig was started so we do that to fix issues 17:20:34 it won't happen automagically 17:20:41 mhroncok++ 17:20:41 frantisekz: Karma for churchyard changed to 17 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:20:42 ahoyhoy 17:20:46 hey adamw! 17:20:51 hi :) 17:20:51 Southern_Gentlem: I don't disagree. That's one of the mitigations we've been citing. 17:20:57 Southern_Gentlem: we cannot respin install DVDs, PXE images, or disk images :( 17:21:02 so has the Great Fedora UEFI Civil War started? 17:21:06 mhroncok: agreed, but it also might not be a problem. it's a *potential* problem at this point 17:21:06 * cmurf i think a 33.1 in the middle of the f34 cycle is begging for some combination of f34 slip and burn out by various people 17:21:09 yup 17:21:10 King_InuYasha: we can. it would be a 33.1 or something 17:21:11 adamw: we've been far too civil so far 17:21:19 adamw, yes, and only you can end it 17:21:46 Can we produce a "33.1" that's just the same except the updated shim package? 17:21:48 so as it stands right now, we've gone from (+7,1,-6) to (+7,0,-9) 17:21:51 Not "33 + all updates so far"? 17:21:58 mattdm: yes. but it would be effort still. 17:22:00 fwiw, a lot of my +1 is the same concern as mhroncok's 17:22:03 adamw is not around for the first few min of the meeting 17:22:07 because I agree that doing a full additional QA cycle is not viable 17:22:10 bcotton_: is there a scenario when we won't need to re-create the media? 17:22:11 i think he phrased that very well 17:22:12 Oh, he is here 17:22:19 adamw: that it won't be taken seriously? 17:22:23 I am going to ask a problematic questions - why is it so important that we "release on time"? 17:22:30 bcotton_: (if we release with old shim now) 17:22:31 or that there is no process? 17:22:34 that it would be easy to not manage to do it because there's no existing process or deadlines 17:22:41 mboddu: yes, if the revocations don't happen until after we release f34, the f33 media is far less important 17:22:41 mattdm: A change to the bootloader probably *does* warrant a good chunk of the QA cycle, though. 17:22:45 we'd be making it up as we went along 17:22:57 adamw: That *is* our core competency... 17:22:59 er, sorry,that was for mhroncok 17:22:59 I don't disagree, but I'm burned out now on this discussion 17:23:01 =) 17:23:21 Releasing on the schedule has huge benefits for our reputation, with users and with partners like Lenovo 17:23:36 I'm not saying two weeks will kill that, but it's a shame to break the streak 17:23:49 and we have so much stuff in this release that I'm eager to get it to users 17:23:52 I'd really rather have this fixed in GA, but the fact that this isn't progressively getting worse now makes me feel like it's less urgent 17:24:02 has any of the partners tested the f33 beta to see if it causes them issues 17:24:04 Also, given civil unrest in the USA, the news cycle post-Nov. 3rd may not be ideal 17:24:04 mattdm, ok, are you absolutely sure that releasing with this blocker not fixed will not harm the reputation? 17:24:06 having people try to install our current release in 4 months and it not working because of this would not do our reputation a lot of good. 17:24:07 (to note, Ubuntu yanked the dbx update this morning) 17:24:11 Being consistent with releases translates to people feeling confident about the distro as a whole 17:24:25 Southern_Gentlem: Lenovo is testing the F33 beta now, yes. 17:24:35 are they seeing this issue 17:24:36 sorry if this has already been asked, but do we have any kind of known schedule for when significant entities are planning to (re-)ship the key revocations? 17:24:38 They have, to cmurf's sadness I'm sure, turned of Secure Boot by default. 17:24:40 lruzicka, adamw: the problem is we don't know if that will happen or not. certainly not before april 1 according ot microsoft 17:24:54 adamw: "no earlier than Q2" is what i've been told Microsoft is saying 17:24:54 adamw: That's true, but we will also have the "well, try F34 Beta!" argument there... 17:24:56 adamw: "Q2 2021, probably-ish" 17:24:56 microsoft is obviously the big one, but ubuntu and system firmware updates too 17:24:59 adamw: toward the end of Q1 17:25:03 sgallagh: i hate that argument. 17:25:09 Fair 17:25:17 "our stable release doesn't work? eh try the beta" is not a reputation-enhancing proposition :P 17:25:28 Southern_Gentlem: no, because lenovo ships with secureboot off. :( 17:25:29 adamw++ 17:25:29 mhroncok: Karma for adamwill changed to 11 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:25:29 if we knew with any precision when this would happen, it would make the decision a lot easier 17:25:38 bcotton: yes. 17:25:38 I think the people who are most likely to be affected, though, are enthusiasts for whom "try the beta" isn't a hardship at all 17:25:41 fact of the matter is, nobody ever thought we'd have to do a key rotation for secure boot ever when we designed this whole thing 17:25:48 mattdm: +1 17:25:51 King_InuYasha: "designed" 17:25:55 On the plus side, Lenovo is one of the only manufacturers who publishes hashes of their firmware. Esoteric though it is, there is a way to verify you have manufacturer firmware. 17:25:56 which was, in retrospect, a really bad move 17:26:04 adamw: I'm trying to be somewhat charitable :P 17:26:13 mattdm: i'm also not buying that. for me enthusiasts are if anything more likely to fiddle around with turning SB off. 17:26:19 non-enthusiasts buy a laptop and leave it alone. 17:26:33 but they're not going to get updated dbx early 17:26:47 non-enthusiasts read all the websites that advise turning it off, do that, then never think about it again 17:26:57 mattdm: do you have next week's lottery numbers in that crystal ball too? :P 17:27:01 yes :) 17:27:06 okay, so if microsoft is saying q2 2021 17:27:09 4 41 56 1 57 3 17:27:09 that's april at earliest 17:27:23 But realistically, not before April 1 is the same as saying "Almost F34 release" 17:27:38 f34 'preferred' release is april 20 17:27:39 so, wj 17:27:44 they haven't said Q2 as far as I know 17:27:48 so that's already three weeks potentially, and that assumes f34 doesn't slip 17:27:53 So even if it happens right on Apr. 1, we do have the "F34 will be out soon" statement. 17:27:54 so we are going to delay f33 to till then or what 17:27:57 I've mostly heard March is the month that things will start shipping 17:28:02 what about this proposal, can we plan to release F34 a little earlier to be ready for the change? 17:28:06 See, I want us to be able to assume F34 won't slip :) 17:28:07 they've said 2021 publicly, and i've heard it's Q1 or Q2 17:28:12 Southern_Gentlem: No, the new key is available, the current key is getting revoked then 17:28:19 and of course we have absolutely no precedent for RH trying to jam major features into releases-that-will-become-RHEL or anything like that, that never happens. :P 17:28:21 But we aren't yet signed with the new key 17:28:31 adamw: naturally not :) 17:28:34 lruzicka: I wouldn't put F34 release date to an earlier point 17:28:56 there are other schedules around that - GNOME, KDE, gcc,... 17:28:57 cmurf: pjones reported they said "Not before Apr." explicitly to him in person. 17:28:59 shortening the F34 schedule is appealing, but given our downstream's development cycle, i would guess it will be too feature-ful to make it realistic 17:29:26 OK 17:30:15 shortening the F34 cycle isn't appealing to me for the exact same consistency reason :) 17:30:19 bcotton_: Asked about escalating F34 schedule in Workstation meeting a week ago and it's pretty much a no go. 17:30:22 it's a tough call. ;( 17:30:27 i want to thank everyone that has been beating the midnite oil troubleshooting this, but i see no way fedora should wait 2 weeks or 6months to release f33 17:30:34 As in, impractical to make it go faster. 17:30:48 Southern_Gentlem: there is no proposal to wait six months. 17:30:50 cmurf: yeah, unless we get gnome to release early, too 17:31:34 so the vote as it currently stands is net negative. anyone interesting in going from -1 to 1? 17:31:53 adamw, we release a new shim but M$ doesnt then people are mad because we shipped and nuked their windows install 17:31:56 because otherwise, it seems like we have as stable of an opinion as we're going to have 17:32:05 Southern_Gentlem++ 17:32:14 Southern_Gentlem: that can't happen. 17:32:31 Southern_Gentlem: on that last one, I think we're just shippign new signed shim not the revocation list 17:32:36 Southern_Gentlem: we're not changing the system's trusted keys. just signing our bootloader with a different one. 17:32:52 ok 17:32:53 alternatively: does anyone want to make a last-minute attempt at convincing the group that blocking is the way to go 17:32:58 bcotton: i just did :P 17:33:20 loll 17:33:27 Almost everyone of the major distros, and also Microsoft, have new-world key signed bootloaders.So the revocation list being pushed affects mostly us and maybe Debian and one other. 17:33:33 someone flip a coin 17:33:46 cmurf: Fedora and Debian are it 17:33:49 everyone else has been fixed 17:33:59 at least of the major secure boot supporting distros 17:33:59 i.e. dbx version >=190 17:34:24 Debian, however, only just introduced secure boot support with this latest release a couple years ago, so... 17:34:33 If we are going for a release, we should set expectations on the new images? Do we build them, release them.... 17:34:51 mboddu: what do you mean? 17:34:53 * cmurf hasn't voted yet 17:34:56 Let's start planning for it, but not say we will 17:34:58 mboddu: you mean a point release after f33? 17:35:04 what are your thoughts, cmurf? 17:35:10 bcotton_: ^^ yes 17:35:18 it's a coin toss, consequences either way 17:35:52 I'm not sure this meeting is the right place to discuss a possible point release... 17:36:01 cmurf: yeah. :( 17:36:06 mboddu: yeah, what mattdm said. we should start figuring out what we need to do, but we don't need to _do_ it until we know we have to 17:36:28 Okay 17:36:45 well that was the primary question in the fesco issue i filed that kicked this off :) 17:36:52 fwiw, i'd be solidly +1 if we knew with reasonable certainty that the new dbx would be widely distributed prior to the f34 release, but since we don't, it's hard for me to justify that 17:36:54 contingency 17:36:59 without a plan however we are basically creating a huge problem for our future selves 17:37:13 mhroncok: agreed 17:37:17 I would guarantee that we're going to be in trouble no matter what 17:37:20 nirik: i mean, i'm much more happy with a -1 if we make a definite commitment to ship at least some kind of respun image with a resigned bootloader 17:37:24 cmurf: and that ticket was solved by making it a blocker 17:37:25 at minimum a new workstation live 17:37:25 we can't do anything now, and we have no way to do anything in the future 17:37:33 by revoking the blocker status, we have unsolved it 17:37:37 adamw: I would want *all* media respun if we did that 17:37:39 adamw: ok, thats fair. 17:37:54 it is not acceptable, IMO, to have less than all of it 17:38:02 nirik: i would usually agree that the scope of the meeting is just "is it a blocker or not" but i think this case is unusual :) 17:38:19 We are not *automatically* creating a huge problem. "Everything is basically fine until F34 is released" is actually an outcome with a reasonable possibility 17:38:53 * mhroncok would eb ahppy to go -1 if we have a concrete contingency plan. "we might be able to release new media, fingers crossed" isn't it 17:39:01 And (as much as cmurf hates it), “disable secureboot” is a valid workaround. 17:39:10 also, "Everything is on fire until F34 is released" is a reasonable possibility :) , we should have some plan what to do in the fire case, imo 17:39:14 it's a valid work around 17:39:20 but bad advice 17:39:27 cmurf I 100% agree 17:39:28 Agreed 17:39:40 mattdm: there is no reasonable case where that is true 17:39:53 also ;) there is another work around not discussed 17:40:03 cmurf? 17:40:05 Resetting the firmware 17:40:05 mattdm: unless we have a plan to fix this very soon 17:40:18 so, would it help if we schedule a point after we have new shim signed and decide if we need a new point release then? otherwise it's just a case of it being enough of a problem to do it? 17:40:36 the same WHCP spec that requires (now optional) that SB can be disabled, also requires that a user can put the firmware into Custom mode, which in the simple case wipes all databases including the dbx. 17:40:38 nirik: yes. 17:41:34 nirik: yes, but let's not decide that schedule in this meeting since 1. we don't know when we'll have it and 2. we need to sit down and figure out what tasks are needed and where they'll fall on the calendar 17:41:40 but i guess there are some firmware floating about that don't do this reliably *shrug* 17:42:05 someone flip the coin and lets move on 17:42:14 well, deciding to schedule that might help folks -1 blocker this now... 17:42:34 nirik: yes, we can decide *to* schedule now, just not what the schedule will be :-) 17:42:35 we cant fix it now and i like nirik plan 17:43:17 nirik: I think we're at "not a blocker" given the rule bcotton_ said at the beging 17:43:48 But we definitely don't want to take this lightly and rubber-stamp so it's worth the discussion 17:43:54 if needed we can do a 33.a if needed but i have a feeling that f34 this issue will be resolved ( i hope) 17:44:14 proposed #agreed 1883609 - RejectedBlocker (Final) - There's no clear consensus, but the net vote is "not a blocker". The FPgM will work with appropriate parties to develop a schedule for a potential point release that contains a newly-signed shim 17:44:38 and even if we don't respin, we can definitely publicize when we have a new shim and tell people with secureboot off to turn it on 17:45:04 which may actually result in net greater secure boot use overall than if we hadn't run into this :) 17:45:12 :D 17:45:26 ack 17:45:32 ack 17:45:43 ack 17:45:48 reluctant ack 17:45:53 ack 17:45:57 sad ack 17:46:05 Cant do anything ack 17:46:06 lol :) 17:46:07 ack 17:46:11 yes 17:46:15 adamw: anything that could make you less reluctant or is it just a "this situation is sad"? 17:46:18 ack 17:46:18 sad sack sad ack 17:46:19 ack (I am taking the promise) 17:46:29 ack 17:46:35 bcotton: i would've liked a firmer commitment to new images. but oh well. 17:46:44 bcotton_: FYI, we can compose those images, and push them somewhere on to the mirrors, but not to the places where mediawriter looks at and people are familiar with 17:47:02 We might have to advertise about them 17:47:06 mboddu, adamw: that could be enough if properly advertised 17:47:12 well, they are still going to need qa, etc 17:47:19 mboddu: so we'd have to document TF out of it. that's doable, if not fully effective 17:47:54 nirik, we are always ready 17:47:55 mbooth: can we make mediawriter look there as well? 17:47:56 Yup and so, its extra work for QA and releng 17:48:10 mboddu: even if it's F31.x ? can't this be done? 17:48:19 if we do a point release, I think we should do it just like a release... make rc's, test, sync, update websites/docs, etc. 17:48:36 mhroncok: We could hardwire the mediawriter to look at the new location for f33 release 17:48:38 i suspect doing a release which literally added a .x to the release number would cause all kinds of fun 17:48:43 the more places we actually put that .1 in, the more fun 17:48:49 adamw++ 17:48:49 mattdm: Karma for adamwill changed to 12 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:48:54 it's a QE dream, isn't it :) 17:48:58 could be. 17:49:01 okay, i'm not seeing any nacks to my proposal 17:49:07 remember when we had a unicode character and a space in the release name, and that was so bad we stopped doing release names? yeah like that only worse. :P 17:49:08 I'm out of my boundaries here, but..... Do we know how many users are using secure boot? 17:49:14 x3mboy: no. 17:49:14 so i think we'll call that a decision made, if not loved 17:49:23 It will serve to measure the real affectation 17:49:30 so much more work for QA and releng and docs and websites and whatnot. isn't it worth slipping a bit? 17:49:31 I'm not using it, e.g. 17:49:56 mhroncok maybe! but it's a hard call that we just already ack'd 17:50:05 frantisekz: Id didn't get your question " even if it's F31.x ? can't this be done?" ? 17:50:10 right, sorry for bringing it up again 17:50:12 #agreed 1883609 - RejectedBlocker (Final) - There's no clear consensus, but the net vote is "not a blocker". The FPgM will work with appropriate parties to develop a schedule for a potential point release that contains a newly-signed shim 17:50:27 okay, so 17:50:32 with that decided 17:50:36 * nirik will make a releng ticket to track things we think will break with a point release. 17:50:39 mboddu: I mean, if we do it as another release, let's say 31.5, can't we put that into media writer/ getfedora? 17:50:41 #info Zero accepted blockers outstanding 17:50:50 mhroncok: it's okay to register your concern :) 17:50:59 #action bcotton to assemble a super team to figure out a 33.1 schedule 17:51:06 frantisekz: Okay, as I said earlier, we need to hard code that logic into media writer 17:51:18 okay, thanks 17:51:29 frantisekz: the answer to "can we make media writer find it" is already "yes it's just more work" 17:51:37 and also "work that we don't exactly have a precedent for how to do" 17:51:57 mboddu: do we? doesn't it get that from a json file? 17:52:08