#meeting-1:fedoraproject.org log

<@tdawson:fedora.im>

18:00:45

!startmeeting EPEL (2025-02-19)

<@tdawson:fedora.im>

18:01:51

!topic aloha

<@tdawson:fedora.im>

18:01:51

!meetingname epel

<@meetbot:fedora.im>

18:01:51

Meeting started at 2025-02-19 18:00:45 UTC

<@meetbot:fedora.im>

18:01:51

The Meeting name is 'EPEL (2025-02-19)'

<@meetbot:fedora.im>

18:01:52

The Meeting Name is now epel

<@dherrera:fedora.im>

18:02:08

!hi

<@zodbot:fedora.im>

18:02:09

Diego Herrera (dherrera) - he / him / his

<@tdawson:fedora.im>

18:02:12

!meetingname epel

<@tdawson:fedora.im>

18:02:12

!topic aloha

<@carlwgeorge:fedora.im>

18:02:13

!hi

<@meetbot:fedora.im>

18:02:14

The Meeting Name is now epel

<@zodbot:fedora.im>

18:02:16

Carl George (carlwgeorge) - he / him / his

<@nirik:matrix.scrye.com>

18:02:20

morning

<@tdawson:fedora.im>

18:02:44

That was wierd ... it took a minute for my first command to go through ... seems to be ok now though.

<@tdawson:fedora.im>

18:03:17

Morning nirik

<@tdawson:fedora.im>

18:03:26

Hi Diego Herrera and Carl George

<@davide:cavalca.name>

18:03:29

!hi

<@zodbot:fedora.im>

18:03:31

Davide Cavalca (dcavalca) - he / him / his

<@tdawson:fedora.im>

18:03:38

Hi Davide Cavalca

<@nhanlon:beeper.com>

18:04:30

!hi

<@zodbot:fedora.im>

18:04:32

Neil Hanlon (neil) - he / him / his

<@tdawson:fedora.im>

18:05:44

Hi Neil Hanlon

<@tdawson:fedora.im>

18:05:57

!topic EPEL Issues https://pagure.io/epel/issues

<@tdawson:fedora.im>

18:05:57

!link https://pagure.io/epel/issues?tags=meeting&status=Open

<@tdawson:fedora.im>

18:06:25

We have several items today, I'm going to start from oldest to newest.

<@tdawson:fedora.im>

18:06:36

!epel 304

<@zodbot:fedora.im>

18:06:38

<@zodbot:fedora.im>

18:06:38

● **Assignee:** dherrera

<@zodbot:fedora.im>

18:06:38

● **Last Updated:** 10 hours ago

<@zodbot:fedora.im>

18:06:38

● **Opened:** 3 months ago by carlwgeorge

<@zodbot:fedora.im>

18:06:38

**epel #304** (https://pagure.io/epel/issue/304):**EPEL 10.0 mass branching**

<@tdawson:fedora.im>

18:07:11

Diego Herrera: Carl George How is that going? ... or actually, can you give a quick report.

<@carlwgeorge:fedora.im>

18:08:36

!link https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/7HPSCQDLFOZWNF4WACDDMULJCXZDVJRP/

<@dherrera:fedora.im>

18:08:57

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

<@dherrera:fedora.im>

18:09:47

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)

<@rcallicotte:fedora.im>

18:10:26

!hi

<@zodbot:fedora.im>

18:10:28

Robby Callicotte (rcallicotte) - he / him / his

<@tdawson:fedora.im>

18:10:38

Hi Robby Callicotte

<@tdawson:fedora.im>

18:11:08

Diego Herrera: That sounds great. I look forward to my first EPEL 10.0 update (yep, I already found one)

<@dherrera:fedora.im>

18:11:17

this should get fixed on fedpkg, but a workaround is to use the --no-auto-module flag as mentioned by fabio on the thread

<@carlwgeorge:fedora.im>

18:11:29

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

<@davide:cavalca.name>

18:11:44

does this mean we should use `epel10.1-build` as the base sidetag for epel10 builds now?

<@tdawson:fedora.im>

18:12:12

I believe it does.

<@carlwgeorge:fedora.im>

18:12:20

yes, that's what the epel10-candidate target uses now

<@davide:cavalca.name>

18:13:03

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

<@carlwgeorge:fedora.im>

18:13:29

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

<@carlwgeorge:fedora.im>

18:14:28

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?

<@davide:cavalca.name>

18:14:48

`fedpkg request-side-tag --base-tag`

<@davide:cavalca.name>

18:14:55

right now you have to give it the point release tag

<@davide:cavalca.name>

18:15:32

```

<@davide:cavalca.name>

18:15:32

```

<@davide:cavalca.name>

18:15:32

Could not execute request_side_tag: No such tagInfo: 'epel10-build'

<@davide:cavalca.name>

18:15:32

$ fedpkg request-side-tag --base-tag epel10-build

<@carlwgeorge:fedora.im>

18:15:33

i believe if you run `fedpkg request-side-tag` from the epel10 branch it resolves it for you

<@davide:cavalca.name>

18:15:43

oh, til

<@davide:cavalca.name>

18:16:07

yup that works just fine

<@davide:cavalca.name>

18:16:11

thanks!

<@carlwgeorge:fedora.im>

18:16:24

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

<@carlwgeorge:fedora.im>

18:17:22

i think that's it for the mass branching unless Diego Herrera has anything else, we should move on

<@tdawson:fedora.im>

18:18:21

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.

<@dherrera:fedora.im>

18:18:30

no, I think that's all for now :)

<@carlwgeorge:fedora.im>

18:18:59

huge thanks to nirik and jnsamyak for all their help

<@tdawson:fedora.im>

18:19:20

Moving on to the next ticket

<@tdawson:fedora.im>

18:19:36

!epel 313

<@zodbot:fedora.im>

18:19:37

● **Last Updated:** a day ago

<@zodbot:fedora.im>

18:19:37

**epel #313** (https://pagure.io/epel/issue/313):**EPEL 10 dnf variables problems**

<@zodbot:fedora.im>

18:19:37

<@zodbot:fedora.im>

18:19:37

● **Opened:** 4 weeks ago by carlwgeorge

<@zodbot:fedora.im>

18:19:37

● **Assignee:** carlwgeorge

<@tdawson:fedora.im>

18:20:02

Carl George: Do you mind giving a brief status.

<@tdawson:fedora.im>

18:21:00

nirik: Sounds good, I'll make sure we have enough time for it.

<@carlwgeorge:fedora.im>

18:21:44

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.

<@tdawson:fedora.im>

18:22:44

You had mentioned that things were moving forward. I'm not sure about the extension.

<@tdawson:fedora.im>

18:23:11

But thank you for continuing to work on that. It's really going to help.

<@tdawson:fedora.im>

18:23:25

Do you want to add anything else before we move on?

<@carlwgeorge:fedora.im>

18:23:47

nope, that's it

<@tdawson:fedora.im>

18:24:03

OK, moving on to a ticket that might take more time.

<@tdawson:fedora.im>

18:24:17

!epel 316

<@zodbot:fedora.im>

18:24:18

● **Assignee:** Not Assigned

<@zodbot:fedora.im>

18:24:18

● **Last Updated:** 3 hours ago

<@zodbot:fedora.im>

18:24:18

**epel #316** (https://pagure.io/epel/issue/316):**EPEL Updates Policy, minor branches, and source-only Rust packages**

<@zodbot:fedora.im>

18:24:18

<@zodbot:fedora.im>

18:24:18

● **Opened:** 5 hours ago by decathorpe

<@nirik:matrix.scrye.com>

18:25:19

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)

<@tdawson:fedora.im>

18:25:44

Yes, that is what I though we'd already decided, a year or two ago.

<@carlwgeorge:fedora.im>

18:25:59

yeah that's our general rule, but it doesn't hurt to be explicit when there is doubt

<@nhanlon:beeper.com>

18:26:03

I recall the same

<@conan_kudo:matrix.org>

18:26:04

!hi

<@zodbot:fedora.im>

18:26:05

Neal Gompa (ngompa) - he / him / his

<@conan_kudo:matrix.org>

18:26:26

Yeah, I'm fairly certain that's the rule, we can just quickly agree and record that in the ticket.

<@music:fedora.im>

18:26:28

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.”

<@carlwgeorge:fedora.im>

18:26:57

i do think we should consider not matching the fedora list exactly though

<@nirik:matrix.scrye.com>

18:26:59

yeah, we should document

<@carlwgeorge:fedora.im>

18:27:19

like, the list will probably be mostly the same, but i'm not convinced that each case will make sense for both

<@conan_kudo:matrix.org>

18:27:32

the exception list follows the same policy recommendations we would require anyway

<@conan_kudo:matrix.org>

18:27:37

so I would _hope_ the list is the same

<@tdawson:fedora.im>

18:27:44

Well yes, not exactly, that was where we would have our own exceptions (or additions) list.

<@carlwgeorge:fedora.im>

18:27:45

kde already doesn't have the same policy between fedora and epel

<@conan_kudo:matrix.org>

18:27:55

it doesn't?

<@carlwgeorge:fedora.im>

18:28:36

kde 6 isn't coming to epel8/9 anytime soon, last i checked

<@jonathanspw:fedora.im>

18:28:42

!hi

<@zodbot:fedora.im>

18:28:43

Jonathan Wright (jonathanspw)

<@conan_kudo:matrix.org>

18:28:44

that's also true in fedora

<@conan_kudo:matrix.org>

18:28:50

we didn't upgrade kde6 in f39

<@conan_kudo:matrix.org>

18:28:56

we didn't upgrade to kde6 in f39

<@conan_kudo:matrix.org>

18:29:01

that is not a policy difference

<@tdawson:fedora.im>

18:29:23

The fedora exceptions for KDE doesn't say they "HAVE" to update all the releases, I believe it says they "CAN" update the releases.

<@nirik:matrix.scrye.com>

18:29:27

I'm hard pressed to think of an example where they would differ...

<@conan_kudo:matrix.org>

18:29:38

I don't think there _is_ a reason for it to differ.

<@conan_kudo:matrix.org>

18:29:48

The difference is we yell more when people break the rules :P

<@nirik:matrix.scrye.com>

18:30:06

(of course some don't apply... like the kernel)

<@conan_kudo:matrix.org>

18:30:13

The exception has never included major versions where all the ABIs completely break.

<@conan_kudo:matrix.org>

18:30:35

that's why we didn't even _contemplate_ KDE Plasma 6 for F39 _or_ EPEL9

<@carlwgeorge:fedora.im>

18:30:36

yeah, enterprise users are more sensitive to changes, so we should be more careful

<@carlwgeorge:fedora.im>

18:30:59

the difference is f39 is already eol, epel9 is around for many years to come

<@carlwgeorge:fedora.im>

18:31:07

it's not quite the same thing

<@conan_kudo:matrix.org>

18:31:12

sure, but when Plasma 6 was first released F39 was not EOL

<@nirik:matrix.scrye.com>

18:31:20

I think if we just document 'fedora exceptions apply, if you have any questions, please talk to us'

<@conan_kudo:matrix.org>

18:31:28

yeah, that's reasonable

<@dherrera:fedora.im>

18:31:36

that's reasonable

<@conan_kudo:matrix.org>

18:31:43

there's a page to link to from the fesco side IIRC

<@nirik:matrix.scrye.com>

18:31:51

see: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_exceptions

<@conan_kudo:matrix.org>

18:31:52

so we should ensure that's referenced

<@smooge:fedora.im>

18:32:20

let's let music finish typing please

<@carlwgeorge:fedora.im>

18:32:42

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)

<@music:fedora.im>

18:32:43

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.

<@carlwgeorge:fedora.im>

18:33:18

<@carlwgeorge:fedora.im>

18:33:18

one example, zathura:

<@carlwgeorge:fedora.im>

18:33:18

> Zathura users tend to want the latest version - I often get bugs asking for an update.

<@conan_kudo:matrix.org>

18:33:55

the document reader app?

<@conan_kudo:matrix.org>

18:34:42

I'm not sure we'd block that either

<@carlwgeorge:fedora.im>

18:35:07

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

<@carlwgeorge:fedora.im>

18:35:41

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.

<@nirik:matrix.scrye.com>

18:35:43

I'm not sure thats really happening anymore. ;)

<@nirik:matrix.scrye.com>

18:35:57

I don't think fesco has ever gone back to re-evaluate old exceptions

<@conan_kudo:matrix.org>

18:36:47

I think it's not entirely useful extra work to do that each time a fesco exception is added

<@conan_kudo:matrix.org>

18:37:06

we can always ask fesco to consider us as part of their permanent exception criteria (if they aren't already doing that)

<@carlwgeorge:fedora.im>

18:37:06

it's not every time, as not all the packages are even in epel

<@carlwgeorge:fedora.im>

18:37:42

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

<@tdawson:fedora.im>

18:37:55

Actually, third

<@carlwgeorge:fedora.im>

18:38:07

what was the other one i'm forgetting?

<@tdawson:fedora.im>

18:38:16

!epel 317

<@zodbot:fedora.im>

18:38:17

● **Opened:** 3 hours ago by music

<@zodbot:fedora.im>

18:38:17

**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**

<@zodbot:fedora.im>

18:38:17

● **Last Updated:** 12 minutes ago

<@zodbot:fedora.im>

18:38:17

● **Assignee:** Not Assigned

<@zodbot:fedora.im>

18:38:17

<@tdawson:fedora.im>

18:38:38

Somebody jumped to the front of the exceptions queue :)

<@carlwgeorge:fedora.im>

18:38:53

ah, i wasn't counting that separate since it's tied up in the rust stuff, but yes it's technically a third one

<@carlwgeorge:fedora.im>

18:39:09

so if we start a list now, it will be a list of three bullets

<@smooge:fedora.im>

18:39:34

llhttp

<@carlwgeorge:fedora.im>

18:40:19

i see llhttp in epel9 and on the fedora exception list, did we ever discuss that doing that style of update in epel?

<@tdawson:fedora.im>

18:40:32

Yep

<@carlwgeorge:fedora.im>

18:40:41

ok, four bullets

<@tdawson:fedora.im>

18:40:47

<@smooge:fedora.im>

18:40:50

issue 262 This exception, as well as a permanent exception, was approved this week in the EPEL Steering Committee meeting.

<@music:fedora.im>

18:41:05

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.

<@carlwgeorge:fedora.im>

18:41:09

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

<@tdawson:fedora.im>

18:42:24

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.

<@nirik:matrix.scrye.com>

18:42:54

sure.

<@smooge:fedora.im>

18:42:56

wow troy.. trying to make this meeting productive

<@carlwgeorge:fedora.im>

18:43:20

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

<@carlwgeorge:fedora.im>

18:43:40

i guess we could have two competing prs and just close the one we don't go with 😁

<@conan_kudo:matrix.org>

18:43:41

that's when nirik proposed earlier, and I'm in favor of that

<@conan_kudo:matrix.org>

18:43:52

PRs that duke it out is fine too :P

<@tdawson:fedora.im>

18:43:55

As long as we have a starting point for the discussion. Right now we're all saying "this is what I think we said"

<@nirik:matrix.scrye.com>

18:44:18

🪕🪕

<@music:fedora.im>

18:44:39

Note that under the full incompatible updates policy, 317 is still in the one-week email discussion period.

<@carlwgeorge:fedora.im>

18:46:01

competing prs it is then, will write that up later this week

<@carlwgeorge:fedora.im>

18:46:08

competing prs it is then, will write up mine later this week

<@tdawson:fedora.im>

18:46:53

True, but 316 is only 2 hours older, yet it made it here.

<@tdawson:fedora.im>

18:48:15

But music has a good point. Do we want to wait a week to decide about 316 and 317?

<@tdawson:fedora.im>

18:48:47

I think we should. There hasn't been a week to discuss, and we're fairly short on time.

<@dherrera:fedora.im>

18:48:56

let's give it a week so we can also have the PRs

<@nirik:matrix.scrye.com>

18:49:13

sure, we can wait

<@tdawson:fedora.im>

18:49:25

Sounds good.

<@tdawson:fedora.im>

18:49:57

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.

<@tdawson:fedora.im>

18:50:10

!topic General Issues / Open Floor

<@tdawson:fedora.im>

18:50:20

nirik: You are first for open floor.

<@tdawson:fedora.im>

18:50:30

I also have something for open floor, hopefully short.

<@nirik:matrix.scrye.com>

18:50:47

Oh yeah, lets see if I can remember...

<@nirik:matrix.scrye.com>

18:50:51

first:

<@nirik:matrix.scrye.com>

18:51:16

epel10.0/10.1 are enabled in koschei now.

<@nirik:matrix.scrye.com>

18:51:16

https://koschei.fedoraproject.org/

<@nirik:matrix.scrye.com>

18:51:36

although now that I look, I wonder if it's working...

<@tdawson:fedora.im>

18:52:04

It's at least on the page. :)

<@nirik:matrix.scrye.com>

18:52:08

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

<@carlwgeorge:fedora.im>

18:52:13

if you sort by either epel column, some checks and x's show up

<@carlwgeorge:fedora.im>

18:52:38

https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10

<@nirik:matrix.scrye.com>

18:52:40

yeah, it is working I think... just looked weird because it hasn't gotten to any in a bit.

<@nirik:matrix.scrye.com>

18:52:53

excellent. thanks. :) Thats all I had

<@carlwgeorge:fedora.im>

18:53:14

i have an item too after troy does his

<@dherrera:fedora.im>

18:53:35

me too, but I think one of you 2 will say the same XD

<@tdawson:fedora.im>

18:53:37

So, I just had one that I wanted people to look at

<@tdawson:fedora.im>

18:53:48

https://pagure.io/epel/pull-request/315

<@tdawson:fedora.im>

18:54:30

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.

<@tdawson:fedora.im>

18:55:12

!link https://tdawson.fedorapeople.org/epel-docs/public/epel/

<@tdawson:fedora.im>

18:55:29

I compiled it and put it up so it was easier to see.

<@tdawson:fedora.im>

18:56:13

We don't have to decide anything here and now, just making more people aware.

<@tdawson:fedora.im>

18:56:29

Carl George: I think you are next.

<@carlwgeorge:fedora.im>

18:57:20

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.

<@tdawson:fedora.im>

18:58:28

Carl George: So, like say you can retire it out of the current epel10, but not one that has already been archived?

<@carlwgeorge:fedora.im>

18:58:33

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.

<@carlwgeorge:fedora.im>

18:59:24

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.

<@conan_kudo:matrix.org>

18:59:34

I think that's reasonable as long as minor versions never last longer than 6 months

<@carlwgeorge:fedora.im>

18:59:56

putting the idea out there, will do a full write up in discussions to gather wider feedback

<@conan_kudo:matrix.org>

18:59:59

if we ever map minor versions to RHEL lifecycles, (including EUS), then this no longer flies

<@conan_kudo:matrix.org>

19:00:11

if we ever map minor versions to RHEL lifecycles (including EUS), then this no longer flies

<@tdawson:fedora.im>

19:00:19

Yep. If we ever start doing EUS things ... we'll have to rethink it.

<@conan_kudo:matrix.org>

19:00:22

if we ever map minor versions to RHEL lifecycles (including EUS/ELS), then this no longer flies

<@tdawson:fedora.im>

19:01:02

Oh ... we're getting very short on time ... I'm going to pass to Diego Herrera really quick.

<@carlwgeorge:fedora.im>

19:01:09

that's it for now, we can move on and give davide overtime

<@tdawson:fedora.im>

19:01:47

Or both at once :) Saves time.

<@dherrera:fedora.im>

19:01:54

going to pass to Davide Cavalca since it was the same as troy, but shoutout to Petr Bokoc for his work on that PR

<@pbokoc:fedora.im>

19:02:18

<@davide:cavalca.name>

19:02:53

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

<@davide:cavalca.name>

19:03:01

is there a way we can opt it out of point releases entirely?

<@zodbot:fedora.im>

19:03:01

smooge gave a cookie to pbokoc. They now have 61 cookies, 1 of which were obtained in the Fedora 41 release cycle

<@davide:cavalca.name>

19:03:21

(there will be at least a couple more packages with the same constraint in the near future)

<@carlwgeorge:fedora.im>

19:03:36

i don't think we ever really considered a truly centos-only package

<@smooge:fedora.im>

19:03:54

well epel-next was sort of that

<@carlwgeorge:fedora.im>

19:04:04

yeah i mean for epel10

<@davide:cavalca.name>

19:04:06

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

<@carlwgeorge:fedora.im>

19:04:26

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?

<@nirik:matrix.scrye.com>

19:04:29

I suppose we could come up with a blocklist in the scm request processor... but then we would have to maintain that list. ;)

<@davide:cavalca.name>

19:04:39

maybe a flag file in the repo?

<@zodbot:fedora.im>

19:04:49

dherrera gave a cookie to pbokoc. They now have 62 cookies, 2 of which were obtained in the Fedora 41 release cycle

<@conan_kudo:matrix.org>

19:04:49

we should be careful with flag files

<@nirik:matrix.scrye.com>

19:04:51

oh, wait, I see

<@davide:cavalca.name>

19:04:52

like `.noepelautobranch` or something

<@conan_kudo:matrix.org>

19:04:58

anyone can check those in and bad things can happen

<@carlwgeorge:fedora.im>

19:04:58

if the list is small, i was thinking hard coded exceptions to the branching script

<@conan_kudo:matrix.org>

19:05:13

we already have some misuse of the `noautobuild` file in fedora

<@carlwgeorge:fedora.im>

19:05:44

this one https://pagure.io/releng/blob/main/f/scripts/branching-epel/get_all_active_packages_branching.sh

<@davide:cavalca.name>

19:05:52

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

<@davide:cavalca.name>

19:05:57

but overall I'd expect less than 10

<@conan_kudo:matrix.org>

19:06:12

a list in the releng repo that the script reads is probably fine

<@carlwgeorge:fedora.im>

19:06:14

yeah lets just hard code that into the script, that's by far the easiest way to address it

<@tdawson:fedora.im>

19:06:29

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.

<@nirik:matrix.scrye.com>

19:07:11

That wouldn't prevent someone requesting the branch later tho? but I would assume maintainers who can do that would know not to.

<@carlwgeorge:fedora.im>

19:07:33

yeah that'll be fine i think

<@tdawson:fedora.im>

19:07:56

Sounds like a good time to end the meeting.

<@davide:cavalca.name>

19:08:03

thanks folks

<@carlwgeorge:fedora.im>

19:08:08

Davide Cavalca: please do send a pr to that script to implement the exception list, happy to review it

<@davide:cavalca.name>

19:08:16

will do

<@tdawson:fedora.im>

19:08:39

Thank you all for the very good discussions today. I, and others, appreciate all the input, ideas, and opinions.

<@tdawson:fedora.im>

19:08:52

I'll talk to ya'll next week, if not sooner.

<@nirik:matrix.scrye.com>

19:09:02

thanks as always for running things Troy Dawson

<@tdawson:fedora.im>

19:09:25

!endmeeting