#meeting-1:fedoraproject.org log

<@tdawson:fedora.im>

18:00:03

!startmeeting EPEL (2024-08-21)

<@meetbot:fedora.im>

18:00:04

Meeting started at 2024-08-21 18:00:03 UTC

<@meetbot:fedora.im>

18:00:04

The Meeting name is 'EPEL (2024-08-21)'

<@tdawson:fedora.im>

18:00:09

!meetingname epel

<@tdawson:fedora.im>

18:00:09

!topic aloha

<@tdawson:fedora.im>

18:00:09

<@meetbot:fedora.im>

18:00:10

The Meeting Name is now epel

<@dherrera:fedora.im>

18:00:25

!hi

<@zodbot:fedora.im>

18:00:26

Diego Herrera (dherrera) - he / him / his

<@tdawson:fedora.im>

18:00:32

Hi Diego Herrera

<@jrichardson:matrix.org>

18:00:33

!hi

<@zodbot:fedora.im>

18:00:34

James Richardson (jrichardson)

<@tdawson:fedora.im>

18:00:42

Hi James Richardson

<@davide:cavalca.name>

18:01:50

!hi

<@zodbot:fedora.im>

18:01:51

Davide Cavalca (dcavalca) - he / him / his

<@tdawson:fedora.im>

18:01:56

Hi Davide Cavalca

<@nhanlon:beeper.com>

18:02:56

!hi

<@zodbot:fedora.im>

18:02:58

Neil Hanlon (neil) - he / him / his

<@nhanlon:beeper.com>

18:03:05

sorry I'm late, someone was _wrong_ on the internet

<@carlwgeorge:matrix.org>

18:03:06

!hi

<@zodbot:fedora.im>

18:03:07

Carl George (carlwgeorge) - he / him / his

<@nirik:matrix.scrye.com>

18:03:34

morning

<@tdawson:fedora.im>

18:03:46

Hi Neil Hanlon and Carl George

<@tdawson:fedora.im>

18:03:51

Morning nirik

<@salimma:fedora.im>

18:04:36

!hi

<@zodbot:fedora.im>

18:04:37

Michel Lind (salimma) - he / him / his

<@tdawson:fedora.im>

18:04:53

Hi Michel Lind 🎩

<@salimma:fedora.im>

18:04:53

sorry I'm late, someone was right on the Internet :P

<@tdawson:fedora.im>

18:05:16

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

<@tdawson:fedora.im>

18:05:16

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

<@tdawson:fedora.im>

18:05:38

Cool, I like that I can now paste more than one thing at a time.

<@salimma:fedora.im>

18:05:47

oh, it's finally live! nice

<@tdawson:fedora.im>

18:06:01

So, let's start with Zeek

<@tdawson:fedora.im>

18:06:12

!epel 284

<@zodbot:fedora.im>

18:06:13

<@zodbot:fedora.im>

18:06:13

**epel #284** (https://pagure.io/epel/issue/284):**Proposing incompatible upgrade of Zeek to the latest LTS version**

<@zodbot:fedora.im>

18:06:13

● **Assignee:** Not Assigned

<@zodbot:fedora.im>

18:06:13

● **Last Updated:** 2 weeks ago

<@zodbot:fedora.im>

18:06:13

● **Opened:** a month ago by salimma

<@salimma:fedora.im>

18:06:35

oh, that fun one

<@salimma:fedora.im>

18:06:51

Zeek 7 LTS is now out, so I'll need to redo the packaging anyway

<@tdawson:fedora.im>

18:06:54

Did we ever come to a conclusion since we talked about it a few weeks ago?

<@salimma:fedora.im>

18:07:01

in that light I think starting as a new package is probably better

<@salimma:fedora.im>

18:07:24

no point pushing the current zeek that's updated to v6 since it will soon go EOL

<@carlwgeorge:matrix.org>

18:07:47

to me "no longer supported upstream" isn't a strong enough justification by itself, if it were then the majority of epel packages would qualify to do incompatible updates

<@salimma:fedora.im>

18:08:05

right, but in zeek's case there are a lot of security issues in there

<@carlwgeorge:matrix.org>

18:08:54

for posterity we should document the specific security issues that are intended to be solved by this in the issue

<@salimma:fedora.im>

18:08:54

but even if we want to push an incompatible upgrade (instead of an alternate package for a higher version) - it does not make sense to do v6 anymore

<@salimma:fedora.im>

18:09:31

I like the idea of just creating a new package for each LTS version, then getting the new version in is not blocked on the incompat process, and instead we can decide whether to retire the old EOL versions or not based on security risks

<@tdawson:fedora.im>

18:09:58

I'm fine with that.

<@salimma:fedora.im>

18:09:59

we should, yeah. upstream does not make it easy but I'll do that later

<@carlwgeorge:matrix.org>

18:10:09

yeah i think i remember that part, but we failed to record that observation in the ticket the last time we talked about it

<@salimma:fedora.im>

18:10:23

oh - follow up to that

<@salimma:fedora.im>

18:11:10

I'll draft some packaging guideline for FPC about virtual provides - e.g. different Django stacks, different Zeeks, etc. - since we're using it for different things in Fedora proper and EPEL but there's no consistency about naming and how to do it

<@carlwgeorge:matrix.org>

18:11:54

are you leaning towards parallel installable with alternatives, or conflicting packages?

<@dherrera:fedora.im>

18:11:57

if you are considering this, I think it would be sensible start in fedora :eyes:

<@dherrera:fedora.im>

18:12:09

if you are considering this, I think it would be sensible to start in fedora :eyes:

<@salimma:fedora.im>

18:12:11

once we have that, I suppose the Django draft I still have on my disk can be widened to also apply to Zeek? I'll need to see how much overlap they end up having

<@salimma:fedora.im>

18:12:24

yup

<@salimma:fedora.im>

18:12:34

the same way zeek v6 is now in Rawhide

<@salimma:fedora.im>

18:13:24

I think I'll treat zeek and Django the same way - unversioned package only in Fedora, "fork" it to create the versioned packages each time

<@conan_kudo:matrix.org>

18:18:26

!hi

<@salimma:fedora.im>

18:18:29

because now you'll be blocked on releasing an incompatible upgrade, since the binary RPMs are the same, but you have to do the extra work of getting a new package reviewed

<@zodbot:fedora.im>

18:18:32

Neal Gompa (ngompa) - he / him / his

<@nhanlon:beeper.com>

18:18:42

I think this strategy will be the best long term, given what we've seen with zeek so far. I am of course on board to help with the maintenance and such

<@dherrera:fedora.im>

18:18:48

I read kubernetes is going the same way in fedora (https://fedoramagazine.org/forthcoming-kubernetes-packaging-changes/)

<@tdawson:fedora.im>

18:19:42

So, are we done with this issue? Since it is no longer a update, but rather a EOL due to security, I believe it doesn't need a vote. But rather follow this policy https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons

<@carlwgeorge:matrix.org>

18:19:59

sounds about right to me

<@salimma:fedora.im>

18:20:04

we're done, yeah

<@tdawson:fedora.im>

18:20:32

Michel Lind 🎩: Don't forget to update the issue. And moving on to the next one ...

<@tdawson:fedora.im>

18:20:54

!epel 291

<@zodbot:fedora.im>

18:20:55

<@zodbot:fedora.im>

18:20:55

● **Last Updated:** a day ago

<@zodbot:fedora.im>

18:20:55

● **Opened:** a day ago by decathorpe

<@zodbot:fedora.im>

18:20:55

**epel #291** (https://pagure.io/epel/issue/291):**erroneous EPEL2RHEL ticket for RHEL 10 filed for package in EPEL 9 but not in EPEL 10**

<@zodbot:fedora.im>

18:20:55

● **Assignee:** Not Assigned

<@tdawson:fedora.im>

18:21:31

I don't think this one needs much discussion, I didn't mark it for meeting, but someone else did.

<@carlwgeorge:matrix.org>

18:21:56

yeah i did just to make sure it was brought up for awareness

<@carlwgeorge:matrix.org>

18:22:04

looks like you're on top of it

<@tdawson:fedora.im>

18:22:24

I'm really hoping we don't get any more of these because 1) hopefully we aren't adding too many new packages to RHEL10 and 2) hopefully we get the epel10 repo in place.

<@tdawson:fedora.im>

18:23:01

I honestly am surprised at how few we've gotten. If I am looking right, this is the first one.

<@salimma:fedora.im>

18:23:07

yeah, I think it's worth highlighting this happened

<@carlwgeorge:matrix.org>

18:23:16

it's sort of in place, but i don't trust it yet. i need another chunk of nirik's time to look closer at the details of which parts aren't working right yet.

<@carlwgeorge:matrix.org>

18:23:55

like i thought we were doing ad-hoc compose runs, but it seems several have happened automatically now and packages are populating the repo paths

<@tdawson:fedora.im>

18:24:07

This does sortof lead into the next topic, I think I'm going to change topics.

<@tdawson:fedora.im>

18:24:12

!topic EPEL 10

<@nirik:matrix.scrye.com>

18:24:17

yes, bodhi does daily updates pushes, these are part of that now that it's composed by bodhi

<@carlwgeorge:matrix.org>

18:25:38

so originally i was planning on having epel10 composes be done like rawhide, via a cron job outside of bodhi, with the bodhi setting of composed-by-bodhi set to false like rawhide. at flock it was suggested to me that it is done that way for rawhide for image generation, which we don't have to worry about.

<@carlwgeorge:matrix.org>

18:26:20

and the further suggestion that we just flip composed-by-bodhi to true. but it seems we hit an unplanned combination of bodhi settings and now our automatic updates aren't processing to stable fully automatically like before.

<@nirik:matrix.scrye.com>

18:27:04

right. Create Automatic Updates isn't really setup for this use case. There's more process for branched/rawhide that requests them to testing, lets ci run and then stable after a while.

<@carlwgeorge:matrix.org>

18:27:33

so i think our decision point is whether we 1) switch to full rawhide style, likely until we get to the official epel10 launch in nov/dec, or 2) troubleshoot the bodhi weirdness, possibly make code changes, and role those out in production, or 3) turn off automatic updates

<@carlwgeorge:matrix.org>

18:27:38

thoughts?

<@carlwgeorge:matrix.org>

18:28:11

i know several folks told me they appreciated the automatic updates and 0 days to stable for initial bootstrapping

<@nirik:matrix.scrye.com>

18:28:36

note that sidetags should be working now for stacks of dependent things

<@nhanlon:beeper.com>

18:28:51

ideally #2 happens anyways, but I guess lean towards 1

<@carlwgeorge:matrix.org>

18:29:01

oh yes we got sidetags working in the last week too

<@tdawson:fedora.im>

18:29:25

Yep, I know I like the automatic updates, so I'm leaning towards 1, rawhide style.

<@carlwgeorge:matrix.org>

18:29:25

working sidetags i guess are a point in favor of 3

<@salimma:fedora.im>

18:29:31

automatic updates were nice, I think we should do that (e.g. operate Rawhide style) until RHEL 10 beta

<@nirik:matrix.scrye.com>

18:29:43

I am not sure we can easily get to 1. would have to think about it. In any case it would require a pungi config and script to do the composes

<@nhanlon:beeper.com>

18:30:07

ah, that changes my mind

<@carlwgeorge:matrix.org>

18:30:08

i say we got sidetags working, kevin did it all, i just noted it down in my hackmd to go into future minor versions and the eventual sop

<@nirik:matrix.scrye.com>

18:30:08

I guess that and setting it back to 'pending'

<@salimma:fedora.im>

18:30:11

I'm also OK - if we have to - deal with it like Fedora branched (work on side tag, land side tag, updates go stable in 3 days not 7) but it makes bootstrapping a bit harder

<@nhanlon:beeper.com>

18:30:33

sidetag workflow is also fine with me :)

<@conan_kudo:matrix.org>

18:30:37

we could also just do a variation where it lands in one day

<@salimma:fedora.im>

18:30:38

anything that avoid using Pungi more sounds like a win so... by all means I'll vote in favor of anything that does not touch it

<@nhanlon:beeper.com>

18:30:43

appreciate the work on that!

<@nhanlon:beeper.com>

18:30:49

nirik++

<@zodbot:fedora.im>

18:30:50

Sorry, but Fedora Accounts user 'nirik' does not exist

<@tdawson:fedora.im>

18:30:57

Ya, I'm good with whatever get's us working. My prefernce is 1/rawhide like, but whatever we need to do.

<@salimma:fedora.im>

18:30:58

yeah, landing in one day is probably a nice compromise between Rawhide style and Fedora branched style

<@nhanlon:beeper.com>

18:31:02

i'll give you cookies later..

<@conan_kudo:matrix.org>

18:31:03

nirik++

<@nirik:matrix.scrye.com>

18:31:06

updates currently do this: an automatic update is created, but it's just 'pending' you have to request testing on it, then next push they go to testing and get autosubmitted for stable and go stable in the next push, so 2 days

<@salimma:fedora.im>

18:31:28

knowing you have to request testing yourself seems counterintuitive

<@carlwgeorge:matrix.org>

18:31:47

i was leaning towards getting 1 working, but i'm not sure the effort is worth it just to have it that way for a few months

<@nirik:matrix.scrye.com>

18:31:50

it's a use case that was never designed for to have auto updates and not rawhide/branched.

<@carlwgeorge:matrix.org>

18:32:14

like other things with the epel10 plan, we're breaking previous expectations in fun ways

<@carlwgeorge:matrix.org>

18:32:25

nothing insurmountable, just kinks to work out

<@nirik:matrix.scrye.com>

18:32:26

go fast, break things. ;)

<@jrichardson:matrix.org>

18:32:56

Would #2 be the longer term solution?

<@conan_kudo:matrix.org>

18:33:21

Carl George: I think it'd be more useful to have the next go around

<@nirik:matrix.scrye.com>

18:33:24

3 is easy, 1 and 2 will require some work (either bodhi or pungi/scripts)

<@carlwgeorge:matrix.org>

18:33:27

only if we do things the exact same way in epel11 timeline wise

<@conan_kudo:matrix.org>

18:33:56

well, so far we haven't done a single epel branch the same way twice in a row

<@carlwgeorge:matrix.org>

18:33:59

i would rank by amount of effort 3 (easiest), 1, 2 (hardest)

<@conan_kudo:matrix.org>

18:34:07

at least not since I started paying attention to epel branching :)

<@carlwgeorge:matrix.org>

18:34:51

i'm really hoping that we do for epel11, save stephen's plan for early builds (rebranded eln-extras)

<@conan_kudo:matrix.org>

18:34:51

6, 7, 8, 9, and 10 were all different :D

<@salimma:fedora.im>

18:35:41

I'm hoping we settle on one we can reuse for 11, yeah

<@carlwgeorge:matrix.org>

18:35:56

anyways, that's the state of things, we don't need a decision here and i'll cook on it some more with nirik when he has time

<@salimma:fedora.im>

18:35:59

sure, it will probably need to be tweaked a bit, but let's not do one-offs

<@salimma:fedora.im>

18:36:37

seems like we're all in alignment that we want to reduce friction in bootstrapping while not making releng's life hell, and something that can be reused next time round :)

<@salimma:fedora.im>

18:36:49

so... are we ok with just delegating this to Carl and nirik?

<@carlwgeorge:matrix.org>

18:36:51

at this point the only thing i think that will make epel11 radically different is if minor versions are a complete failure and everyone hates them

<@nhanlon:beeper.com>

18:37:08

wishful thinking

<@nhanlon:beeper.com>

18:37:18

the new complaint is we don't have per-compose snapshots

<@salimma:fedora.im>

18:37:28

yeah, and minor version wouldn't be something we need to deal with when bootstrapping anyway, right?

<@tdawson:fedora.im>

18:37:33

I really hope they aren't. I hope we find them wonderful and useful. Brilliant Unicorn Farts.

<@salimma:fedora.im>

18:37:41

so hopefully whatever flow we pick for bootstrapping X.0 would work again

<@nhanlon:beeper.com>

18:37:42

at least that's the one I'm going to start circulating on my mastodon sock puppet accounts... /s

<@salimma:fedora.im>

18:37:59

I like sock puppets better than bots

<@tdawson:fedora.im>

18:38:17

So, it sounds like we're ready to move on.

<@tdawson:fedora.im>

18:38:43

!topic Old Business

<@tdawson:fedora.im>

18:39:09

Does anyone have any Old Business?

<@tdawson:fedora.im>

18:40:51

I don't see smooge anywhere ... so I'm going to move on ...

<@tdawson:fedora.im>

18:41:00

!topic General Issues / Open Floor

<@tdawson:fedora.im>

18:41:15

Does anyone have anything for the Open Floor?

<@nhanlon:beeper.com>

18:41:25

i have a small thing

<@tdawson:fedora.im>

18:41:39

Neil Hanlon: Go for it.

<@nhanlon:beeper.com>

18:43:05

incus is still a bit new, of course, but I had a handful of people interested in moving from LXD to incus on EL9, so I obliged with a copr repo.

<@nhanlon:beeper.com>

18:43:05

test, comment, etc etc

<@nhanlon:beeper.com>

18:43:05

<@nhanlon:beeper.com>

18:43:05

<@nhanlon:beeper.com>

18:43:05

https://copr.fedorainfracloud.org/coprs/neil/incus/ -- got this nominally working on EL 9 last night with help from stgrabber.

<@nhanlon:beeper.com>

18:43:19

incus is still a bit new, of course, but I had a handful of people interested in moving from LXD to incus on EL9, so I obliged with a copr repo.

<@nhanlon:beeper.com>

18:43:19

test, comment, etc etc

<@nhanlon:beeper.com>

18:43:19

<@nhanlon:beeper.com>

18:43:19

https://copr.fedorainfracloud.org/coprs/neil/incus/ -- got this nominally working on EL 9 last night with help from stgraber.

<@nhanlon:beeper.com>

18:43:19

<@tdawson:fedora.im>

18:43:55

Very cool

<@salimma:fedora.im>

18:43:59

Conan Kudo might be interested

<@carlwgeorge:matrix.org>

18:44:13

incus is already in rawhide, with Conan Kudo as a maintainer

<@conan_kudo:matrix.org>

18:44:31

there's a bunch of things that need to get done before I'm comfortable bringing it into EPEL 9

<@nhanlon:beeper.com>

18:44:42

yeah, we've chatted about it before

<@nhanlon:beeper.com>

18:44:52

but already solved a couple issues

<@nhanlon:beeper.com>

18:45:03

https://github.com/lxc/incus/pull/1144/ e.g.

<@salimma:fedora.im>

18:45:22

seems like COPR is being used as intended, then - drive down the list of issues, then branch for EPEL 9 when ready?

<@tdawson:fedora.im>

18:46:37

Thank you Neil Hanlon ... does anyone else have anything to bring up on Open Floor?

<@yselkowitz:fedora.im>

18:46:42

a couple things, I've already pre-typed:

<@tdawson:fedora.im>

18:46:54

yselkowitz: Go for it

<@yselkowitz:fedora.im>

18:46:58

1) ELN Extras has been restarted and has already been helpful in finding bugs in both future EPEL 10 packages as well as in RHEL 10 itself. I'd really like to add more to it with the hope of potentially preempting even more issues. Ultimately, all I need is a list of "end-user" packages (iow the packages that people actually care about, not worrying about their dependencies) and potentially their intended maintainers. With that I could quickly expand ELN Extras and see what we can find.

<@yselkowitz:fedora.im>

18:47:36

2) I'm wondering if an EPEL 10 config in Content Resolver would be helpful. It wasn't possible before but now it should be, albeit with caveats. See https://github.com/fedora-eln/eln/issues/195 for more details.

<@yselkowitz:fedora.im>

18:47:49

that's supposed to be 2, silly client

<@carlwgeorge:matrix.org>

18:48:02

i see 1. and 2. here in element

<@yselkowitz:fedora.im>

18:48:31

I'm using nheko, it's showing 1. and 1. 🤷

<@nirik:matrix.scrye.com>

18:49:04

¯\\\_(ツ)\_/¯ Huh, I see 1 and 2 here in nheko.

<@salimma:fedora.im>

18:49:18

I see 1 and 2 but also on Element

<@rcallicotte:fedora.im>

18:49:18

!hi

<@zodbot:fedora.im>

18:49:19

Robby Callicotte (rcallicotte) - he / him / his

<@salimma:fedora.im>

18:49:24

let me check my Fluffy client

<@tdawson:fedora.im>

18:49:29

<@tdawson:fedora.im>

18:49:29

So, if we create an epel10, would we also create an epel11 ?

<@carlwgeorge:matrix.org>

18:49:32

<@carlwgeorge:matrix.org>

18:49:32

this is a wildly different answer for different people, you'll never get a single list

<@carlwgeorge:matrix.org>

18:49:32

> the packages that people actually care about

<@salimma:fedora.im>

18:49:49

yeah Fluffy shows 1 and 1

<@tdawson:fedora.im>

18:50:01

I'm just thinking, once I get my packages into epel10, I won't need them in eln-extras, but I still want them tracked for epel11.

<@carlwgeorge:matrix.org>

18:50:06

and i thought the whole idea of cr workloads was everyone could put in their own lists as workloads?

<@yselkowitz:fedora.im>

18:50:17

but nobody has

<@carlwgeorge:matrix.org>

18:50:28

i know me and troy have, so not nobody

<@salimma:fedora.im>

18:50:29

wait, what do you mean by nobody

<@salimma:fedora.im>

18:50:35

Neal, me and Davide have several lists

<@conan_kudo:matrix.org>

18:50:58

yeah

<@yselkowitz:fedora.im>

18:51:01

which have been there for a while, but nothing new in the last long time

<@conan_kudo:matrix.org>

18:51:03

what am I chopped lettuce?

<@nhanlon:beeper.com>

18:51:11

😂

<@salimma:fedora.im>

18:51:20

part of the problem, as we discussed in ELN a few weeks ago, is lack of visibility I think?

<@tdawson:fedora.im>

18:51:46

Nothing wrong with chopped lettuce 😀

<@salimma:fedora.im>

18:51:48

so if it becomes a joint ELN/EPEL thing and get documented, there should be more of an uptake

<@nhanlon:beeper.com>

18:52:04

from my perspective.. a. I don't maintain a lot of things right now that I personally benefit from eln-extras (I think?) and 2. my eyes kinda glaze over looking at the CR format...

<@conan_kudo:matrix.org>

18:52:10

Troy Dawson: lettuce is the least appealing vegetable for sandwiches :P

<@salimma:fedora.im>

18:52:11

lettuces outlast prime ministers these days

<@carlwgeorge:matrix.org>

18:52:18

so if i understand you right, you would like to see a push for more workloads to be added to eln-extras in cr. i saw your mailing list post calling for that a few weeks ago. not sure what else we can do, epel maintainers are volunteers and can't be forced to do anything.

<@nhanlon:beeper.com>

18:52:24

you leave crunchy water alone Conan Kudo

<@salimma:fedora.im>

18:52:26

but yeah Iceland lettuce is barely a vegetable. darn you Big Agro

<@conan_kudo:matrix.org>

18:52:40

true

<@yselkowitz:fedora.im>

18:52:42

so is there anything I can do to lower the bar?

<@yselkowitz:fedora.im>

18:53:02

I can write the configs, but ultimately I need the list

<@conan_kudo:matrix.org>

18:53:13

I think we should start documenting this process as part of EPEL itself

<@carlwgeorge:matrix.org>

18:53:21

!link https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/KW2PIQG3N4HX76OFKJJ2RU2JUCTAGHP3/

<@conan_kudo:matrix.org>

18:53:40

and we can pull samples from Davide Cavalca, Michel Lind 🎩, and myself as a starting point for people

<@carlwgeorge:matrix.org>

18:54:09

epel maintainers aren't rhel maintainers. they can't be compelled to do anything. if they don't see value in creating an eln-extra workload, someone has to demonstrate that value to them.

<@nhanlon:beeper.com>

18:54:39

<@nhanlon:beeper.com>

18:54:39

<@nhanlon:beeper.com>

18:54:39

i think guidance, too, on when to putt things in a _$FAS.yaml vs _packagegroup.yaml

<@nhanlon:beeper.com>

18:54:47

<@nhanlon:beeper.com>

18:54:47

<@nhanlon:beeper.com>

18:54:47

i think guidance, too, on when to put things in a _$FAS.yaml vs _packagegroup.yaml

<@conan_kudo:matrix.org>

18:54:54

sure, but making it easy and showing a path to success from it is something we build as we do this

<@carlwgeorge:matrix.org>

18:55:11

yeah a cr onboarding guide doc would be useful

<@conan_kudo:matrix.org>

18:55:15

we are building EPEL 10 now, and I can say with some confidence that it has helped with being aware for the stacks I deal with

<@conan_kudo:matrix.org>

18:55:42

there were some fumbles, but by and large it has been helpful

<@nhanlon:beeper.com>

18:55:51

perhaps a new ebranch feature? `ebranch generate-cr-config` ? 🤔

<@nhanlon:beeper.com>

18:56:50

Carl George you should hear the ones that _don't_ get sent! :D

<@tdawson:fedora.im>

18:57:45

We're getting close to time, does anyone have anything else before we close? Or we can continue with this thread for the last couple minutes.

<@dherrera:fedora.im>

18:57:56

I have something!

<@salimma:fedora.im>

18:57:59

I actually have this in poi-tracker

<@tdawson:fedora.im>

18:58:07

Diego Herrera: Go for it

<@nhanlon:beeper.com>

18:58:23

oh, nice. I will look into that. been trying to convince an internal team to use poi-t

<@salimma:fedora.im>

18:58:29

need to polish it up, it does work but the output currently does not match what Yaakov wants indentation wise (that's why I apckaged yq)

<@salimma:fedora.im>

18:58:45

but let's let Diego speak

<@dherrera:fedora.im>

18:59:12

(would like to put it on tdawson domain, but this will do xD)

<@dherrera:fedora.im>

18:59:12

it's short, mentioning that the willit thing is fixed, and it's being updated here https://dherrerace.github.io/willit-result/

<@dherrera:fedora.im>

18:59:12

that's all

<@zodbot:fedora.im>

18:59:30

jrichardson has already given cookies to dherrera during the F40 timeframe

<@salimma:fedora.im>

18:59:31

can we put it on an official Fedora domain?

<@carlwgeorge:matrix.org>

19:00:10

last thing, imo, just asking people for a list and writing the configs for them is an unsustainable strategy. you want documentation for cr and workloads, a detailed breakdown of the benefits, an onboarding guide, and then convince people to do the steps themselves.

<@tdawson:fedora.im>

19:00:21

Diego Herrera: ++

<@tdawson:fedora.im>

19:01:04

Thank you. I'll see what I can do to pull it into mine, but I agree that getting it into a Fedora domain might be good to.

<@salimma:fedora.im>

19:01:20

what Carl said

<@yselkowitz:fedora.im>

19:01:25

depends how much we want to try to fix before 10.beta

<@salimma:fedora.im>

19:01:25

this should be self service

<@dherrera:fedora.im>

19:01:28

we can talk about this on #epel:fedoraproject.org

<@tdawson:fedora.im>

19:01:57

Looks like our time is up. Thank you all for the dicussions and the work you do for EPEL and it's community.

<@tdawson:fedora.im>

19:02:09

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

<@jrichardson:matrix.org>

19:02:13

Troy Dawson: ++

<@zodbot:fedora.im>

19:02:16

jrichardson has already given cookies to tdawson during the F40 timeframe

<@salimma:fedora.im>

19:02:37

Thanks for chairing Troy, as always

<@tdawson:fedora.im>

19:02:40

!endmeeting