14:00:01 #startmeeting FESCO (2020-09-30) 14:00:01 Meeting started Wed Sep 30 14:00:01 2020 UTC. 14:00:01 This meeting is logged and archived in a public location. 14:00:01 The chair is mhroncok. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:01 The meeting name has been set to 'fesco_(2020-09-30)' 14:00:05 #meetingname fesco 14:00:05 The meeting name has been set to 'fesco' 14:00:08 #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 14:00:08 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek 14:00:11 #topic init process 14:00:17 .hello2 14:00:18 decathorpe: decathorpe 'Fabio Valentini' 14:00:22 morning 14:00:22 .hello churchyard 14:00:25 mhroncok: churchyard 'Miro Hrončok' 14:00:38 .hello2 14:00:39 bcotton: bcotton 'Ben Cotton' 14:01:00 * King_InuYasha waves 14:01:04 .hello ngompa 14:01:05 King_InuYasha: ngompa 'Neal Gompa' 14:01:49 .hello2 14:01:50 sgallagh: sgallagh 'Stephen Gallagher' 14:02:10 .hello2 14:02:11 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 14:02:16 .hello2 14:02:17 dcantrell: dcantrell 'David Cantrell' 14:02:56 7 participants, missing cvernaand ignatenkobrain, right? 14:03:00 mhroncok: Can we exchange #2477 and #2476? I think it'll easier to handle them in opposite order. 14:03:03 *cverna and 14:03:10 zbyszek: ack 14:03:37 zbyszek: handle 2477 before 2476, right? 14:03:54 #topic #2474 F34 System-Wide Change: Rust Crate Packages For Release Branches 14:04:09 I was hoping to get ignatenkobrain here for the rist discussion 14:04:12 *rust 14:04:29 * mhroncok is quite happy with the proposal as it stands, including the update policy exception 14:04:32 I think he'd generally be satisfied with the exception that's included in the change proposal 14:05:18 decathorpe: would you like to punt this, or count the votes? 14:05:23 mhroncok: yes, 2477 first. 14:05:28 zbyszek: ok 14:05:44 if there's questions, I can answer them, but otherwise, I'm good 14:06:13 decathorpe: does that mean waiting for next week or counting the votes? 14:06:22 I see +5,1-1 in the ticket 14:06:56 I think with that we can just approve it 14:07:06 any additional votes here? 14:07:07 I've read through the rust one and don't have any questions, +1 from me 14:07:09 I'd be +1 if we vote today, though I was hoping to hear from ignatenkobrain. 14:07:15 I just added my vote to the ticket 14:07:18 * King_InuYasha expects the next items of business will eat all our time anyway 14:07:31 that's +7,1-1 14:07:35 I'll add my +1 to the ticket also 14:07:43 Thought I already had, but must have forgotten 14:07:50 sgallagh: you had 14:07:54 oh ok 14:08:08 * nirik is +1 to it, but also would have liked to hear more from ignatenkobrain 14:08:32 decathorpe: is this time sensitive at this point? 14:08:49 decathorpe: I'd say it only gets sensitive when we approach branching, right? 14:08:55 yes. 14:09:13 I can prepare the releng PRs in the meantime. 14:09:28 proposal: let's give ignatenkobrain a chance to discuss this next week 14:09:37 mhroncok: +1 14:09:50 mhroncok: +1 14:09:54 +1 14:09:56 mhroncok: +1 14:09:58 Sure, +1 14:10:10 +1 14:10:21 #approved let's give ignatenkobrain a chance to discuss this next week 14:10:28 * King_InuYasha just poked ignatenkobrain via telegram 14:10:32 I don't think a proper vote count matters here 14:10:49 King_InuYasha: thanks, we can circle back to this topic later if needed 14:10:58 yup sounds good 14:11:04 #topic #2477 Fedora 33 schedule: Is it correct there is only one week between Beta and Final Freeze? 14:11:26 any thoughts? 14:11:30 this one surprised me, actually 14:11:37 so we have done this either way over history. 14:11:40 King_InuYasha: the ticket or the fact that it happened? 14:11:44 the latter 14:11:46 yeah, one week is definitely a short window :( 14:12:00 sometimes taking from the buffer sometimes pushing out the final 14:12:02 especially given the 7 days in testing policy 14:12:04 I didn't realize we can easily wind up in a situation that nothing can really get done 14:12:18 that makes beta -> RC essentially pointless 14:12:22 thats a bit... strong 14:12:48 King_InuYasha: well, it pushes hundreds of pending updates in after the beta freeze 14:12:51 mhroncok: right. updates that don't get karma can't even go in during this time 14:12:54 Yeah, I'm sure we already pushed 10k packages after the freeze was lifted. 14:13:33 so i'll note that moving the target back means 1 slip puts us on the same day as a major news event in the US, which mattdm has said "we're not doing" :-) 14:13:37 zbyszek: pushing all those packages all at once after the freeze is lifted tends to cause new problems that can only be fixed during one week 14:13:48 I think the problem here is the 7 day window for bodhi 14:13:53 I am perfectly fine only spending this time in the schedule with fixing things 14:13:58 so essentially if we miss the first target, we'd slip two weeks and be well into november 14:14:19 bcotton: can we push the freeze, but not the target? 14:14:33 we could, but it's already only 2 weeks 14:14:38 or can we shorten the hold period for bodhi? 14:14:40 so you might have QA very upset 14:14:51 like 2 days instead of 7? 14:14:53 King_InuYasha: the bodhi period is 7 days by policy but 3 days in practice 14:15:20 I mean, if there's urgent updates, people can always ask for karma or for a FE 14:15:22 mhroncok: What do you mean by "3 days in practice"? 14:15:40 sgallagh: I mean if you create an update in f33 bodhi, it gets pushed in 3 days 14:15:56 sgallagh: the policy says 7 days after beta, but it ha snot been done yet 14:15:58 Oh, the default push time is 3 days for Branched. Right 14:16:21 hum, that should have been fixed. 14:16:24 we should probably not fix that 14:16:36 (the bug, I mean) 14:16:49 King_InuYasha: well if we want this to be 3 days, we need to ack that 14:17:12 I think reducing it to 3 days and making that actually *known* is probably enough to help deal with this 14:17:20 I think it's perfectly fine to requests FE for stuff instead of generally allowing naything in 14:17:22 because then at least you can get 2 update cycles 14:17:42 yeah, but adamw doesn't particularly want to pull in FEs post beta freeze 14:17:46 mhroncok: yeah, either FE or ask people for karma on important updates. 14:17:47 people tend to do big breaking changes between beta and final, this should teach them :D 14:17:52 well, more, since we unfroze updates last friday 14:17:57 mhroncok++ 14:17:57 sgallagh: Karma for churchyard changed to 16 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:18:31 * sgallagh sometimes feels like he's the only one who tries to honor the Change Freeze. 14:18:59 I try as well, but I mostly spend the entire post-change period fixing FTIs and FTBFSes 14:19:13 ok... so there are several things we can do 14:19:25 and few people care about giving karma for those things 14:19:32 0) do nothing 14:19:52 1) keep the bodhi time limit on 3 days on purpose for this cycle 14:20:12 2) postpone the freeze only and overwhelm QA 14:20:33 3) postpone the freeze and the release and make the pope sad 14:21:04 My preference: 1, 0, 3, 2 (in decreasing order) 14:21:14 :-D 14:21:19 my preference is for #1 14:21:23 #info https://bodhi.fedoraproject.org/updates/?search=&status=pending&status=testing&releases=F33 14:21:29 I'd be ok with 0, sort of ok with 1 and -1 to 2 and 3 14:21:37 193 updates. 14:21:42 preference for #1 14:21:42 I'd like to say that 2 is bad because QA is one very active contributor short now 14:21:53 my preference is #1, but generally speaking I never have a problem postponing a release 14:21:56 mhroncok: agreed 14:22:11 I'm with zbyszek (1, 0, 3, 2) 14:22:26 I'm torn between 1 and 3 14:22:36 FWIW: bodhi has not yet been changed to post beta (ie, it's still set for 3 days) 14:22:38 I am 0, then 1 and -1 to 2 and 3 14:22:39 dcantrell: The problem is that we effetively we can't postpone it just 1 week, and we don't want to postpone it 2 or 3 weeks. 14:22:52 why do we not want to postpone it 2 or 3 weeks? 14:23:07 then we start getting into the us thanksgiving. 14:23:17 so, it's 2 more weeks... 14:23:23 that's fair 14:23:30 and suddenly, it's winter holiday season 14:23:30 And also with a longer gap between Freezes, people tend to make bigger changes 14:23:31 yeah, the end of the year starts to get tight with holidays, fedora elections, etc 14:23:48 I don't particularly want to slip the schedule 14:23:50 also, it's better PR to ship in the month we said we would 14:24:13 we can always slip if we have blockers 14:24:16 I do like adhering to schedules, but it's also a creation of our own. So if adhering to a schedule is going to overwhelm a team, I don't like that approach. 14:24:20 On the list I linked there's 193 updates... We should ask people to test them and give karma. 14:24:22 (which is why the preferred target is the 3rd tuesday of october/april) 14:24:26 OK, does someone want to set up a ranked-choice vote for the four options? 14:24:42 sgallagh: thta might be pointles 14:24:57 it seems that 0 and 1 have the biggest support 14:25:20 given the options, I'm still on board with #1 14:25:36 Proposal: keep the bodhi time limit set for 3 days until the freeze 14:25:41 mhroncok: +1 14:25:47 +1 14:25:48 +1 14:25:57 +0.5 14:26:08 mhroncok: +1 14:26:08 +1 for that or the seven-day version 14:26:18 sgallagh: I'll get to that 14:26:44 +-0 14:27:33 now. Proposal: set the bodhi time limit to 7 days as it was supposed to be, keep the "de jure" status quo 14:27:44 +1 14:27:46 +1 14:27:56 +0 14:28:01 ±0 14:28:17 +1 14:28:41 +1 14:28:59 if my math skills are good, the previous proposal has more support 14:29:20 -1 14:29:44 King_InuYasha just made sure 14:29:45 so 14:30:22 #agreed Keep the bodhi time limit set for 3 days until the freeze (for this release cycle) +5.5,0.5,-0 14:31:09 nirik: anything that needs to be done to prevent bodhi adjusting the limit to 7? 14:31:15 I've closed https://pagure.io/fedora-infrastructure/issue/9302 14:31:52 I'll add a comment with a pointer to this decision so no one changes it. 14:32:17 #action nirik will add a comment with a pointer to this decision so no one changes it 14:32:20 nirik++ 14:32:31 #topic #2476 systemd-resolved by default should be deferred to a future release 14:32:39 and now the easy one 14:32:46 ha 14:33:04 I must admit I have not read the entire discussion 14:33:16 So... effectively how much time do we have to make adjustments? 14:33:40 zbyszek: 3 days + freeze exceptions 14:34:00 zbyszek: or, 5 days + karma 14:34:19 or more with blockers 14:34:28 I don't think it should be postponed or delayed. 14:34:30 I think freeipa already pushed an update with resolved fixes? 14:34:34 I am not convinced that we should defer the resolved feature 14:34:41 I know you are heroes, but this seems a bit tight 14:34:49 The problem is that people decided to test some rather special features very very late in the cycle. 14:35:04 honestly, the main concern on server and even though it's still nominally an edition, i'm not entirely sure we should care about it much anymore 14:35:23 And the work-arounds are fairly trivial, so even if some issues remain, I think a good Common Bugs entry will be enough. 14:35:25 * King_InuYasha was looking forward to resolved in Fedora Server actually 14:35:33 bcotton: joke proposal: We don't care about the server any more 14:35:37 :( 14:35:44 mhroncok: +1 14:35:47 -1 14:36:09 -1. I'm running fedora on my servers too :) 14:36:35 in seriousness, i think we need to have a talk about how we de-edition an edition, but that's a matter for council to tackle 14:36:42 so, how mch broken this actually is? 14:36:51 in practice, not very 14:36:51 so, would DNSSEC=allow-downgrade placate the issues? I guess not? 14:36:52 *how much 14:37:27 from the last comment in the ticket: "Either don't enable systemd-resolved on servers, or enable it in a way that does not break servers (eg configured to not drop DNS queries with the DO bit set)" 14:37:40 nirik: no, that's not the issue. The DO-bit issue is unrelated. 14:37:57 yeah, see that now. Had not read the last comment yet. 14:38:15 .fesco 2476 14:38:16 mhroncok: Issue #2476: systemd-resolved by default should be deferred to a future release - fesco - Pagure.io - https://pagure.io/fesco/issue/2476 14:39:09 any ideas? 14:39:49 proposal: Add #1879028 as FE, close 2476. 14:40:16 zbyszek: +1 14:40:16 .bug 1879028 14:40:18 mhroncok: 1879028 – systemd: Caching DNS resolver is not DNSSEC-aware - https://bugzilla.redhat.com/1879028 14:40:36 zbyszek: is it likely to be fixed? 14:41:00 Yes. 14:41:04 this is noted as being reported upstream 1.5 years ago 14:41:18 my point is, if we only approve FE, it might end up not being fixed 14:41:29 dcantrell: it wasn't a priority. It's the kind of thing that only very select people care about. 14:41:36 yeah, perhaps it should be a blocker? but thats a lot of pressure on it 14:41:37 a stronger option might be to have a blocker (fix or defer) 14:41:57 I know, but if it's been ignored that long then is there enough time for upstream to address it and get it working for release? My gut tells me no. 14:42:23 I would trust zbyszek to do the right things here for fixing and pulling it into Fedora 14:42:25 I am worried howeever that if we revert this change on last minute, it might be even more broken, as it would receive very little QA 14:42:43 that's a concern I have as well 14:42:56 dcantrell: yes, but now we are making this default... so the issue is a lot more pressing 14:43:06 So... I'd say people who care about DO propagation would not use the resolver on localhost anyway, so to a large extent we'd be working on something that would see very little use anyway. 14:43:13 exactly how niche are the use cases that are broken right now? 14:43:33 zbyszek: what's the real pain point of deferring this to f34? 14:43:34 nirik: not disagreeing there, but issue classification doesn't impact the amount of time it takes to fix something 14:43:42 in other words, would it be terrible if those only get fixed after GA? 14:43:46 indeed. 14:44:32 decathorpe: I think it's totally fine to fix it after GA. 14:44:33 we also *don't* have any criteria for evaluating this for QA anyway 14:44:34 if this was partially fixed and/or still had bugs in GA, would the majority of users care? would it fuck up their use cases? 14:44:48 King_InuYasha: true 14:45:01 I think it'd probably be fine as a post-GA fix 14:45:04 the majority of fedora users are desktop users, so no... ;) 14:45:17 hence why I'm okay with it being an FE 14:45:23 if it's fixed earlier, great, if not, welp 14:45:35 let's vote on the FE proposal please 14:45:38 yeah, so there we go 14:45:38 dcantrell: nobody knows for sure, but I think that assuming that it's a super-tiny minority of people is justified. 14:45:47 the proposal was: Add #1879028 as FE, close 2476. 14:45:52 zbyszek: yeah, seems reasonable to assume 14:45:59 mhroncok: +1 14:46:02 mhroncok: +1 14:46:05 +1, we could always revisit if needed 14:46:37 zbyszek: I count you as +1 14:46:41 ... and people who care about this, are most likely carying local configuration anyway. 14:46:47 mhroncok: +1 14:46:48 mhroncok: +1 14:47:14 can we make sure the release notes for GA contain an explanation about this known issue and what to do now? 14:47:25 dcantrell: common bugs 14:47:29 I know zbyszek originally noted this was more of a docs issue anyway 14:47:33 sounds good 14:47:46 sgallagh: ? 14:48:19 FWIW, I want to work on a blognote-style explanation for how resolved configuration works (with the VPNs and domain routing). 14:48:34 that would be cool 14:48:47 we are at +5. I'll abstain - it doesn't really make a difference and I don't feel comfortable voting on the topic as I've missed most of the discussion 14:48:50 zbyszek: i heard you want to write a Fedora Magazine article about this 14:49:09 #agreed Add #1879028 as FE, close 2476. (+5, 1, -0) 14:49:18 bcotton: I do? Oh, indeed. 14:49:29 #action zbyszek to mark 1879028 as a fesco accepted FE 14:49:45 i'm good at volunteering other people to do work, too :-) 14:49:50 #action zbyszek to write a Fedora Magazine article 14:50:11 #action zbyszek to make sure this gets into common bugs if it is not fixed 14:50:28 :) 14:50:30 zbyszek: proposal workflow in case you're not familiar https://docs.fedoraproject.org/en-US/fedora-magazine/writing-a-pitch/ 14:50:33 poor zbyszek 14:51:03 #topic Next week's chair 14:52:27 * mhroncok has dentist and depending on how good the painkillers are, might not attend 14:52:40 next week might be slightly chaotic for me (first week of new semester), so I'd rather not volunteer for next week, but I can do the week after that 14:54:52 anybody? 14:55:05 I'll do it. 14:55:18 (Sorry, I got a phone call from the NSA and had to take it.) 14:55:22 :o 14:55:26 don't tell us! 14:55:34 (Background check for a friend of mine) 14:55:39 #action sgallagh will chair next meeting 14:55:44 via phone? or neural implat? ;) 14:55:57 just tell them your friend is great, but cheated off you in math all through school 14:56:15 #topic Open Floor 14:57:49 any chance ignatenkobrain is here? 14:58:24 sgallagh: any followups on some of the topics you've missed? 14:58:53 I think I only missed the resolved one and I haven't been following it closely enough to have an opinion 14:59:40 ignatenkobrain didn't respond to my message in telegram, so I dunno 14:59:41 sgallagh: thanks for checking 15:00:02 ok 15:00:06 thanks all 15:00:09 see you next week 15:00:22 mhroncok++ 15:00:22 and go break something before the freeze 15:00:26 Thanks for chairing mhroncok 15:00:28 mhroncok++ 15:00:30 mhroncok-- 15:00:41 #endmeeting