17:03:02 <zbyszek> #startmeeting FESCO (2023-09-21)
17:03:02 <zodbot> Meeting started Thu Sep 21 17:03:02 2023 UTC.
17:03:02 <zodbot> This meeting is logged and archived in a public location.
17:03:02 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:03:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:02 <zodbot> The meeting name has been set to 'fesco_(2023-09-21)'
17:03:02 <zbyszek> #meetingname fesco
17:03:02 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor, tstellar
17:03:02 <zodbot> The meeting name has been set to 'fesco'
17:03:02 <zodbot> 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 <zbyszek> #topic init process
17:03:09 <zbyszek> .hello2
17:03:10 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:03:12 <dcantrell> .hello2
17:03:16 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:03:17 <mhayden> .hello2
17:03:19 <zodbot> mhayden: mhayden 'Major Hayden' <mhayden@redhat.com>
17:03:36 <mhroncok_web> .hello churchyard
17:03:37 <zodbot> mhroncok_web: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:03:59 <nirik> morning
17:04:11 <zbyszek> Son_Goku: please reintroduce yourself FTR.
17:04:33 <zbyszek> Anyway, we have quorum.
17:04:41 <zbyszek> .fesco 3059
17:04:42 <zodbot> zbyszek: Issue #3059: F39 incomplete changes: 100% complete deadline - fesco - Pagure.io - https://pagure.io/fesco/issue/3059
17:05:38 <Son_Goku> .hello ngompa
17:05:38 <nirik> whats left here?
17:05:38 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:05:59 <zbyszek> TBB: I sent an email two weeks ago, and didn't get any reply.
17:07:27 <zbyszek> Also no movement in the bug (#2175941).
17:07:59 <nirik> 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 <zbyszek> OK, should we just bump this to F40? If somebody picks up maintainance, they'll probably do the change.
17:09:59 <nirik> yeah, seems reasonable
17:10:00 <dcantrell> I think that's reasonable
17:10:16 <nirik> or just drop and the can resubmit?
17:10:23 <nirik> they
17:10:31 <zbyszek> Yeah, that's probably better.
17:10:46 <zbyszek> Anyone against dropping?
17:11:21 <mhayden> no objection here
17:11:24 <Son_Goku> nope
17:11:29 <dcantrell> none from me
17:11:37 <zbyszek> #info ModernizeTBB is dropped.
17:11:39 <mhroncok_web> drop
17:11:46 <zbyszek> LegacyXorgDriverRemoval
17:11:59 <mhroncok_web> drop
17:12:02 <zbyszek> nirik: there was an ACTION for you to check check status.
17:12:05 <zbyszek> Any update on this?
17:12:25 <nirik> I mailed ajax... no reply
17:12:33 <Son_Goku> :(
17:12:55 <zbyszek> Anyone against dropping?
17:13:07 <Son_Goku> it's been three releases at this point, I guess
17:13:29 <dcantrell> I say drop it
17:13:37 <nirik> +1 to drop
17:13:41 <Son_Goku> +1 too
17:13:41 <zbyszek> #info LegacyXorgDriverRemoval is dropped.
17:13:59 <zbyszek> Bigger ESP: this was all handled, nothing to do.
17:14:10 <zbyszek> Enable bootupd for Fedora Silverblue & Kinoite: postponed by Owners to F40.
17:14:25 <zbyszek> Enable fwupd-refresh.timer by default on IoT, CoreOS & Server editions
17:14:33 <zbyszek> I'm not sure. Is this all done?
17:15:12 <Son_Goku> someone needs to merge it in fedora-release
17:15:38 <Son_Goku> https://src.fedoraproject.org/rpms/fedora-release/pull-request/279
17:15:59 <nirik> yeah, I can... we were in freeze.
17:16:13 <nirik> unless we don't want to after beta
17:16:21 <zbyszek> I think it's fine.
17:16:48 <zbyszek> #action nirik to look into the last pull request for Enable fwupd-refresh.timer by default on IoT, CoreOS & Server editions.
17:16:57 <zbyszek> #info https://src.fedoraproject.org/rpms/fedora-release/pull-request/279
17:17:04 <nirik> and there was a question outstanding? but I guess this is ok to merge and can be improved on
17:17:18 <zbyszek> Allow Removal of tzdata
17:17:29 <tstellar> .hello tstellar
17:17:30 <zodbot> tstellar: tstellar 'Tom Stellard' <tstellar@redhat.com>
17:17:36 <zbyszek> tstellar: hi
17:17:55 <tstellar> Sorry, I'm a little late.
17:18:20 <nirik> hey tstellar
17:18:46 <zbyszek> 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 <zbyszek> I think we should just let the Owner update the status as appropriate.
17:19:57 <zbyszek> At least the main part is done, not sure about the "packages which would be beneficial to be changed".
17:20:47 <nirik> +1
17:20:49 <mhroncok_web> I'd consider this done
17:20:57 <mhroncok_web> optiuonal is optional
17:21:02 <zbyszek> #info Allow Removal of tzdata is (in its basic part) done.
17:21:31 <mhroncok_web> correction: optiuonal is actually not optional, optional is optional
17:21:39 <dcantrell> heh
17:21:56 <zbyszek> The beaty of the inglish language is that you can insert a lot of letters without any effect.
17:22:00 <zbyszek> OK, so that's all on the list.
17:22:16 <mhroncok_web> \o/
17:22:37 <zbyszek> #topic #3063 Should we remove Systemd-boot support from Anaconda
17:22:42 <zbyszek> .fesco 3063
17:22:46 <zodbot> zbyszek: Issue #3063: Should we remove Systemd-boot support from Anaconda - fesco - Pagure.io - https://pagure.io/fesco/issue/3063
17:22:57 <zbyszek> (I now realize that I didn't set topic for the previous section. Too late to fix this now.)
17:24:01 <zbyszek> Note that there were replies in the ticket just now.
17:24:37 <zbyszek> > 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 <zbyszek> So I think we should close the ticket.
17:25:30 <nirik> +1 to close... seems being worked on
17:25:50 <zbyszek> +1 to close
17:26:18 <zbyszek> (please vote, this is a separate ticket so we should follow the procedure.)
17:26:25 <mhroncok_web> +1 to close
17:26:40 <dcantrell> +1
17:26:52 <mhroncok_web> brb
17:27:00 <Son_Goku> +1
17:27:16 <zbyszek> tstellar: ?
17:27:24 <zbyszek> mhayden: ?
17:27:30 <tstellar> +1
17:28:11 <zbyszek> #agreed REJECTED (0, 0, -6)
17:28:37 <zbyszek> #topic #3068 Ongoing problems with ELN contributions
17:28:46 * mhroncok_web is back
17:28:54 <zbyszek> .fesco 3068
17:28:55 <zodbot> zbyszek: Issue #3068: Ongoing problems with ELN contributions - fesco - Pagure.io - https://pagure.io/fesco/issue/3068
17:30:08 <nirik> so, sounds like some dialog at least
17:30:18 <nirik> is it enough to say things are going to be better?
17:30:30 <mhroncok_web> better how?
17:30:44 <tstellar> 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 <Son_Goku> yeah, I don't think so
17:30:50 <zbyszek> It's unfortunate that sgallagh is not here.
17:30:51 <nirik> more documented, clearer understanding?
17:31:10 <Son_Goku> lack of transparency in ELN development is an ongoing issue
17:31:12 <gotmax> 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 <nirik> we still need to know who is responsible for eln branches, and some other things
17:31:21 <zbyszek> tstellar: I don't think "alleged" is necessary. The examples in the ticket are rather obvious.
17:31:25 <gotmax> Son_Goku: Indeed
17:32:48 <tstellar> 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 <nirik> 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 <zbyszek> nirik: sounds good
17:33:59 <mhroncok_web> 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 <gotmax> tstellar: there was a discussion of general problems and then links to multiple problematic PRs
17:34:21 <gotmax> right
17:34:38 <mhroncok_web> 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 <nirik> well, sgallagh is one of the 'eln folks' and he replied a fair bit... is there others you expect to answer?
17:36:20 <mhroncok_web> 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 <tstellar> 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 <tstellar> Otherwise, the discussion becomes too fragmented and it makes it harder to come to conclusion.
17:38:01 <mhroncok_web> 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 <zbyszek> I think that gotmax didn't want to discuss specific ticket. The issue lists four points:
17:38:12 <zbyszek> 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 <zbyszek> 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 <zbyszek> Blah, this didn't format properly.
17:38:38 <zbyszek> 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 <gotmax> 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 <zbyszek> 2. The ways in which ELN diverges from Packaging Guidelines need to be documented so Fedora maintainers can properly review changes.
17:38:44 <zbyszek> 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 <zbyszek> 4. ELN developers are willing to respond to feedback and make changes.
17:39:36 <Son_Goku> and when ELN branches are created, they also need review to be shut down when they are not necessary
17:39:43 <gotmax> s/edit the PR/edit the ticket description/
17:40:04 <Son_Goku> ELN deviations are supposed to be minimal
17:40:14 <Son_Goku> and an effort should be made to reconcile them
17:40:22 <Son_Goku> I haven't seen a lot of that either
17:40:31 <dcantrell> in some cases they won't be able to
17:40:39 <dcantrell> 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 <Son_Goku> dcantrell: no
17:40:48 <Son_Goku> that's not the point of ELN
17:40:49 <dcantrell> 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 <dcantrell> I think zbyszek's point
17:41:03 <dcantrell> #1 is key here
17:41:14 <dcantrell> there's not enough documentation indicating the responsible party and who handles what
17:41:29 <nirik> All those things are 'get this process documented, approved and everyone agreeing to follow it' basically right?
17:41:37 <dcantrell> yes
17:41:43 <zbyszek> yeah, I think that'd help a lot.
17:41:49 <Son_Goku> 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 <gotmax> dcantrell: that's my point, but yes
17:42:04 <Son_Goku> Fedora maintainers can't do anything with ELN stuff
17:42:08 <dcantrell> 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 <gotmax> nirik: that and the issue about provenpackager privs
17:42:30 <zbyszek> (I was quoting gotmax from the ticket. I should have made that clearer.)
17:42:41 <dcantrell> provenpackager privs wrt ELN should be involved in this as-yet-to-be-written documentation
17:43:24 <Son_Goku> dcantrell: we also shouldn't allow RHEL tech debt to pile up in Fedora either
17:43:29 <Son_Goku> that can create its own problems
17:43:32 <gotmax> 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 <gotmax> that's been incorrectly implied by multiple people
17:43:52 <dcantrell> gotmax: agreed, it just seems we're all not quite aligned on the same page at the moment
17:43:54 <nirik> yeah, +1 gotmax
17:44:05 <mhroncok_web> "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 <Son_Goku> honestly, I'm starting to feel like there is forking going on
17:44:09 <dcantrell> Son_Goku: I'm not advocating for that
17:44:24 <mhroncok_web> and the response by eln is pretty much "your standards do no apply to us"
17:44:44 <Son_Goku> ^ this is something I've gotten in private a fair number of times
17:45:12 <Son_Goku> offhand, I only have one good interaction around reconciling RHEL and Fedora in ELN
17:45:13 <dcantrell> 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 <nirik> IMHO it should be like epel... "all fedora guidelines, etc, with these small list of exceptions and reasons for them..."
17:45:33 <zbyszek> nirik: +1
17:45:42 <Son_Goku> dcantrell: that would be appropriate if they're not willing to follow the rules of being part of Fedora
17:45:56 <Son_Goku> I would be happier if ELN had an EPEL-like setup
17:46:14 <Son_Goku> wrt rules, policy management, and community support
17:46:45 <Son_Goku> 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 <dcantrell> nirik: +1
17:46:53 <Son_Goku> that was something I was comfortable with
17:46:57 <Son_Goku> what we're doing now, I just don't know
17:47:02 <dcantrell> ah yes, "just the build flags"  :)
17:47:18 <sgallagh> I'm here, sorry
17:47:19 <dcantrell> so yeah, some boundaries and policy documentation
17:47:21 <sgallagh> Did we change rooms?
17:47:32 <Son_Goku> no, this has been the room for a while
17:47:44 <Son_Goku> we'll hopefully switch back to #fedora-meeting once we switch back to Tuesday
17:47:47 <nirik> sgallagh: welcome. just in time for eln discussing.
17:47:54 <zbyszek> sgallagh: since we moved the meeting day and #fedora-meeting was busy.
17:48:04 <sgallagh> Is there a quick catch-up link?
17:48:54 <mhroncok_web> https://paste.centos.org/view/364d755f
17:48:57 <sgallagh> Thank you
17:49:00 <nirik> https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2023-09-21/fesco.2023-09-21-17.03.log.txt
17:49:17 <Son_Goku> huh TIL
17:49:21 <mhroncok_web> nice
17:50:40 <sgallagh> Still reading, just a moment
17:52:38 <nirik> 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 <sgallagh> OK, let me start replying.
17:53:06 <Son_Goku> nirik: we're almost there I hear :)
17:53:26 <nirik> getting close. ;)
17:53:30 <sgallagh> First: Regarding packaging deltas from Fedora:
17:53:54 <dcantrell> (I've got a meeting starting at the next hour, but I'll stay in here too)
17:54:13 <sgallagh> 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 <sgallagh> 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 <sgallagh> 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 <sgallagh> That was always the policy, but this was poorly communicated by me to the team.
17:56:45 <tstellar> Were these exceptions agreed upon in the past but just never written down?
17:56:50 <sgallagh> Yes
17:57:20 <zbyszek> sgallagh: What about other dependencies (non-test)? I think those would also be dropped in ELN.
17:57:26 <mhroncok_web> unwanted generally or actaully marked as such in the content resolver?
17:57:43 <nirik> FYI, there are 17 eln branches for rpms.
17:57:56 <sgallagh> mhroncok_web: If those two lists are not the same, a mistake has been made somewhere.
17:58:11 <nirik> (and 4 modules)
17:58:22 <sgallagh> The modules are not in use.
17:58:34 <nirik> yeah. just listing for completeness
17:58:39 <gotmax> that was my implicit understanding, but it seems some of these PRs are going "above and beyond" that
17:58:42 <sgallagh> 17 is actually a few more than I expected. That likely means someone branched and didn't tell us.
17:58:55 <sgallagh> Which means our automation is probably stepping on them
17:59:08 <zbyszek> 17 doesn't seem like a big problem.
17:59:15 <gotmax> 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 <gotmax> zbyszek: it's a problem if nobody is responsible for maintaining them
17:59:45 <sgallagh> 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 <zbyszek> sgallagh: ack
18:00:41 <nirik> well, also: where do people file bugs on them? who handles those bugs?
18:00:51 <sgallagh> 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 <sgallagh> This has long been a problem, even before ELN
18:01:51 <mhroncok_web> 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 <dcantrell> 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 <sgallagh> 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 <Son_Goku> welp
18:02:19 <dcantrell> sgallagh: thank you, I don't get much email  :)
18:02:25 <nirik> ha
18:02:37 <zbyszek> dcantrell++
18:02:37 <zodbot> zbyszek: Karma for dcantrell changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
18:03:01 <zbyszek> 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 <nirik> if there are exceptions to the exceptions, perhaps they should be approved by fesco ? if they are rare...
18:03:38 <sgallagh> 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 <Son_Goku> I'm wondering if we need some kind of exception review
18:04:35 <dcantrell> 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 <Son_Goku> *regular exception review
18:04:46 <gotmax> well, we're being given low quality patches and the being expected to maintain them ourselves
18:04:57 <mhroncok_web> gotmax++
18:05:03 <sgallagh> mhroncok_web: Sorry, just saw your other Q: yes, something like libb2 should indeed be added to the "unwanted" list.
18:05:07 <Son_Goku> gotmax++
18:05:07 <zodbot> Son_Goku: Karma for gotmax23 changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
18:05:47 <sgallagh> zbyszek: Yes, I'll take that action
18:06:13 <zbyszek> #action sgallagh to preparate an update for the ELN documentation
18:06:19 <zbyszek> sgallagh++, thanks
18:06:26 <zbyszek> sgallagh++
18:06:26 <zodbot> zbyszek: Karma for sgallagh changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
18:06:48 <sgallagh> 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 <mhroncok_web> 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 <sgallagh> (I really hate criticizing in public, but I feel like I have to address that elephant)
18:07:31 <gotmax> again, we're not asking everyone to be subject-matter experts. we're asking them to address our feedback.
18:07:45 <Son_Goku> and importantly, not dismiss them as invalid
18:07:47 <sgallagh> gotmax: I think we're agreeing here.
18:08:03 <zbyszek> mhroncok_web: If compliance with FPG will be clarified in the rules, then hopefully this stop being an issue.
18:08:12 <mhroncok_web> hopefully
18:08:19 <zbyszek> (Not not responding to feedback, but questions about what applies.)
18:08:38 <zbyszek> (OK, actually I hope both ;))
18:09:04 <sgallagh> I *really really* want to get to a point where SMEs actually *are* the people maintaining things for ELN.
18:09:10 <sgallagh> But it's been an uphill battle.
18:09:21 * gotmax does not know what SME is
18:09:25 <Son_Goku> subject matter expert
18:09:28 <sgallagh> Subject Matter Experts
18:09:36 <zbyszek> I think we can stop beating this horse, it seems very dead at this point.
18:09:39 <Son_Goku> RH is full of TLAs :)
18:09:57 <Son_Goku> and TLIs
18:10:21 <mhroncok_web> zbyszek++
18:10:22 <Son_Goku> zbyszek: I dunno, I hear the horse groaning...
18:10:26 <Son_Goku> :)
18:10:30 <sgallagh> I have a small bit more to add, if that is alright?
18:10:36 <zbyszek> sgallagh: oh, please go.
18:10:39 <Son_Goku> go for it
18:10:40 <dcantrell> the horse can't take it!
18:10:55 <gotmax> 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 <dcantrell> j/k
18:10:59 * dcantrell hands sgallagh the bat
18:11:20 <zbyszek> Recently I learned that horses actually have about ~15 HP, so they can take much more than one would expect.
18:12:59 <sgallagh> 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 <sgallagh> But these are neither communicated to Fedora at large nor, frankly, really anyone else's problem.
18:13:29 <sgallagh> "A lack of planning on my part, etc. etc."
18:14:03 <Son_Goku> sgallagh: I think it would be useful to have the schedule be less obscure
18:14:14 <sgallagh> 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 <Son_Goku> it also allows all the rest of us to be prepared for when the RHEL beast awakens
18:14:38 <sgallagh> Son_Goku: I don't disagree, and I've been trying to announce as much as I'm allowed to.
18:14:53 <sgallagh> Though I'll admit is has been a while since my last attempt at such
18:14:59 <gotmax> you sent out that detailed email about c10s branching last month FWIW
18:15:15 <sgallagh> That was a couple months ago, and it's out of date :-(
18:15:31 <dcantrell> 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 <dcantrell> rather than pushing as hard as you can in Fedora because of some internal deadline
18:15:54 <sgallagh> We're on a day-by-day slip regarding our big CentOS Stream 10 import... since the beginning of August
18:16:31 <sgallagh> dcantrell: Agreed, in theory. Practice gets harder.
18:17:01 <sgallagh> 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 <dcantrell> 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 <gotmax> 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 <dcantrell> sgallagh: and isn't that the kind of thing we wanted ELN to give us a heads up for anyway?
18:17:40 <sgallagh> FWIW, I agree. I'm not making excuses; I'm just trying to explain how we got here.
18:18:49 <sgallagh> We're playing Whack-a-Mole with blockers to getting CS10 started, and that can wear on anyone over time.
18:19:17 <dcantrell> yeah, no one likes the blocker bug treadmill
18:19:59 <mhroncok_web> how's the horse doing?
18:20:07 <sgallagh> Anyway, I hope this has provided at least a little bit of context.
18:20:30 <Son_Goku> mhroncok_web: still groaning!
18:20:31 <sgallagh> Clearly, my team and I need to work on a few things.
18:20:56 <sgallagh> I don't have anything more to add right this minute
18:21:16 <zbyszek> sgallagh: thanks.
18:21:23 * gotmax also feels that they've repeated themself enough times ;)
18:21:49 <zbyszek> OK, let's jump to another favorite topic.
18:21:50 <zbyszek> #topic Next week's chair
18:22:11 <zbyszek> I have some people coming over for the weekend, so I'm not sure if I'll be there.
18:22:25 <zbyszek> ... next week. Somebody else has to volunteer.
18:22:53 <smooge> <<crickets>>
18:23:02 <mhroncok_web> I am visiting a friend (not zbyszek) for the (extended) weekend, so I'll probably miss the meeting as well
18:23:07 <sgallagh> Thanks for volunteering, smooge!
18:23:08 <mhayden> my calendar is double-booked next thursday started at 7AM 😭
18:23:22 <mhayden> put me down for Oct 5 but next week is gonna be tough
18:23:27 <smooge> how about cancelling?
18:23:40 <sgallagh> I can cover next week
18:23:41 <smooge> if you are having me run the meeting.. its gone past desperate
18:24:11 <zbyszek> #action sgallagh will chair next meeting
18:24:12 <zbyszek> #topic Open Floor
18:24:15 <smooge> it looks like you have 3 people out
18:24:22 <smooge> what is the needed quorum?
18:24:33 <adamw> ahoyhoy
18:24:36 <sgallagh> Five
18:24:37 <zbyszek> 5. But I'll most likely be there. I just don't want to commit to chairing.
18:24:54 <adamw> 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 <adamw> not sure if mhayden or davdunc are around?
18:25:22 <zbyszek> mhayden is.
18:25:32 <mhayden> 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 <nirik> I am pretty sure we are making the images... just need to publish them...
18:25:44 <nirik> but yeah, there's a format thing too I guess
18:25:55 <mhayden> osbuild/osbuild-composer are rapidly adding btrfs and that was one of our last hurdles
18:25:59 <adamw> there is also https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder , which clearly isn't happening
18:26:01 <sgallagh> mhayden: I feel like it's a missed marketing opportunity not to offer Silverblue on Azure :)
18:26:13 <davdunc> I aam around too.
18:26:20 <mhayden> pbrobinson graciously offered to help with some the pungi/fedora/azure connection efforts 👏
18:27:28 <adamw> 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 <mhroncok_web> if we haven't got any beta images out, how are we making sure the final images will not be... bad?
18:28:24 <davdunc> we have testing mhroncok_web
18:28:25 <sgallagh> "The power of positive thinking"?
18:28:50 <mhroncok_web> (forgive me if I misunderstood things and we can replace the images with fixed ones later)
18:29:37 <mhroncok_web> I'm a afraid my positive thinking budget is depleted
18:30:05 <mhayden> i'd like to get Fedora on Azure ASAP, but this would need to be done manually with our current tooling
18:30:21 <davdunc> +1 and we are capable of doing it manually.
18:30:37 <davdunc> that's already possible
18:30:46 <Son_Goku> mhayden: it's basically a publish issue
18:30:57 <Son_Goku> davdunc was working on an ansible based generic publisher
18:31:05 <Son_Goku> so that we can scale to all the different platforms
18:31:08 <davdunc> yes.
18:31:15 <adamw> 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 <adamw> 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 <davdunc> @adamw what do we need to do on cloud to get that done?
18:31:58 <adamw> 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 <davdunc> publish to the messege.
18:32:17 <davdunc> gotcha.
18:32:35 <adamw> 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 <adamw> obviously the table needs an Azure column, but i can do that easily if we're going ahead.
18:32:55 <mhroncok_web> I am getting distracted and the puppy would probably like to go outside, sorry folks, but I'll leave now
18:32:56 <davdunc> we can do that.
18:33:09 <davdunc> the Azure list will be much simpler.
18:33:22 <davdunc> GCP too.
18:33:25 <adamw> cool. i'll need to add support for it to wikitcms but it shouldn't be hard.
18:34:15 <nirik> 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 <davdunc> yea. I agree that should happen. I'll prioritize it over the next two weeks.
18:35:21 <adamw> nirik: do you mean "shouldn't"?
18:35:33 <nirik> yeah, sorry, mistyped.
18:35:34 <davdunc> ah.
18:35:48 <adamw> so you'd rather we do it manually for f39 and hook up the whizzy bits for f30
18:35:50 <adamw> f40...
18:36:02 <davdunc> yes.
18:36:04 <nirik> 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 <Son_Goku> sure
18:36:15 <Son_Goku> we can effectively split this change in two
18:36:34 <davdunc> that way we can get this out today and then we can be pushing nightlies for F40
18:36:40 <nirik> changing the publishing would also change the other cloud's too, so it's a bigger/different change.
18:36:42 <Son_Goku> technically the infra side can be done whenever
18:36:48 <nirik> right.
18:36:59 <Son_Goku> and as soon as we do that, we'll have nightlies rolling out again
18:37:03 <mhayden> steel reserve
18:37:05 <nirik> but ideally no switchover happens near a release. ;)
18:37:10 <mhayden> oops, wrong channel
18:37:14 <adamw> but we are *building* images in each compose already, right? just not publishing them?
18:37:19 <Son_Goku> yes
18:37:25 <Son_Goku> they've been building for a while now
18:37:29 <adamw> so for any given compose we can manually publish the images and add them to the test matrix page
18:37:34 <Son_Goku> yes
18:37:37 <adamw> okay, great.
18:37:42 <nirik> yes
18:38:34 <zbyszek> 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 <nirik> https://koji.fedoraproject.org/koji/taskinfo?taskID=106473542 for example
18:39:19 <adamw> 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 <nirik> I can try...
18:39:46 <zbyszek> somebody needs to also publish them manually, iiuc?
18:39:55 <Son_Goku> yes
18:39:56 <davdunc> I can take an action to publish them
18:40:03 <nirik> #action davdunc and/or mhayden to publish azure images
18:40:09 <zbyszek> #action adamw to make sure we have azure images linked from the final candidate test pages, and an azure column in the table
18:40:36 <zbyszek> OK, so I think we're good here.
18:40:40 <adamw> awesome
18:40:52 <zbyszek> Thank you all.
18:40:53 <adamw> so, there's also https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder
18:40:55 <zbyszek> adamw++
18:40:57 <zbyszek> mhayden++
18:40:57 <zodbot> zbyszek: Karma for mhayden changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
18:41:01 <zbyszek> davdunc++
18:41:01 <zodbot> zbyszek: Karma for davdunc changed to 1 (for the release cycle f39):  https://badges.fedoraproject.org/tags/cookie/any
18:41:04 <mhayden> adamw++
18:41:24 <zbyszek> #proposal: FedoraWorkstationImageBuilder is postponed until F40.
18:41:24 <mhayden> always a good time to give adamw kudos 🫂
18:41:29 <nirik> +1
18:41:39 <adamw> that one i think we should defer at this point...even if the productmd change gets merged tomorrow i don't think we should try and get it into f39 at this point just in case it causes unexpected compose issues
18:41:44 <mhayden> +1 here as well
18:42:01 <zbyszek> s/postponed/deferred/
18:42:08 <zbyszek> s/until/to/
18:42:17 <sgallagh> Yeah, post-Beta is too late for this
18:42:48 <zbyszek> sgallagh, dcantrell, Son_Goku: vote?
18:43:01 <dcantrell> +1
18:43:06 <dcantrell> sorry, thought I had pressed Enter
18:43:06 <zbyszek> tstellar: vote?
18:43:17 <Son_Goku> +1
18:44:09 <zbyszek> I'll count sgallagh as +1.
18:44:10 <zbyszek> #agree FedoraWorkstationImageBuilder is deferred to F40 (+6, 0, 0)
18:44:31 <zbyszek> #action zbyszek to adjust the Change page.
18:44:47 <zbyszek> We're at 105 minutes.
18:44:52 <zbyszek> Anything else?
18:44:55 <adamw> there are a few more now i look through the list
18:44:58 <adamw> but i'll put them in the ticket
18:45:06 <zbyszek> adamw: thank you.
18:45:06 <adamw> if folks could vote there or something, that'd be great
18:45:42 <nirik> thanks
18:45:53 <zbyszek> Thank you all for coming.
18:45:54 <zbyszek> #endmeeting