2025-02-19 18:00:45 <@tdawson:fedora.im> !startmeeting EPEL (2025-02-19)
2025-02-19 18:01:51 <@tdawson:fedora.im> !topic aloha
2025-02-19 18:01:51 <@tdawson:fedora.im> !meetingname epel
2025-02-19 18:01:51 <@meetbot:fedora.im> Meeting started at 2025-02-19 18:00:45 UTC
2025-02-19 18:01:51 <@meetbot:fedora.im> The Meeting name is 'EPEL (2025-02-19)'
2025-02-19 18:01:52 <@meetbot:fedora.im> The Meeting Name is now epel
2025-02-19 18:02:08 <@dherrera:fedora.im> !hi
2025-02-19 18:02:09 <@zodbot:fedora.im> Diego Herrera (dherrera) - he / him / his
2025-02-19 18:02:12 <@tdawson:fedora.im> !meetingname epel
2025-02-19 18:02:12 <@tdawson:fedora.im> !topic aloha
2025-02-19 18:02:13 <@carlwgeorge:fedora.im> !hi
2025-02-19 18:02:14 <@meetbot:fedora.im> The Meeting Name is now epel
2025-02-19 18:02:16 <@zodbot:fedora.im> Carl George (carlwgeorge) - he / him / his
2025-02-19 18:02:20 <@nirik:matrix.scrye.com> morning
2025-02-19 18:02:44 <@tdawson:fedora.im> That was wierd ... it took a minute for my first command to go through ... seems to be ok now though.
2025-02-19 18:03:17 <@tdawson:fedora.im> Morning nirik 
2025-02-19 18:03:26 <@tdawson:fedora.im> Hi Diego Herrera and Carl George 
2025-02-19 18:03:29 <@davide:cavalca.name> !hi
2025-02-19 18:03:31 <@zodbot:fedora.im> Davide Cavalca (dcavalca) - he / him / his
2025-02-19 18:03:38 <@tdawson:fedora.im> Hi Davide Cavalca 
2025-02-19 18:04:30 <@nhanlon:beeper.com> !hi
2025-02-19 18:04:32 <@zodbot:fedora.im> Neil Hanlon (neil) - he / him / his
2025-02-19 18:05:44 <@tdawson:fedora.im> Hi Neil Hanlon 
2025-02-19 18:05:57 <@tdawson:fedora.im> !topic EPEL Issues https://pagure.io/epel/issues
2025-02-19 18:05:57 <@tdawson:fedora.im> !link https://pagure.io/epel/issues?tags=meeting&status=Open
2025-02-19 18:06:25 <@tdawson:fedora.im> We have several items today, I'm going to start from oldest to newest.
2025-02-19 18:06:36 <@tdawson:fedora.im> !epel 304
2025-02-19 18:06:38 <@zodbot:fedora.im> 
2025-02-19 18:06:38 <@zodbot:fedora.im> ● **Assignee:** dherrera
2025-02-19 18:06:38 <@zodbot:fedora.im> ● **Last Updated:** 10 hours ago
2025-02-19 18:06:38 <@zodbot:fedora.im> ● **Opened:** 3 months ago by carlwgeorge
2025-02-19 18:06:38 <@zodbot:fedora.im> **epel #304** (https://pagure.io/epel/issue/304):**EPEL 10.0 mass branching**
2025-02-19 18:07:11 <@tdawson:fedora.im> Diego Herrera: Carl George How is that going?  ... or actually, can you give a quick report.
2025-02-19 18:08:36 <@carlwgeorge:fedora.im> !link https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/7HPSCQDLFOZWNF4WACDDMULJCXZDVJRP/
2025-02-19 18:08:57 <@dherrera:fedora.im> In short, everything went well :) we were able to do all the branching and tags without problems ^^ so people should be able to push things to epel10 and epel10.0 branch
2025-02-19 18:09:47 <@dherrera:fedora.im> the only issue that we've found is that there is a problem with fedpkg that sends multiple tickets if you try to create an epel10.0 branch (as mentioned on the email thread)
2025-02-19 18:10:26 <@rcallicotte:fedora.im> !hi
2025-02-19 18:10:28 <@zodbot:fedora.im> Robby Callicotte (rcallicotte) - he / him / his
2025-02-19 18:10:38 <@tdawson:fedora.im> Hi Robby Callicotte 
2025-02-19 18:11:08 <@tdawson:fedora.im> Diego Herrera: That sounds great.  I look forward to my first EPEL 10.0 update  (yep, I already found one)
2025-02-19 18:11:17 <@dherrera:fedora.im> this should get fixed on fedpkg, but a workaround is to use the --no-auto-module flag as mentioned by fabio on the thread
2025-02-19 18:11:29 <@carlwgeorge:fedora.im> i've sent in a pr to fix fedpkg, but have no idea how long that will take to land in a released fedpkg and most users get upgraded to it
2025-02-19 18:11:44 <@davide:cavalca.name> does this mean we should use `epel10.1-build` as the base sidetag for epel10 builds now?
2025-02-19 18:12:12 <@tdawson:fedora.im> I believe it does.
2025-02-19 18:12:20 <@carlwgeorge:fedora.im> yes, that's what the epel10-candidate target uses now
2025-02-19 18:13:03 <@davide:cavalca.name> thanks, not sure how feasible, but it'd be nice to make `epel10-build` always resolve to the latest one, so one doesn't have to remember the point release when doing epel10
2025-02-19 18:13:29 <@carlwgeorge:fedora.im> this is what we planned for, `fedpkg build` on the epel10 branch uses the epel10-candidate tag, and that will get updated every six months through each epel10.x-build tag
2025-02-19 18:14:28 <@carlwgeorge:fedora.im> the idea is maintainers won't have to remember the point release, they just build from the epel10 branch.  what is the use case you had in mind?
2025-02-19 18:14:48 <@davide:cavalca.name> `fedpkg request-side-tag --base-tag`
2025-02-19 18:14:55 <@davide:cavalca.name> right now you have to give it the point release tag
2025-02-19 18:15:32 <@davide:cavalca.name> ```
2025-02-19 18:15:32 <@davide:cavalca.name> ```
2025-02-19 18:15:32 <@davide:cavalca.name> Could not execute request_side_tag: No such tagInfo: 'epel10-build'
2025-02-19 18:15:32 <@davide:cavalca.name> $ fedpkg request-side-tag --base-tag epel10-build
2025-02-19 18:15:33 <@carlwgeorge:fedora.im> i believe if you run `fedpkg request-side-tag` from the epel10 branch it resolves it for you
2025-02-19 18:15:43 <@davide:cavalca.name> oh, til
2025-02-19 18:16:07 <@davide:cavalca.name> yup that works just fine
2025-02-19 18:16:11 <@davide:cavalca.name> thanks!
2025-02-19 18:16:24 <@carlwgeorge:fedora.im> yeah, `--base-tag` is optional, and the docs describe using it without it https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/#_how_does_gating_multi_builds_updates_work
2025-02-19 18:17:22 <@carlwgeorge:fedora.im> i think that's it for the mass branching unless Diego Herrera has anything else, we should move on
2025-02-19 18:18:21 <@tdawson:fedora.im> Thank you Diego Herrera Carl George and everyone else who worked on the mass branching.  I, and I believe all the EPEL community, appreciate it.
2025-02-19 18:18:30 <@dherrera:fedora.im> no, I think that's all for now :)
2025-02-19 18:18:59 <@carlwgeorge:fedora.im> huge thanks to nirik and jnsamyak for all their help
2025-02-19 18:19:20 <@tdawson:fedora.im> Moving on to the next ticket
2025-02-19 18:19:36 <@tdawson:fedora.im> !epel 313
2025-02-19 18:19:37 <@zodbot:fedora.im> ● **Last Updated:** a day ago
2025-02-19 18:19:37 <@zodbot:fedora.im> **epel #313** (https://pagure.io/epel/issue/313):**EPEL 10 dnf variables problems**
2025-02-19 18:19:37 <@zodbot:fedora.im> 
2025-02-19 18:19:37 <@zodbot:fedora.im> ● **Opened:** 4 weeks ago by carlwgeorge
2025-02-19 18:19:37 <@zodbot:fedora.im> ● **Assignee:** carlwgeorge
2025-02-19 18:20:02 <@tdawson:fedora.im> Carl George: Do you mind giving a brief status.
2025-02-19 18:21:00 <@tdawson:fedora.im> nirik: Sounds good, I'll make sure we have enough time for it.
2025-02-19 18:21:44 <@carlwgeorge:fedora.im> i don't remember if i mentioned it last week, but the rhel maintainers of dnf/libdnf want more time to test the change, so they asked for it to be filed as an exception for 10.0 ga, which i have done.  now we are in a holding pattern until that moves forward.  we did get the necessary provides into redhat-release, so once dnf/libdnf get the backports it should start working as expected.
2025-02-19 18:22:44 <@tdawson:fedora.im> You had mentioned that things were moving forward.  I'm not sure about the extension.
2025-02-19 18:23:11 <@tdawson:fedora.im> But thank you for continuing to work on that.  It's really going to help.
2025-02-19 18:23:25 <@tdawson:fedora.im> Do you want to add anything else before we move on?
2025-02-19 18:23:47 <@carlwgeorge:fedora.im> nope, that's it
2025-02-19 18:24:03 <@tdawson:fedora.im> OK, moving on to a ticket that might take more time.
2025-02-19 18:24:17 <@tdawson:fedora.im> !epel 316
2025-02-19 18:24:18 <@zodbot:fedora.im> ● **Assignee:** Not Assigned
2025-02-19 18:24:18 <@zodbot:fedora.im> ● **Last Updated:** 3 hours ago
2025-02-19 18:24:18 <@zodbot:fedora.im> **epel #316** (https://pagure.io/epel/issue/316):**EPEL Updates Policy, minor branches, and source-only Rust packages**
2025-02-19 18:24:18 <@zodbot:fedora.im> 
2025-02-19 18:24:18 <@zodbot:fedora.im> ● **Opened:** 5 hours ago by decathorpe
2025-02-19 18:25:19 <@nirik:matrix.scrye.com> oh yeah, this was one of the things I was gonna mention. I thought we decided fedora exceptions apply to epel (along with fedora packaging guidelines unless overridden)
2025-02-19 18:25:44 <@tdawson:fedora.im> Yes, that is what I though we'd already decided, a year or two ago.
2025-02-19 18:25:59 <@carlwgeorge:fedora.im> yeah that's our general rule, but it doesn't hurt to be explicit when there is doubt
2025-02-19 18:26:03 <@nhanlon:beeper.com> I recall the same
2025-02-19 18:26:04 <@conan_kudo:matrix.org> !hi
2025-02-19 18:26:05 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2025-02-19 18:26:26 <@conan_kudo:matrix.org> Yeah, I'm fairly certain that's the rule, we can just quickly agree and record that in the ticket.
2025-02-19 18:26:28 <@music:fedora.im> Related, https://pagure.io/epel/issue/317, where I just wrote “If the EPEL steering committee takes the reasonable position that Fedora exceptions apply to EPEL by default, then please consider this issue to be a request for documentation of that position.”
2025-02-19 18:26:57 <@carlwgeorge:fedora.im> i do think we should consider not matching the fedora list exactly though
2025-02-19 18:26:59 <@nirik:matrix.scrye.com> yeah, we should document
2025-02-19 18:27:19 <@carlwgeorge:fedora.im> like, the list will probably be mostly the same, but i'm not convinced that each case will make sense for both
2025-02-19 18:27:32 <@conan_kudo:matrix.org> the exception list follows the same policy recommendations we would require anyway
2025-02-19 18:27:37 <@conan_kudo:matrix.org> so I would _hope_ the list is the same
2025-02-19 18:27:44 <@tdawson:fedora.im> Well yes, not exactly, that was where we would have our own exceptions (or additions) list.
2025-02-19 18:27:45 <@carlwgeorge:fedora.im> kde already doesn't have the same policy between fedora and epel
2025-02-19 18:27:55 <@conan_kudo:matrix.org> it doesn't?
2025-02-19 18:28:36 <@carlwgeorge:fedora.im> kde 6 isn't coming to epel8/9 anytime soon, last i checked
2025-02-19 18:28:42 <@jonathanspw:fedora.im> !hi
2025-02-19 18:28:43 <@zodbot:fedora.im> Jonathan Wright (jonathanspw)
2025-02-19 18:28:44 <@conan_kudo:matrix.org> that's also true in fedora
2025-02-19 18:28:50 <@conan_kudo:matrix.org> we didn't upgrade kde6 in f39
2025-02-19 18:28:56 <@conan_kudo:matrix.org> we didn't upgrade to kde6 in f39
2025-02-19 18:29:01 <@conan_kudo:matrix.org> that is not a policy difference
2025-02-19 18:29:23 <@tdawson:fedora.im> The fedora exceptions for KDE doesn't say they "HAVE" to update all the releases, I believe it says they "CAN" update the releases.
2025-02-19 18:29:27 <@nirik:matrix.scrye.com> I'm hard pressed to think of an example where they would differ...
2025-02-19 18:29:38 <@conan_kudo:matrix.org> I don't think there _is_ a reason for it to differ.
2025-02-19 18:29:48 <@conan_kudo:matrix.org> The difference is we yell more when people break the rules :P
2025-02-19 18:30:06 <@nirik:matrix.scrye.com> (of course some don't apply... like the kernel)
2025-02-19 18:30:13 <@conan_kudo:matrix.org> The exception has never included major versions where all the ABIs completely break.
2025-02-19 18:30:35 <@conan_kudo:matrix.org> that's why we didn't even _contemplate_ KDE Plasma 6 for F39 _or_ EPEL9
2025-02-19 18:30:36 <@carlwgeorge:fedora.im> yeah, enterprise users are more sensitive to changes, so we should be more careful
2025-02-19 18:30:59 <@carlwgeorge:fedora.im> the difference is f39 is already eol, epel9 is around for many years to come
2025-02-19 18:31:07 <@carlwgeorge:fedora.im> it's not quite the same thing
2025-02-19 18:31:12 <@conan_kudo:matrix.org> sure, but when Plasma 6 was first released F39 was not EOL
2025-02-19 18:31:20 <@nirik:matrix.scrye.com> I think if we just document 'fedora exceptions apply, if you have any questions, please talk to us'
2025-02-19 18:31:28 <@conan_kudo:matrix.org> yeah, that's reasonable
2025-02-19 18:31:36 <@dherrera:fedora.im> that's reasonable
2025-02-19 18:31:43 <@conan_kudo:matrix.org> there's a page to link to from the fesco side IIRC
2025-02-19 18:31:51 <@nirik:matrix.scrye.com> see: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions
2025-02-19 18:31:52 <@conan_kudo:matrix.org> so we should ensure that's referenced
2025-02-19 18:32:20 <@smooge:fedora.im> let's let music finish typing please
2025-02-19 18:32:42 <@carlwgeorge:fedora.im> i've looked through some of the fesco tickets for these exceptions, and not all of them are strong cases for epel (but were strong enough for fedora)
2025-02-19 18:32:43 <@music:fedora.im> In general, I would point out that an exception to do breaking updates isn’t a get-out-of-jail free card to break things willy-nilly – I would expect people to still do due diligence for potential impact on other packages.
2025-02-19 18:33:18 <@carlwgeorge:fedora.im> 
2025-02-19 18:33:18 <@carlwgeorge:fedora.im> one example, zathura:
2025-02-19 18:33:18 <@carlwgeorge:fedora.im> > Zathura users tend to want the latest version - I often get bugs asking for an update.
2025-02-19 18:33:55 <@conan_kudo:matrix.org> the document reader app?
2025-02-19 18:34:42 <@conan_kudo:matrix.org> I'm not sure we'd block that either
2025-02-19 18:35:07 <@carlwgeorge:fedora.im> my point is i don't think all of these should be automatic for epel, and some don't apply at all like the kernel
2025-02-19 18:35:41 <@carlwgeorge:fedora.im> is there any harm in having a separate list, and then we review the exceptions case by case?  being on the fedora exception list is a great argument in favor of it, but i don't think it should be automatic.
2025-02-19 18:35:43 <@nirik:matrix.scrye.com> I'm not sure thats really happening anymore. ;)
2025-02-19 18:35:57 <@nirik:matrix.scrye.com> I don't think fesco has ever gone back to re-evaluate old exceptions
2025-02-19 18:36:47 <@conan_kudo:matrix.org> I think it's not entirely useful extra work to do that each time a fesco exception is added
2025-02-19 18:37:06 <@conan_kudo:matrix.org> we can always ask fesco to consider us as part of their permanent exception criteria (if they aren't already doing that)
2025-02-19 18:37:06 <@carlwgeorge:fedora.im> it's not every time, as not all the packages are even in epel
2025-02-19 18:37:42 <@carlwgeorge:fedora.im> this is only the second time it's come up that i can remember, first was certbot where we said the fedora policy applied, now it's rust devel packages
2025-02-19 18:37:55 <@tdawson:fedora.im> Actually, third
2025-02-19 18:38:07 <@carlwgeorge:fedora.im> what was the other one i'm forgetting?
2025-02-19 18:38:16 <@tdawson:fedora.im> !epel 317
2025-02-19 18:38:17 <@zodbot:fedora.im> ● **Opened:** 3 hours ago by music
2025-02-19 18:38:17 <@zodbot:fedora.im> **epel #317** (https://pagure.io/epel/issue/317):**Proposed update of uv from 0.5.31 to 0.6.x in EPEL10; proposed permanent exception**
2025-02-19 18:38:17 <@zodbot:fedora.im> ● **Last Updated:** 12 minutes ago
2025-02-19 18:38:17 <@zodbot:fedora.im> ● **Assignee:** Not Assigned
2025-02-19 18:38:17 <@zodbot:fedora.im> 
2025-02-19 18:38:38 <@tdawson:fedora.im> Somebody jumped to the front of the exceptions queue :) 
2025-02-19 18:38:53 <@carlwgeorge:fedora.im> ah, i wasn't counting that separate since it's tied up in the rust stuff, but yes it's technically a third one
2025-02-19 18:39:09 <@carlwgeorge:fedora.im> so if we start a list now, it will be a list of three bullets
2025-02-19 18:39:34 <@smooge:fedora.im> llhttp
2025-02-19 18:40:19 <@carlwgeorge:fedora.im> i see llhttp in epel9 and on the fedora exception list, did we ever discuss that doing that style of update in epel?
2025-02-19 18:40:32 <@tdawson:fedora.im> Yep
2025-02-19 18:40:41 <@carlwgeorge:fedora.im> ok, four bullets
2025-02-19 18:40:47 <@tdawson:fedora.im> :)
2025-02-19 18:40:50 <@smooge:fedora.im> issue 262 This exception, as well as a permanent exception, was approved this week in the EPEL Steering Committee meeting.
2025-02-19 18:41:05 <@music:fedora.im> I am not digging up the link quickly, but a permanent exception for llhttp was suggested by the EPEL committee and announced on epel-devel.
2025-02-19 18:41:09 <@carlwgeorge:fedora.im> still completely doable imo, and if at some point we decide it's too much burden we can scrap that process and just blanket say the fedora list applies
2025-02-19 18:42:24 <@tdawson:fedora.im> How about this.  We do two things.  1) Someone do a writeup so we can discuss, and have it written down what our policy is.   2) Agree on 316 and 317 for now while we wait for step 1 to finish.
2025-02-19 18:42:54 <@nirik:matrix.scrye.com> sure.
2025-02-19 18:42:56 <@smooge:fedora.im> wow troy.. trying to make this meeting productive
2025-02-19 18:43:20 <@carlwgeorge:fedora.im> i can write up what i was suggesting, but i haven't seen anyone agree that is what they want, so others may want to write up a simple "fedora policy applies" clarification
2025-02-19 18:43:40 <@carlwgeorge:fedora.im> i guess we could have two competing prs and just close the one we don't go with 😁
2025-02-19 18:43:41 <@conan_kudo:matrix.org> that's when nirik proposed earlier, and I'm in favor of that
2025-02-19 18:43:52 <@conan_kudo:matrix.org> PRs that duke it out is fine too :P
2025-02-19 18:43:55 <@tdawson:fedora.im> As long as we have a starting point for the discussion.  Right now we're all saying "this is what I think we said"
2025-02-19 18:44:18 <@nirik:matrix.scrye.com> 🪕🪕
2025-02-19 18:44:39 <@music:fedora.im> Note that under the full incompatible updates policy, 317 is still in the one-week email discussion period.
2025-02-19 18:46:01 <@carlwgeorge:fedora.im> competing prs it is then, will write that up later this week
2025-02-19 18:46:08 <@carlwgeorge:fedora.im> competing prs it is then, will write up mine later this week
2025-02-19 18:46:53 <@tdawson:fedora.im> True, but 316 is only 2 hours older, yet it made it here.
2025-02-19 18:48:15 <@tdawson:fedora.im> But music has a good point.  Do we want to wait a week to decide about 316 and 317?
2025-02-19 18:48:47 <@tdawson:fedora.im> I think we should.  There hasn't been a week to discuss, and we're fairly short on time.
2025-02-19 18:48:56 <@dherrera:fedora.im> let's give it a week so we can also have the PRs
2025-02-19 18:49:13 <@nirik:matrix.scrye.com> sure, we can wait
2025-02-19 18:49:25 <@tdawson:fedora.im> Sounds good.
2025-02-19 18:49:57 <@tdawson:fedora.im> Since we're short on time, I'm going to go straight to Open Floor ... if there is something old that needs to come up, it can go there.
2025-02-19 18:50:10 <@tdawson:fedora.im> !topic General Issues / Open Floor
2025-02-19 18:50:20 <@tdawson:fedora.im> nirik: You are first for open floor.
2025-02-19 18:50:30 <@tdawson:fedora.im> I also have something for open floor, hopefully short.
2025-02-19 18:50:47 <@nirik:matrix.scrye.com> Oh yeah, lets see if I can remember...
2025-02-19 18:50:51 <@nirik:matrix.scrye.com> first:
2025-02-19 18:51:16 <@nirik:matrix.scrye.com> epel10.0/10.1 are enabled in koschei now.
2025-02-19 18:51:16 <@nirik:matrix.scrye.com> https://koschei.fedoraproject.org/
2025-02-19 18:51:36 <@nirik:matrix.scrye.com> although now that I look, I wonder if it's working...
2025-02-19 18:52:04 <@tdawson:fedora.im> It's at least on the page. :)
2025-02-19 18:52:08 <@nirik:matrix.scrye.com> second: Is there docs we can point people to about the 10 minor release plans? I know there's a discussion thread, but wanted to point someone to docs
2025-02-19 18:52:13 <@carlwgeorge:fedora.im> if you sort by either epel column, some checks and x's show up
2025-02-19 18:52:38 <@carlwgeorge:fedora.im> https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
2025-02-19 18:52:40 <@nirik:matrix.scrye.com> yeah, it is working I think... just looked weird because it hasn't gotten to any in a bit.
2025-02-19 18:52:53 <@nirik:matrix.scrye.com> excellent. thanks. :) Thats all I had
2025-02-19 18:53:14 <@carlwgeorge:fedora.im> i have an item too after troy does his
2025-02-19 18:53:35 <@dherrera:fedora.im> me too, but I think one of you 2 will say the same XD
2025-02-19 18:53:37 <@tdawson:fedora.im> So, I just had one that I wanted people to look at
2025-02-19 18:53:48 <@tdawson:fedora.im> https://pagure.io/epel/pull-request/315
2025-02-19 18:54:30 <@tdawson:fedora.im> This is a major restructuring of our docs.   I haven't had time to go over it all, but I just wanted to make sure extra eyes are on it.
2025-02-19 18:55:12 <@tdawson:fedora.im> !link https://tdawson.fedorapeople.org/epel-docs/public/epel/
2025-02-19 18:55:29 <@tdawson:fedora.im> I compiled it and put it up so it was easier to see.
2025-02-19 18:56:13 <@tdawson:fedora.im> We don't have to decide anything here and now, just making more people aware.
2025-02-19 18:56:29 <@tdawson:fedora.im> Carl George: I think you are next.
2025-02-19 18:57:20 <@carlwgeorge:fedora.im> now that we have multiple epel10 branches, i think it's time to consider making our retirement policy more granular.  right now, it says that epel packages can basically be retired at any time, give or take a week.
2025-02-19 18:58:28 <@tdawson:fedora.im> Carl George: So, like say you can retire it out of the current epel10, but not one that has already been archived?
2025-02-19 18:58:33 <@carlwgeorge:fedora.im> i'm thinking a good end state could be something like the current policy for the epel10 branch, but epel10.x branches can't retire stuff as easily (or at all).  this would be closer to fedora's retirement policy for rawhide vs stable.  that means for rhel users, packages would only be able to disappear when moving to new minor versions.
2025-02-19 18:59:24 <@carlwgeorge:fedora.im> well the ones that get archived won't change if a branch is retired, and those branches should show as inactive anyways.  but yes for the trailing but still maintained minor version branches.
2025-02-19 18:59:34 <@conan_kudo:matrix.org> I think that's reasonable as long as minor versions never last longer than 6 months
2025-02-19 18:59:56 <@carlwgeorge:fedora.im> putting the idea out there, will do a full write up in discussions to gather wider feedback
2025-02-19 18:59:59 <@conan_kudo:matrix.org> if we ever map minor versions to RHEL lifecycles, (including EUS), then this no longer flies
2025-02-19 19:00:11 <@conan_kudo:matrix.org> if we ever map minor versions to RHEL lifecycles (including EUS), then this no longer flies
2025-02-19 19:00:19 <@tdawson:fedora.im> Yep.  If we ever start doing EUS things ... we'll have to rethink it.
2025-02-19 19:00:22 <@conan_kudo:matrix.org> if we ever map minor versions to RHEL lifecycles (including EUS/ELS), then this no longer flies
2025-02-19 19:01:02 <@tdawson:fedora.im> Oh ... we're getting very short on time ... I'm going to pass to Diego Herrera really quick.
2025-02-19 19:01:09 <@carlwgeorge:fedora.im> that's it for now, we can move on and give davide overtime
2025-02-19 19:01:47 <@tdawson:fedora.im> Or both at once :)   Saves time.
2025-02-19 19:01:54 <@dherrera:fedora.im> going to pass to Davide Cavalca since it was the same as troy, but shoutout to Petr Bokoc for his work on that PR
2025-02-19 19:02:18 <@pbokoc:fedora.im> o7
2025-02-19 19:02:53 <@davide:cavalca.name> I just noticed that `m1n1` got branched for 10.0; this package has CentOS Stream branding baked in, and is really only appropriate for CentOS Stream
2025-02-19 19:03:01 <@davide:cavalca.name> is there a way we can opt it out of point releases entirely?
2025-02-19 19:03:01 <@zodbot:fedora.im> smooge gave a cookie to pbokoc. They now have 61 cookies, 1 of which were obtained in the Fedora 41 release cycle
2025-02-19 19:03:21 <@davide:cavalca.name> (there will be at least a couple more packages with the same constraint in the near future)
2025-02-19 19:03:36 <@carlwgeorge:fedora.im> i don't think we ever really considered a truly centos-only package
2025-02-19 19:03:54 <@smooge:fedora.im> well epel-next was sort of that
2025-02-19 19:04:04 <@carlwgeorge:fedora.im> yeah i mean for epel10
2025-02-19 19:04:06 <@davide:cavalca.name> to be clear, this isn't bad or anything on RHEL, it would just be mostly useless, and probably confusing if someone ever actually got it to work
2025-02-19 19:04:26 <@carlwgeorge:fedora.im> there certainly isn't a way currently to opt out, but i'm open to adding one.  do we have anything similar in fedora to model it after?
2025-02-19 19:04:29 <@nirik:matrix.scrye.com> I suppose we could come up with a blocklist in the scm request processor... but then we would have to maintain that list. ;)
2025-02-19 19:04:39 <@davide:cavalca.name> maybe a flag file in the repo?
2025-02-19 19:04:49 <@zodbot:fedora.im> dherrera gave a cookie to pbokoc. They now have 62 cookies, 2 of which were obtained in the Fedora 41 release cycle
2025-02-19 19:04:49 <@conan_kudo:matrix.org> we should be careful with flag files
2025-02-19 19:04:51 <@nirik:matrix.scrye.com> oh, wait, I see
2025-02-19 19:04:52 <@davide:cavalca.name> like `.noepelautobranch` or something
2025-02-19 19:04:58 <@conan_kudo:matrix.org> anyone can check those in and bad things can happen
2025-02-19 19:04:58 <@carlwgeorge:fedora.im> if the list is small, i was thinking hard coded exceptions to the branching script
2025-02-19 19:05:13 <@conan_kudo:matrix.org> we already have some misuse of the `noautobuild` file in fedora
2025-02-19 19:05:44 <@carlwgeorge:fedora.im> this one https://pagure.io/releng/blob/main/f/scripts/branching-epel/get_all_active_packages_branching.sh
2025-02-19 19:05:52 <@davide:cavalca.name> I think for this specifically it would just be `m1n1` and `asahi-installer`; there might be a handful more as packages depending on them would also need to be blocked
2025-02-19 19:05:57 <@davide:cavalca.name> but overall I'd expect less than 10
2025-02-19 19:06:12 <@conan_kudo:matrix.org> a list in the releng repo that the script reads is probably fine
2025-02-19 19:06:14 <@carlwgeorge:fedora.im> yeah lets just hard code that into the script, that's by far the easiest way to address it
2025-02-19 19:06:29 <@tdawson:fedora.im> Ya, if the list is small, I think hardcoding it sounds good.  My mind is having a hard time thinking of packages that would go on the list.
2025-02-19 19:07:11 <@nirik:matrix.scrye.com> That wouldn't prevent someone requesting the branch later tho? but I would assume maintainers who can do that would know not to.
2025-02-19 19:07:33 <@carlwgeorge:fedora.im> yeah that'll be fine i think
2025-02-19 19:07:56 <@tdawson:fedora.im> Sounds like a good time to end the meeting.
2025-02-19 19:08:03 <@davide:cavalca.name> thanks folks
2025-02-19 19:08:08 <@carlwgeorge:fedora.im> Davide Cavalca: please do send a pr to that script to implement the exception list, happy to review it
2025-02-19 19:08:16 <@davide:cavalca.name> will do
2025-02-19 19:08:39 <@tdawson:fedora.im> Thank you all for the very good discussions today.  I, and others, appreciate all the input, ideas, and opinions.
2025-02-19 19:08:52 <@tdawson:fedora.im> I'll talk to ya'll next week, if not sooner.
2025-02-19 19:09:02 <@nirik:matrix.scrye.com> thanks as always for running things Troy Dawson
2025-02-19 19:09:25 <@tdawson:fedora.im> !endmeeting