Meeting started at 2026-06-03 18:00:36 UTC

The Meeting name is 'EPEL (2026-06-03)'

The Meeting Name is now epel

!hi

Diego Herrera: Diego Herrera (dherrera) - he / him / his

!hi

Carl George: Carl George (carlwgeorge) - he / him / his

Hi Diego Herrera and Carl George

!hi

Robby Callicotte: Robby Callicotte (rcallicotte) - he / him / his

Hi Robby Callicotte

We barely have quorum, but maybe more people will show up ... so let's start

We do have one thing marked with meeting

!epel 366

● **Last Updated:** 4 days ago

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

**epel/steering #366** (https://forge.fedoraproject.org/epel/steering/issues/366):**EPEL minor version retirement timing**

● **Assignee:** Not Assigned

Issue querying Pagure: Issue not found

Carl George: Did you want to lead us in the discussion for this issue?

i filed the issue, but will clarify that i don't feel too strongly either way, but felt it merited discussion

basically right now we retire an epel 10 minor the day the next rhel minor comes out, but that means maintainers have zero warning of when that day is because the rhel schedule isn't public

i don't think it's a big deal, but some are bothered by it

To me, my greatedst issued right now is the amount of work needed to extend the release for a week or two.

To me, my greatedst issue right now is the amount of work needed to extend the release for a week or two.

the amount of work would just be to change the policy document and the retirement sop, for the retirement itself it's the same work just with a delay

the amount of work would just be to change the policy document and the retirement sop, for the retirement itself is the same work just with a delay

Conan Kudo 😌: i know you have thoughts on this one, now's your chance to voice them

!hi

Conan Kudo 😌: Neal Gompa (ngompa) - he / him / his

Hi Conan Kudo 😌

I'd prefer to have a delay window

as I've said before, I'd prefer a one month max window (that is, month of release, EOL 30 days later)

that's basically what we do for fedora, and I think it's reasonable for epel too

weren't you also adamantly against doing anything to support eus to avoid having too many branches?

yes, but a one month flushout isn't that much different than what we do in fedora

My opinion. If it's no extra work, set it for a set day that we know will be after the release. (last day of the month, 15th day of the month)

EUS is a much bigger commitment

and hell no to that

people should pay ISVs for that

my point is that if there is concern about too many branches then we should minimize this potential delay window, a month is too long imo

do we have any packages in epel that trigger critpath?

no

So, May 31 or November 30 ... that way we have a set date and it might extend it 1, 2, or 3 weeks.

then... we can probably get away with two weeks after

my original idea would be that we'd just reach the tail of the month it is released

since rhel is almost never released at the end of the month

picking a set date is a bad idea, since we have no control over the rhel schedule and just have to conform to it

but we could have a floor + tail of the month

picking the end of the month could result in a 1 day delay, which isn't enough for stuff to hit auto stable by time

yes, so a two week floor would work to deal with that

how would that be different from just setting the eol to two weeks after the rhel release day?

something like, "by the end of the month, which could be pushed back if there is less than 2 weeks until that deadline"... right?

yes

exactly

it gives us a reasonable bound of predictability while also giving us the ability to tell people the window of existence

that's too convoluted imo

* status quo, retirement on the day of the next rhel minor release. downsides are maintainers could submit an update within the previous week that don't have time to hit automatic stable by time. that's partially mitigated by the fact that if they are doing the right thing with upgrade path then users just get the update for the next minor version instead.

i see basically two options:

* a firm delay window of say 1-2 weeks. when the rhel minor release happens, we set the eol date 1-2 weeks later in bodhi. maintainers submitting an update after that get the eol warning and ideally don't submit if it's not critical to avoid wasted effort of obsoleted (bodhi term, not rpm) updates. it's consistent and as predicable as we can make it given the rhel schedule constraints.

I think a two week window __after the rhel release__ is the happy path here

indeed

fwiw, so far i haven't heard any complaints from maintainers who submitted updates within the week before retirement who got obsoleted builds. we do send out an email at the start of the month to warn maintainers it's coming soon, so no one can really say they had no idea it was coming.

I agree. If we are going to extend it, 2 weeks is the amount I feel comfortable with.

and the whole question of "if" isn't quite settled. nirik stated in the issue he doesn't think it's worthwhile, and i could go either way. is this a problem worth solving?

!hi

Davide Cavalca: Davide Cavalca (dcavalca) - he / him / his

Hi Davide Cavalca

I could go either way. I don't feel strongly about it. But if we do extend it, I feel 2 weeks is the amount we should extend it.

honestly we could even take it down to 8 days, one day more than the stable by time threshold

if a maintainer can get an update to stable they probably don't care if the release is retired a day later, they likely only care (if they do at all) that the update they submitted doesn't get obsoleted before going stable.

Very true.

should we leave this up for discussion in the issue another week and revisit next week, hopefully with more attendance?

I'm ok with this

actually on second count most people are here now, so we could vote if we want

Jonathan Wright probably is around too

It's hard to give a compelling argument for 2 weeks when I'm ok with either way.

yeah i don't feel the need to strongly advocate for this, just wanted people with concerns to have a chance to voice them and get the rest of the committee's views on it

by my rough counting i think i saw 1 hard yes, 1 soft yes, and the rest meh

sounds about it

if we could change the bodhi warning wording from "will go eol" to "expected to go eol", would that change anyone's outlook?

what i'm thinking is we set the eol date to what we expect it to be, then if it changes we're covered by the wording

not really

because the eol date is when you cut off bodhi update submission

so it doesn't matter how it's worded

the effect is what matters

i'm not following your point, the effect is the same, it gets retired when it gets retired

I'm saying you changing the wording doesn't change my opinion _because_ the effect is the same

the eol date field doesn't actually trigger the retirement, it just triggers the warning

ah, doesn't change your opinion, got it

this has taken up over half the meeting at this point, so i'm ready to table it and encourage folks to voice their opinions in the issue itself

table it meaning put it aside or put it to vote?

(since it can mean both 🤪)

commenting on the issue after the vote would be kinda pointless, so i mean put it aside for at least a week

fine with me

Putting it aside for a week sounds good.

it's not like it's urgent

we have five months before it becomes a problem :P

I encourage those those who have strong opinions to comment in the issue.

(or 5 months and some weeks)

That was the only issue marked with meeting ... moving on to Old Business.

I believe the Committee Elections are considered Old Business.

Although it was stated in the regular EPEL matrix channel, I'd like to announce the winners officially here.

fastest election ever

i'm positive there have been elections before where the number of candidates was equal to the number of seats

oh probably

but it's not _that_ common I think

🎉

Diego Herrera: You have some big shoes to fill, but I'm very sure you'll do a great job.

😁 I'll do my best

Anything else around the elections and/or any old business?

Does anyone have anything for Open Floor?

i have one small thing

Carl George: Go for it.

@phsmoura:fedora.im is joining the epel cle team, so we should have a bit more help in the future

That is great!!

he was already in cle working on infra/releng, so not an increase in cle headcount overall, just more focus on epel stuff

It's always good to have more hands helping EPEL.

Any other Open Floor items before we close the meeting?

Thanks to you all for the good discussions. And thank you for all you do for EPEL and it's community.

I'll talk to ya'll next week.

Thanks Troy ^^

bye everyone. Thx Troy