17:03:02 #startmeeting FESCO (2023-09-21) 17:03:02 Meeting started Thu Sep 21 17:03:02 2023 UTC. 17:03:02 This meeting is logged and archived in a public location. 17:03:02 The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 17:03:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:03:02 The meeting name has been set to 'fesco_(2023-09-21)' 17:03:02 #meetingname fesco 17:03:02 #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor, tstellar 17:03:02 The meeting name has been set to 'fesco' 17:03:02 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok nirik sgallagh tstellar zbyszek 17:03:05 #topic init process 17:03:09 .hello2 17:03:10 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 17:03:12 .hello2 17:03:16 dcantrell: dcantrell 'David Cantrell' 17:03:17 .hello2 17:03:19 mhayden: mhayden 'Major Hayden' 17:03:36 .hello churchyard 17:03:37 mhroncok_web: churchyard 'Miro Hrončok' 17:03:59 morning 17:04:11 Son_Goku: please reintroduce yourself FTR. 17:04:33 Anyway, we have quorum. 17:04:41 .fesco 3059 17:04:42 zbyszek: Issue #3059: F39 incomplete changes: 100% complete deadline - fesco - Pagure.io - https://pagure.io/fesco/issue/3059 17:05:38 .hello ngompa 17:05:38 whats left here? 17:05:38 Son_Goku: ngompa 'Neal Gompa' 17:05:59 TBB: I sent an email two weeks ago, and didn't get any reply. 17:07:27 Also no movement in the bug (#2175941). 17:07:59 you are unlikely to get a reply... the change owner left red hat... might mail jwakey? he handled tbb in the past I think? but might be misremembering 17:09:38 OK, should we just bump this to F40? If somebody picks up maintainance, they'll probably do the change. 17:09:59 yeah, seems reasonable 17:10:00 I think that's reasonable 17:10:16 or just drop and the can resubmit? 17:10:23 they 17:10:31 Yeah, that's probably better. 17:10:46 Anyone against dropping? 17:11:21 no objection here 17:11:24 nope 17:11:29 none from me 17:11:37 #info ModernizeTBB is dropped. 17:11:39 drop 17:11:46 LegacyXorgDriverRemoval 17:11:59 drop 17:12:02 nirik: there was an ACTION for you to check check status. 17:12:05 Any update on this? 17:12:25 I mailed ajax... no reply 17:12:33 :( 17:12:55 Anyone against dropping? 17:13:07 it's been three releases at this point, I guess 17:13:29 I say drop it 17:13:37 +1 to drop 17:13:41 +1 too 17:13:41 #info LegacyXorgDriverRemoval is dropped. 17:13:59 Bigger ESP: this was all handled, nothing to do. 17:14:10 Enable bootupd for Fedora Silverblue & Kinoite: postponed by Owners to F40. 17:14:25 Enable fwupd-refresh.timer by default on IoT, CoreOS & Server editions 17:14:33 I'm not sure. Is this all done? 17:15:12 someone needs to merge it in fedora-release 17:15:38 https://src.fedoraproject.org/rpms/fedora-release/pull-request/279 17:15:59 yeah, I can... we were in freeze. 17:16:13 unless we don't want to after beta 17:16:21 I think it's fine. 17:16:48 #action nirik to look into the last pull request for Enable fwupd-refresh.timer by default on IoT, CoreOS & Server editions. 17:16:57 #info https://src.fedoraproject.org/rpms/fedora-release/pull-request/279 17:17:04 and there was a question outstanding? but I guess this is ok to merge and can be improved on 17:17:18 Allow Removal of tzdata 17:17:29 .hello tstellar 17:17:30 tstellar: tstellar 'Tom Stellard' 17:17:36 tstellar: hi 17:17:55 Sorry, I'm a little late. 17:18:20 hey tstellar 17:18:46 I think this is at least partially done. gcc and glibc are done according to https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3. 17:19:30 I think we should just let the Owner update the status as appropriate. 17:19:57 At least the main part is done, not sure about the "packages which would be beneficial to be changed". 17:20:47 +1 17:20:49 I'd consider this done 17:20:57 optiuonal is optional 17:21:02 #info Allow Removal of tzdata is (in its basic part) done. 17:21:31 correction: optiuonal is actually not optional, optional is optional 17:21:39 heh 17:21:56 The beaty of the inglish language is that you can insert a lot of letters without any effect. 17:22:00 OK, so that's all on the list. 17:22:16 \o/ 17:22:37 #topic #3063 Should we remove Systemd-boot support from Anaconda 17:22:42 .fesco 3063 17:22:46 zbyszek: Issue #3063: Should we remove Systemd-boot support from Anaconda - fesco - Pagure.io - https://pagure.io/fesco/issue/3063 17:22:57 (I now realize that I didn't set topic for the previous section. Too late to fix this now.) 17:24:01 Note that there were replies in the ticket just now. 17:24:37 > And it does work, it just needs to avoid the assorted fixes here/there that are the result of it largely being ignored for a year and the difficulty of testing install media, without actual install media. 17:25:06 So I think we should close the ticket. 17:25:30 +1 to close... seems being worked on 17:25:50 +1 to close 17:26:18 (please vote, this is a separate ticket so we should follow the procedure.) 17:26:25 +1 to close 17:26:40 +1 17:26:52 brb 17:27:00 +1 17:27:16 tstellar: ? 17:27:24 mhayden: ? 17:27:30 +1 17:28:11 #agreed REJECTED (0, 0, -6) 17:28:37 #topic #3068 Ongoing problems with ELN contributions 17:28:46 * mhroncok_web is back 17:28:54 .fesco 3068 17:28:55 zbyszek: Issue #3068: Ongoing problems with ELN contributions - fesco - Pagure.io - https://pagure.io/fesco/issue/3068 17:30:08 so, sounds like some dialog at least 17:30:18 is it enough to say things are going to be better? 17:30:30 better how? 17:30:44 I feel like with this one, we should be focused on specific PRs where the Developer Policy was alleged to have not been followed. 17:30:47 yeah, I don't think so 17:30:50 It's unfortunate that sgallagh is not here. 17:30:51 more documented, clearer understanding? 17:31:10 lack of transparency in ELN development is an ongoing issue 17:31:12 well, the ask is to document the policy re. eln branches and Packaging Guidelines differences and for the ELN developers to stop abusing provenpackager privs 17:31:15 we still need to know who is responsible for eln branches, and some other things 17:31:21 tstellar: I don't think "alleged" is necessary. The examples in the ticket are rather obvious. 17:31:25 Son_Goku: Indeed 17:32:48 zbyszek: Well, everything is alleged until a decision is made. But still I find the ticket hard to follow. I would prefer it were more like: Here is PR 12345, I don't feel like the policy was followed because ... 17:32:57 it would be nice to have sgallagh here... perhaps we ask to make sure he can make next week and we discuss then? 17:33:23 nirik: sounds good 17:33:59 FTR record, policies and documentation are needed, but this is not going to improve unless the problem is acknowledged by the ELN folks 17:34:08 tstellar: there was a discussion of general problems and then links to multiple problematic PRs 17:34:21 right 17:34:38 and the response in this ticket (or lack thereof) makes me think that the ELN folks do not accept this is an issue 17:35:47 well, sgallagh is one of the 'eln folks' and he replied a fair bit... is there others you expect to answer? 17:36:20 we can all smile at each other and say things like "we have a common gole here", but at the end of the day, I am... not well 17:36:39 gotmax: The orignal summary just had a link to one ticket. I'm not trying to criticise, it's just for someone like me without prior context, it would be eaiser to follow if there was a more ordered list of PRs with issues. 17:37:22 Otherwise, the discussion becomes too fragmented and it makes it harder to come to conclusion. 17:38:01 the replies so far pretty much focus on "this is not a problem" rather than "yes, we will deal with this", but maybe I misread it 17:38:01 I think that gotmax didn't want to discuss specific ticket. The issue lists four points: 17:38:12 There should be a formal policy about eln branches. Who is responsible for their maintenance and in what cases should they be created? The ways in which ELN diverges from Packaging Guidelines need to be documented so Fedora maintainers can properly review changes. 17:38:16 These changes are limited to packages that will actually end up as part of RHEL to avoid piling up cruft that will add to maintenance burden and affect EPEL packages that we can afford to package in the proper way. ELN developers are willing to respond to feedback and make changes. 17:38:25 Blah, this didn't format properly. 17:38:38 1. There should be a formal policy about `eln` branches. Who is responsible for their maintenance and in what cases should they be created? 17:38:38 I mean, I can edit the PR to include a bulleted list of problematic PRs, but that seems a bit besides the point 17:38:41 2. The ways in which ELN diverges from Packaging Guidelines need to be documented so Fedora maintainers can properly review changes. 17:38:44 3. These changes are limited to packages that will actually end up as part of RHEL to avoid piling up cruft that will add to maintenance burden and affect EPEL packages that we can afford to package in the proper way. 17:38:48 4. ELN developers are willing to respond to feedback and make changes. 17:39:36 and when ELN branches are created, they also need review to be shut down when they are not necessary 17:39:43 s/edit the PR/edit the ticket description/ 17:40:04 ELN deviations are supposed to be minimal 17:40:14 and an effort should be made to reconcile them 17:40:22 I haven't seen a lot of that either 17:40:31 in some cases they won't be able to 17:40:39 kind of the whole point of ELN is that there will be some subset of deviations 17:40:41 * mhayden is back 17:40:44 dcantrell: no 17:40:48 that's not the point of ELN 17:40:49 ELN changes in packages serves as a bookmark to indicate where that happens 17:40:58 * nirik wonders how many eln branches there are so far. 17:41:00 I think zbyszek's point 17:41:03 #1 is key here 17:41:14 there's not enough documentation indicating the responsible party and who handles what 17:41:29 All those things are 'get this process documented, approved and everyone agreeing to follow it' basically right? 17:41:37 yes 17:41:43 yeah, I think that'd help a lot. 17:41:49 ultimately, if there is going to be weird RHEL branches labeled ELN, then there needs to be RHEL maintainers taking ownership of those things 17:41:50 dcantrell: that's my point, but yes 17:42:04 Fedora maintainers can't do anything with ELN stuff 17:42:08 if we continue to push back at ELN changes, then we're basically saying "go fork Fedora and do your own thing then" which isn't what we should be indirectly pushing for 17:42:18 nirik: that and the issue about provenpackager privs 17:42:30 (I was quoting gotmax from the ticket. I should have made that clearer.) 17:42:41 provenpackager privs wrt ELN should be involved in this as-yet-to-be-written documentation 17:43:24 dcantrell: we also shouldn't allow RHEL tech debt to pile up in Fedora either 17:43:29 that can create its own problems 17:43:32 dcantrell: and I think that's the crux of the issue. asking them to follow basic policies (or even have them documented in the first place) is not us trying to tell them to fork Fedora or us purposely trying to make things difficult. 17:43:47 that's been incorrectly implied by multiple people 17:43:52 gotmax: agreed, it just seems we're all not quite aligned on the same page at the moment 17:43:54 yeah, +1 gotmax 17:44:05 "if we continue to push back at ELN changes" -- we are not, we just want the changes to maintain certain quality/standard 17:44:08 honestly, I'm starting to feel like there is forking going on 17:44:09 Son_Goku: I'm not advocating for that 17:44:24 and the response by eln is pretty much "your standards do no apply to us" 17:44:44 ^ this is something I've gotten in private a fair number of times 17:45:12 offhand, I only have one good interaction around reconciling RHEL and Fedora in ELN 17:45:13 my point was if we are insisting on following policy (which, to be clear, is something I want) and ELN keeps saying they don't have to and no one overrides the other, then that _could_ lead to ELN saying "well, this won't work...best do a fork" 17:45:13 IMHO it should be like epel... "all fedora guidelines, etc, with these small list of exceptions and reasons for them..." 17:45:33 nirik: +1 17:45:42 dcantrell: that would be appropriate if they're not willing to follow the rules of being part of Fedora 17:45:56 I would be happier if ELN had an EPEL-like setup 17:46:14 wrt rules, policy management, and community support 17:46:45 when we first did this, the pitch was "evolving the buildroot change to build all of Rawhide with RHEL build flags continuously" 17:46:49 nirik: +1 17:46:53 that was something I was comfortable with 17:46:57 what we're doing now, I just don't know 17:47:02 ah yes, "just the build flags" :) 17:47:18 I'm here, sorry 17:47:19 so yeah, some boundaries and policy documentation 17:47:21 Did we change rooms? 17:47:32 no, this has been the room for a while 17:47:44 we'll hopefully switch back to #fedora-meeting once we switch back to Tuesday 17:47:47 sgallagh: welcome. just in time for eln discussing. 17:47:54 sgallagh: since we moved the meeting day and #fedora-meeting was busy. 17:48:04 Is there a quick catch-up link? 17:48:54 https://paste.centos.org/view/364d755f 17:48:57 Thank you 17:49:00 https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2023-09-21/fesco.2023-09-21-17.03.log.txt 17:49:17 huh TIL 17:49:21 nice 17:50:40 Still reading, just a moment 17:52:38 as a side note with matrix, people who join the meeting room late can just see all the previous stuff in their client. ;) 17:52:40 OK, let me start replying. 17:53:06 nirik: we're almost there I hear :) 17:53:26 getting close. ;) 17:53:30 First: Regarding packaging deltas from Fedora: 17:53:54 (I've got a meeting starting at the next hour, but I'll stay in here too) 17:54:13 From a guidelines perspective, these indeed should not vary from Fedora in any way, with the following limited exceptions (which, indeed we need to document) 17:54:54 1. ELN may opt to bundle content more freely than in Rawhide. If we do so, we must follow the Fedora bundling policy. 17:55:47 2. ELN may opt to exclude (or bundle deps of) certain tests if running them would cause unwanted dependencies to end up in the RHEL content set. 17:56:33 That was always the policy, but this was poorly communicated by me to the team. 17:56:45 Were these exceptions agreed upon in the past but just never written down? 17:56:50 Yes 17:57:20 sgallagh: What about other dependencies (non-test)? I think those would also be dropped in ELN. 17:57:26 unwanted generally or actaully marked as such in the content resolver? 17:57:43 FYI, there are 17 eln branches for rpms. 17:57:56 mhroncok_web: If those two lists are not the same, a mistake has been made somewhere. 17:58:11 (and 4 modules) 17:58:22 The modules are not in use. 17:58:34 yeah. just listing for completeness 17:58:39 that was my implicit understanding, but it seems some of these PRs are going "above and beyond" that 17:58:42 17 is actually a few more than I expected. That likely means someone branched and didn't tell us. 17:58:55 Which means our automation is probably stepping on them 17:59:08 17 doesn't seem like a big problem. 17:59:15 the PR linked in the issue didn't follow the bundling policy and merged the change anyways despite being asked not to 17:59:26 zbyszek: it's a problem if nobody is responsible for maintaining them 17:59:45 zbyszek: The problem is that if we don't have them listed as exceptions in our automation, then Rawhide builds will clobber and replace their ELN builds 18:00:12 sgallagh: ack 18:00:41 well, also: where do people file bugs on them? who handles those bugs? 18:00:51 As for the maintenance question, I continue to tilt at that windmill. I'm attempting to get it made policy that RHEL maintainers need to apply for comaintainership in Fedora. 18:01:06 This has long been a problem, even before ELN 18:01:51 sgallagh: e.g. in https://src.fedoraproject.org/rpms/python3.12/pull-request/63 there is a claim that a package is unwanted, but the content resolver does not show that. 3 weeks of back and forth did not help 18:01:54 I think it's also worth documenting that Fedora maintainers are not responsible for ELN-ness in their packages if it shows up as a PR, branch, etc. 18:02:04 For those of you who are Red Hatters, expect to see a long email tonight or tomorrow; I've been drafting it for a couple days. 18:02:14 welp 18:02:19 sgallagh: thank you, I don't get much email :) 18:02:25 ha 18:02:37 dcantrell++ 18:02:37 zbyszek: Karma for dcantrell changed to 1 (for the release cycle f39): https://badges.fedoraproject.org/tags/cookie/any 18:03:01 sgallagh: can we put an action item on you to update the ELN docs with the list of exceptions and the other clarifications. 18:03:36 if there are exceptions to the exceptions, perhaps they should be approved by fesco ? if they are rare... 18:03:38 dcantrell: That's... not entirely how I would phrase it. I'd at least prefer to phrase it more like "are not mandated to maintain RHEL/ELN-specific changes". But I hope they're willing to accept help/patches. 18:04:34 I'm wondering if we need some kind of exception review 18:04:35 sgallagh: yeah, that's fine with me. the thing that should be clarified is that this is not a surprise back door way to give fedora maintainers more work they were not expecting 18:04:43 *regular exception review 18:04:46 well, we're being given low quality patches and the being expected to maintain them ourselves 18:04:57 gotmax++ 18:05:03 mhroncok_web: Sorry, just saw your other Q: yes, something like libb2 should indeed be added to the "unwanted" list. 18:05:07 gotmax++ 18:05:07 Son_Goku: Karma for gotmax23 changed to 1 (for the release cycle f39): https://badges.fedoraproject.org/tags/cookie/any 18:05:47 zbyszek: Yes, I'll take that action 18:06:13 #action sgallagh to preparate an update for the ELN documentation 18:06:19 sgallagh++, thanks 18:06:26 sgallagh++ 18:06:26 zbyszek: Karma for sgallagh changed to 1 (for the release cycle f39): https://badges.fedoraproject.org/tags/cookie/any 18:06:48 gotmax: What you're getting is the best that non-subject-matter-experts can provide. Of course, the packager in question has also not been as flexible as he should be. I've been trying to work with him on that. 18:06:58 I guess my primary issue here is that when we gave feedback on the low quality patches, we were told that it does not apply 18:07:14 (I really hate criticizing in public, but I feel like I have to address that elephant) 18:07:31 again, we're not asking everyone to be subject-matter experts. we're asking them to address our feedback. 18:07:45 and importantly, not dismiss them as invalid 18:07:47 gotmax: I think we're agreeing here. 18:08:03 mhroncok_web: If compliance with FPG will be clarified in the rules, then hopefully this stop being an issue. 18:08:12 hopefully 18:08:19 (Not not responding to feedback, but questions about what applies.) 18:08:38 (OK, actually I hope both ;)) 18:09:04 I *really really* want to get to a point where SMEs actually *are* the people maintaining things for ELN. 18:09:10 But it's been an uphill battle. 18:09:21 * gotmax does not know what SME is 18:09:25 subject matter expert 18:09:28 Subject Matter Experts 18:09:36 I think we can stop beating this horse, it seems very dead at this point. 18:09:39 RH is full of TLAs :) 18:09:57 and TLIs 18:10:21 zbyszek++ 18:10:22 zbyszek: I dunno, I hear the horse groaning... 18:10:26 :) 18:10:30 I have a small bit more to add, if that is alright? 18:10:36 sgallagh: oh, please go. 18:10:39 go for it 18:10:40 the horse can't take it! 18:10:55 zbyszek: fair enough. I guess we've agreed that the packaging guidelines differences need to be documented and that the eln branch thing needs to be addressed, but not exactly how to address the latter. 18:10:55 j/k 18:10:59 * dcantrell hands sgallagh the bat 18:11:20 Recently I learned that horses actually have about ~15 HP, so they can take much more than one would expect. 18:12:59 A major part of the issues here stem from schedule-obscurity. My team has been under some fairly tight deadlines for a while. 18:13:19 But these are neither communicated to Fedora at large nor, frankly, really anyone else's problem. 18:13:29 "A lack of planning on my part, etc. etc." 18:14:03 sgallagh: I think it would be useful to have the schedule be less obscure 18:14:14 But that does tend to leak out at times, when our internal schedule pressure doesn't line up with the outside world. 18:14:15 it also allows all the rest of us to be prepared for when the RHEL beast awakens 18:14:38 Son_Goku: I don't disagree, and I've been trying to announce as much as I'm allowed to. 18:14:53 Though I'll admit is has been a while since my last attempt at such 18:14:59 you sent out that detailed email about c10s branching last month FWIW 18:15:15 That was a couple months ago, and it's out of date :-( 18:15:31 so those internal deadlines should not drive Fedora schedule or policy. if ELN is to live in Fedora, then the communication should go the other way. internally you say "we'll we've submitted the PR and are waiting for..." or something like that 18:15:43 rather than pushing as hard as you can in Fedora because of some internal deadline 18:15:54 We're on a day-by-day slip regarding our big CentOS Stream 10 import... since the beginning of August 18:16:31 dcantrell: Agreed, in theory. Practice gets harder. 18:17:01 For example, one of the things holding up that big import is that a few packages suddenly started pulling in the entire Rust ecosystem again. Which we worked for months to strip out. 18:17:04 sure, and that's understandable. but the expectations should be in the documentation for how to handle those situations and fedora should have an equal seat at that table 18:17:29 this has been a problem since before August, but yes, I understand the deadlines are stressful and apologize that's causing friction 18:17:31 sgallagh: and isn't that the kind of thing we wanted ELN to give us a heads up for anyway? 18:17:40 FWIW, I agree. I'm not making excuses; I'm just trying to explain how we got here. 18:18:49 We're playing Whack-a-Mole with blockers to getting CS10 started, and that can wear on anyone over time. 18:19:17 yeah, no one likes the blocker bug treadmill 18:19:59 how's the horse doing? 18:20:07 Anyway, I hope this has provided at least a little bit of context. 18:20:30 mhroncok_web: still groaning! 18:20:31 Clearly, my team and I need to work on a few things. 18:20:56 I don't have anything more to add right this minute 18:21:16 sgallagh: thanks. 18:21:23 * gotmax also feels that they've repeated themself enough times ;) 18:21:49 OK, let's jump to another favorite topic. 18:21:50 #topic Next week's chair 18:22:11 I have some people coming over for the weekend, so I'm not sure if I'll be there. 18:22:25 ... next week. Somebody else has to volunteer. 18:22:53 <> 18:23:02 I am visiting a friend (not zbyszek) for the (extended) weekend, so I'll probably miss the meeting as well 18:23:07 Thanks for volunteering, smooge! 18:23:08 my calendar is double-booked next thursday started at 7AM 😭 18:23:22 put me down for Oct 5 but next week is gonna be tough 18:23:27 how about cancelling? 18:23:40 I can cover next week 18:23:41 if you are having me run the meeting.. its gone past desperate 18:24:11 #action sgallagh will chair next meeting 18:24:12 #topic Open Floor 18:24:15 it looks like you have 3 people out 18:24:22 what is the needed quorum? 18:24:33 ahoyhoy 18:24:36 Five 18:24:37 5. But I'll most likely be there. I just don't want to commit to chairing. 18:24:54 i had one thing: there's another Change that's at-risk which wasn't on the list (sorry) - https://fedoraproject.org/wiki/Changes/Fedora_Images_On_Azure 18:25:14 not sure if mhayden or davdunc are around? 18:25:22 mhayden is. 18:25:32 adamw: yes, that one will need to get pushed back as we don't have anything to make/ship those in a compatible way 18:25:33 I am pretty sure we are making the images... just need to publish them... 18:25:44 but yeah, there's a format thing too I guess 18:25:55 osbuild/osbuild-composer are rapidly adding btrfs and that was one of our last hurdles 18:25:59 there is also https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder , which clearly isn't happening 18:26:01 mhayden: I feel like it's a missed marketing opportunity not to offer Silverblue on Azure :) 18:26:13 I aam around too. 18:26:20 pbrobinson graciously offered to help with some the pungi/fedora/azure connection efforts 👏 18:27:28 so, i guess the question is, do we punt the azure change to f40 or try and get it done for f39? 18:27:58 if we haven't got any beta images out, how are we making sure the final images will not be... bad? 18:28:24 we have testing mhroncok_web 18:28:25 "The power of positive thinking"? 18:28:50 (forgive me if I misunderstood things and we can replace the images with fixed ones later) 18:29:37 I'm a afraid my positive thinking budget is depleted 18:30:05 i'd like to get Fedora on Azure ASAP, but this would need to be done manually with our current tooling 18:30:21 +1 and we are capable of doing it manually. 18:30:37 that's already possible 18:30:46 mhayden: it's basically a publish issue 18:30:57 davdunc was working on an ansible based generic publisher 18:31:05 so that we can scale to all the different platforms 18:31:08 yes. 18:31:15 if we're going to do this, i would want to somehow get the images tested in the Cloud matrix like we test on ec2 18:31:37 which would require us to be able to provide some kind of nice click-here-to-test link for Azure at the candidate compose stage, like we do for ec2 18:31:40 @adamw what do we need to do on cloud to get that done? 18:31:58 take a look at how ec2 is in https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test - i'd like azure to be like that 18:32:03 publish to the messege. 18:32:17 gotcha. 18:32:35 that table gets autogenerated based on a message that something publishes, we can do that or someone can just manually put the table in (for one release), but either way, something like that 18:32:53 obviously the table needs an Azure column, but i can do that easily if we're going ahead. 18:32:55 I am getting distracted and the puppy would probably like to go outside, sorry folks, but I'll leave now 18:32:56 we can do that. 18:33:09 the Azure list will be much simpler. 18:33:22 GCP too. 18:33:25 cool. i'll need to add support for it to wikitcms but it shouldn't be hard. 18:34:15 I think it's ok to manually get this in for f39, but we should force in a new cloud publishing setup tied to it. ;) (That would also be great to do, just shouldn't depend on this IMHO) 18:35:06 yea. I agree that should happen. I'll prioritize it over the next two weeks. 18:35:21 nirik: do you mean "shouldn't"? 18:35:33 yeah, sorry, mistyped. 18:35:34 ah. 18:35:48 so you'd rather we do it manually for f39 and hook up the whizzy bits for f30 18:35:50 f40... 18:36:02 yes. 18:36:04 I don't want to revamp everything between beta and final and rush to get it in... that can be seperate from azure publishing right? 18:36:10 sure 18:36:15 we can effectively split this change in two 18:36:34 that way we can get this out today and then we can be pushing nightlies for F40 18:36:40 changing the publishing would also change the other cloud's too, so it's a bigger/different change. 18:36:42 technically the infra side can be done whenever 18:36:48 right. 18:36:59 and as soon as we do that, we'll have nightlies rolling out again 18:37:03 steel reserve 18:37:05 but ideally no switchover happens near a release. ;) 18:37:10 oops, wrong channel 18:37:14 but we are *building* images in each compose already, right? just not publishing them? 18:37:19 yes 18:37:25 they've been building for a while now 18:37:29 so for any given compose we can manually publish the images and add them to the test matrix page 18:37:34 yes 18:37:37 okay, great. 18:37:42 yes 18:38:34 OK. Can somebody who has an understandingn of various pieces write up some #action items so we know what is expected to happen? 18:38:37 https://koji.fedoraproject.org/koji/taskinfo?taskID=106473542 for example 18:39:19 i can take an action item to make sure we have azure images linked from the final candidate test pages, and an azure column in the table 18:39:46 I can try... 18:39:46 somebody needs to also publish them manually, iiuc? 18:39:55