<@tdawson:fedora.im>
21:00:41
!startmeeting EPEL
<@meetbot:fedora.im>
21:00:42
Meeting started at 2023-12-06 21:00:41 UTC
<@meetbot:fedora.im>
21:00:42
The Meeting name is 'EPEL'
<@tdawson:fedora.im>
21:00:52
!meetingname epel
<@tdawson:fedora.im>
21:00:59
!topic aloha
<@carlwgeorge:matrix.org>
21:01:03
!hi
<@zodbot:fedora.im>
21:01:05
Carl George (carlwgeorge)
<@nirik:matrix.scrye.com>
21:01:37
morning
<@nirik:matrix.scrye.com>
21:01:39
!hi
<@zodbot:fedora.im>
21:01:41
Kevin Fenzi (kevin) - he / him / his
<@dherrera:fedora.im>
21:02:12
!hi
<@zodbot:fedora.im>
21:02:13
Diego Herrera (dherrera) - he / him / his
<@carlwgeorge:matrix.org>
21:02:36
is `!hi` necessary for the meetbot to list you as an attendee?
<@tdawson:fedora.im>
21:02:58
I don't think so, but I'm not sure.
<@smooge:fedora.im>
21:03:58
no clue
<@carlwgeorge:matrix.org>
21:04:07
i'm wondering if i can skip it since i set my display name to my real name here in matrix
<@carlwgeorge:matrix.org>
21:04:17
unless that is client-specific
<@smooge:fedora.im>
21:04:23
hi Larc Egroeg
<@carlwgeorge:matrix.org>
21:04:55
larc is now my spy name
<@nirik:matrix.scrye.com>
21:04:58
looks like it looks up anyone who says anything and prints their fas name in the minutes as attende...
<@tdawson:fedora.im>
21:05:24
!topic End Of Life (EOL)
<@tdawson:fedora.im>
21:05:32
RHEL 7 / epel-7 will go EOL on 2024-06-30
https://endoflife.date/rhel
CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
https://endoflife.date/centos-stream
<@nhanlon:beeper.com>
21:05:55
!hi
<@zodbot:fedora.im>
21:05:56
Neil Hanlon (neil) - he / him / his
<@tdawson:fedora.im>
21:06:09
!topic EPEL Issues https://pagure.io/epel/issues
<@tdawson:fedora.im>
21:06:16
https://pagure.io/epel/issues?tags=meeting&status=Open
<@tdawson:fedora.im>
21:06:44
Looks like we have just one this week, possibly short
<@tdawson:fedora.im>
21:06:56
!epel 262
<@zodbot:fedora.im>
21:06:56
epel #262 (https://pagure.io/epel/issue/262): Proposed incompatible security update (again) for llhttp in EPEL9
<@tdawson:fedora.im>
21:07:49
Has everyone read the email and/or issue yet?
<@tdawson:fedora.im>
21:08:08
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/EL2N7VTEADV3H7KIK6GGLOPDZI3Q6EEE/
<@tdawson:fedora.im>
21:09:14
It looks like Fesco has granted it a permanent exception - https://pagure.io/fesco/issue/3115
<@nirik:matrix.scrye.com>
21:09:18
note that fesco has approved a perm exception here. yeah
<@nirik:matrix.scrye.com>
21:10:29
so anyhow, +1 to the exception, and perhaps we could consider a perm one too.
<@nhanlon:beeper.com>
21:10:35
+1 to all
<@tdawson:fedora.im>
21:10:47
Ditto for me +1
<@salimma:fedora.im>
21:10:57
!hi
<@zodbot:fedora.im>
21:10:58
Michel Lind (salimma) - he / him / his
<@carlwgeorge:matrix.org>
21:11:00
yup, seems simplest to officially extend the fesco exception to epel as well
<@salimma:fedora.im>
21:11:15
sorry, in planning meeting all day today and got a bit distracted
<@conan_kudo:matrix.org>
21:11:16
!hi
<@carlwgeorge:matrix.org>
21:11:16
+1 from me to both this one time and to making it permanent
<@zodbot:fedora.im>
21:11:18
Neal Gompa (ngompa) - he / him / his
<@tdawson:fedora.im>
21:11:29
I'm wondering if we have it in one of our policies that if Fesco gives something a permanent exception, so do we, unless we specifically don't want to.
<@conan_kudo:matrix.org>
21:11:37
I think that's a good idea
<@conan_kudo:matrix.org>
21:11:43
it simplifies things for everyone.
<@carlwgeorge:matrix.org>
21:11:45
i don't believe we cover it anywhere
<@nhanlon:beeper.com>
21:11:45
was about to suggest the same, yep
<@salimma:fedora.im>
21:12:01
yeah in general we should assume fesco rulings apply unless indicated otherwise
<@salimma:fedora.im>
21:12:08
should we update our policies?
<@nhanlon:beeper.com>
21:12:13
if we can't trust fesco, who _can_ we trust :)
<@conan_kudo:matrix.org>
21:12:32
IIRC, pretty much all engineering groups technically root their power in FESCo.
<@conan_kudo:matrix.org>
21:12:41
But most people aren't generally aware of that.
<@tdawson:fedora.im>
21:12:50
!agree The voting was unanamous. We all agree to the exception, and to a permanat exception for llhttp
<@conan_kudo:matrix.org>
21:13:02
is it `!agree`?
<@tdawson:fedora.im>
21:13:07
!agreed The voting was unanamous. We all agree to the exception, and to a permanat exception for llhttp
<@jonathanspw:fedora.im>
21:13:12
!hi
<@zodbot:fedora.im>
21:13:13
Jonathan Wright (jonathanspw)
<@jonathanspw:fedora.im>
21:13:20
sorry i'm late
<@salimma:fedora.im>
21:13:35
speaking of FESCo, election opens next Monday https://elections.fedoraproject.org/about/f39%20fesco%20election
<@salimma:fedora.im>
21:13:49
yours truly is running, but the interviews have not been posted yet
<@tdawson:fedora.im>
21:13:53
!agreed The voting was unanamous. We all agree to the exception, and to a permanat exception for llhttp
<@nirik:matrix.scrye.com>
21:14:08
Conan Kudo it's !agreed
<@conan_kudo:matrix.org>
21:14:09
Is this going to show up twice now?
<@carlwgeorge:matrix.org>
21:14:10
to be fair, when fesco is making decisions, i don't think they intend for it to automatically apply to epel in all cases. the fesco folks here can correct me if i'm wrong.
<@conan_kudo:matrix.org>
21:14:34
In general, we do not assume a difference between Fedora and EPEL unless there's a reason to do so.
<@nirik:matrix.scrye.com>
21:15:08
well, for things like package guidelines thats definitely the case. exceptions... could be?
<@conan_kudo:matrix.org>
21:15:16
Needing to handle them differently has come up so rarely that I can't even really remember the last time we had to.
<@conan_kudo:matrix.org>
21:15:28
Certainly not during my tenure on FESCo.
<@conan_kudo:matrix.org>
21:15:41
But nirik may know more, having done this way longer than I
<@salimma:fedora.im>
21:15:45
if something needs to be done differently it's easier to document it on our (EPEL) side rather than FESCo, right
<@carlwgeorge:matrix.org>
21:15:51
well considering fedora and epel have different update policies, i would not assume a fedora updates policy exception applies to epel
<@conan_kudo:matrix.org>
21:16:24
Both Fedora and EPEL have similar policies for stable releases, though. ABI breakage is not generally wanted without a heads-up.
<@conan_kudo:matrix.org>
21:16:41
The difference is how much people adhere to it :P
<@salimma:fedora.im>
21:16:52
definitely true
<@nirik:matrix.scrye.com>
21:16:57
in any case I don't think fesco minds if we differ, but I think we should be clear about whatever we want to do. ;)
<@conan_kudo:matrix.org>
21:17:32
Yeah, if there's a reason to deviate, we should document separately, but I think to make life simpler for everyone, I'd rather accept FESCo exceptions automatically.
<@conan_kudo:matrix.org>
21:17:45
by default, I mean
<@salimma:fedora.im>
21:17:52
yeah, we should either decide that update exemptions automatically apply, or that they need further vetting. and then document that
<@jonathanspw:fedora.im>
21:17:53
+1
<@conan_kudo:matrix.org>
21:18:54
To clarify my position: I largely view EPSCo as stewards of the "EPEL exceptions" to Fedora policy as part of maintaining the EPEL repository
<@conan_kudo:matrix.org>
21:19:12
so I _generally_ defer to Fedora guidance by default unless there's a reason not to
<@conan_kudo:matrix.org>
21:20:02
we've been through plenty of record-keeping conversions :P
<@carlwgeorge:matrix.org>
21:20:20
i think there are few enough exceptions that we can (and should) vet them to ensure we want to apply each one to epel, i.e. an explicit list of epel exceptions, not automatically passing through fedora ones
<@nirik:matrix.scrye.com>
21:20:38
for example, I am pretty sure kde was granted an exception due to release caidence upstream and I know I got an exception for calibre at one point. Oh well.
<@conan_kudo:matrix.org>
21:20:57
Yes, KDE's exception is documented in KDE SIG's wiki pages and somewhere in the packaging guidelines
<@conan_kudo:matrix.org>
21:21:06
and that was globally throughout Fedora and EPEL
<@carlwgeorge:matrix.org>
21:21:11
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#kde
<@nirik:matrix.scrye.com>
21:22:10
ah, missed it because it was in another section
<@conan_kudo:matrix.org>
21:22:27
one of these days, Troy Dawson and I need to just sit and rewrite that page fully
<@tdawson:fedora.im>
21:22:33
I'm sorta thinking that we're talking past each other, and possibly all saying the same thing, but since there are exceptions and exceptions to exceptions, it's not communicating well. Would someone be willing to type up a pull request for our documentation so we can discuss it better.
<@nirik:matrix.scrye.com>
21:22:46
How about...
<@carlwgeorge:matrix.org>
21:22:46
fwiw, that kde sig update policy does not mention epel
<@carlwgeorge:matrix.org>
21:22:51
https://fedoraproject.org/wiki/SIGs/KDE/Update_policy
<@zodbot:fedora.im>
21:22:55
neil gave a cookie to tdawson. They now have 60 cookie(s), 4 of which were obtained in the Fedora 39 release cycle
<@nirik:matrix.scrye.com>
21:23:11
we approve this one time exception and discuss further how we want to handle perm exceptions on list?
<@conan_kudo:matrix.org>
21:23:25
https://fedoraproject.org/wiki/SIGs/KDE/EPEL#Update_Schedule
<@carlwgeorge:matrix.org>
21:23:44
ah, different page
<@conan_kudo:matrix.org>
21:23:51
Again, incoherent.
<@conan_kudo:matrix.org>
21:24:03
We need to fix it.
<@carlwgeorge:matrix.org>
21:24:11
yeah, might be worth considering combining those
<@conan_kudo:matrix.org>
21:24:27
Exactly.
<@conan_kudo:matrix.org>
21:24:39
We have unified our maintenance strategy, and so these pages need to be merged and reworked.
<@carlwgeorge:matrix.org>
21:24:55
i already owe y'all too many docs prs, so i'll steer clear of volunteering for this one
<@tdawson:fedora.im>
21:25:14
nirik: Correct. This particular exception has been approved. Do we have a volunteer to draft a update?
<@tdawson:fedora.im>
21:25:55
I would volunteer, but I can't promise much of anything until beginning of next year (2024)
<@smooge:fedora.im>
21:26:16
Going back to what nirik said.. approve this and move along
<@tdawson:fedora.im>
21:26:27
Moving on :)
<@conan_kudo:matrix.org>
21:26:29
I could do it.
<@salimma:fedora.im>
21:26:47
I owe several docs PRs too so I'll punt on this as well
<@conan_kudo:matrix.org>
21:26:49
I can write up exception policy guidance as a PR that we can discuss more concretely.
<@tdawson:fedora.im>
21:27:11
Conan Kudo: Thank you
<@tdawson:fedora.im>
21:27:56
!topic Old Business
<@tdawson:fedora.im>
21:28:15
Does anyone have any old business they want to bring up?
<@carlwgeorge:matrix.org>
21:29:00
friendly ping to nirik on https://pagure.io/releng/issue/11787
<@nirik:matrix.scrye.com>
21:29:26
I accept your ping and forward it to jednorozec who said he would do this. ;)
<@nirik:matrix.scrye.com>
21:29:31
I'll poke on ticket
<@carlwgeorge:matrix.org>
21:29:38
works for me
<@tdawson:fedora.im>
21:29:49
Any other Old Business ?
<@tdawson:fedora.im>
21:30:33
Not even anything from the young wippersnappers ... ok, moving on.
<@carlwgeorge:matrix.org>
21:30:36
even better 😀
<@tdawson:fedora.im>
21:30:56
!topic General Issues / Open Floor
<@jonathanspw:fedora.im>
21:31:13
I'm happy to report that EPEL support has been added to AlmaLinux ELevate :D
<@nhanlon:beeper.com>
21:31:20
I figured you had that portion covered ;)
<@jonathanspw:fedora.im>
21:31:21
So EPEL is no longer a blocker for folks looking to elevate.
<@smooge:fedora.im>
21:31:23
congrats
<@nhanlon:beeper.com>
21:31:33
congrats, nice work
<@tdawson:fedora.im>
21:31:57
cool
<@jonathanspw:fedora.im>
21:32:02
EPEL support is only for cent7 -> alma 8 right now but the other EL derivatives are coming soon.
<@nirik:matrix.scrye.com>
21:32:04
🛗!
<@conan_kudo:matrix.org>
21:32:11
woot!
<@carlwgeorge:matrix.org>
21:32:22
hopefully this results in more alma devs contributing to epel packages as they notice upgrade path issues
<@carlwgeorge:matrix.org>
21:33:46
i definitely prefer fresh installs, but i'm not against major version upgrades
<@tdawson:fedora.im>
21:34:02
I agree with you. To me it's a chance to ensure everything is cleared up ... but ya ... others don't agree alot.
<@conan_kudo:matrix.org>
21:34:02
if you are made of money, fresh installs are great :)
<@conan_kudo:matrix.org>
21:34:21
most people... are not made of money and do not have oodles of hardware :)
<@nhanlon:beeper.com>
21:34:21
i'm not sure how those are related, but ok
<@salimma:fedora.im>
21:34:53
we generally reimage, but do our initial spin ups of new releases by upgrading in place, so there's room for both
<@nhanlon:beeper.com>
21:35:13
regardless, i didn't meant to rabbit hole us, sorry. That's genuinely awesome news about elevate
<@tdawson:fedora.im>
21:35:48
Any other things for Open Floor?
<@conan_kudo:matrix.org>
21:35:49
typically, I see reprovisioning in environments where there's more hardware to throw at the problem or systems are designed with enough system / data separation that it's easy to do
<@carlwgeorge:matrix.org>
21:35:49
dying on hills tends to generate discussion 😉
<@conan_kudo:matrix.org>
21:36:00
otherwise, in-place upgrades it is
<@nhanlon:beeper.com>
21:36:07
i was _hoping_ i'd be ignored and allowed to decompose!
<@carlwgeorge:matrix.org>
21:36:22
i got one thing
<@tdawson:fedora.im>
21:36:38
Carl George: Go for it.
<@carlwgeorge:matrix.org>
21:37:19
> wild idea: an policy that allows members of the epel-packagers-sig to request epel*-next branches on any package that already has epel* branches
<@michel:one.ems.host>
21:37:49
I'm in favor, we would have mailman in epel9 already if not for this
<@carlwgeorge:matrix.org>
21:38:32
i've run into a case where a maintainer was having trouble understanding what epel next is, and took several back and forth comments to eventually get the epel9-next branch added https://bugzilla.redhat.com/show_bug.cgi?id=2245057
<@tdawson:fedora.im>
21:38:35
I thought this wasn't really a policy thing as much as a releng scripts thing.
<@michel:one.ems.host>
21:38:37
we're pretty much like provenpackagers in the epel* scope except we need to deal with branching and provenpackagers don't on the fedora side
<@michel:one.ems.host>
21:38:51
and this will reduce the burden on releng having to deal with escalations
<@tdawson:fedora.im>
21:39:24
That didn't come out correctly ... I think even if you are a proven packager, you cannot request a epel*-next branch.
<@nirik:matrix.scrye.com>
21:39:26
it could definitely be misused, but then there would be a clear record of who did it. ;)
<@smooge:fedora.im>
21:39:41
I think you mean "requests for epel-next packages can be approved if there are existing epel-* branches". I mean anyone can currently request things.. whether the script gods will accept is another matter :)
<@carlwgeorge:matrix.org>
21:39:44
correct
<@michel:one.ems.host>
21:40:11
Troy Dawson: true. but proven packagers don't need to deal with branching on Fedora, while on epel we don't do auto branching so this is an issue
<@carlwgeorge:matrix.org>
21:40:34
exactly, right now it can be requested, and the toddler will reject it if you aren't a maintainer, collaborator, or in a group that is one of those
<@michel:one.ems.host>
21:40:41
this seems a halfway compromise between "just autobranch if there's already an epel branch" and "no you must be in teh ACL or ask to be first"
<@carlwgeorge:matrix.org>
21:41:31
i'm suggesting a code change to the toddler that will let some group (either epel-packagers-sig or proven packagers) to get epel*-next branches in cases like this
<@michel:one.ems.host>
21:41:49
only epel*-next or epel* too?
<@nirik:matrix.scrye.com>
21:41:57
of course in the end you should still explain to the maintainer whats going on, no?
<@carlwgeorge:matrix.org>
21:41:58
definitely just epel*-next
<@carlwgeorge:matrix.org>
21:42:32
of course, it should still start with a ticket and discussion, but say after a week or something it could move forward without the maintainer
<@michel:one.ems.host>
21:42:36
for epel10 I personally will likely not care that much about non-stream, except for the mailman stack I guess
<@carlwgeorge:matrix.org>
21:43:09
for epel10 it's not a problem because we'll have the leading branch already, and provenpackagers can fix any issues like this without delay
<@nirik:matrix.scrye.com>
21:43:19
I'm not opposed. I could see it being useful where maintainer doesn't know yet whats going on and something has to be done quickly, or maintainer doesn't care and is happy to let someone else do it.
<@nirik:matrix.scrye.com>
21:44:22
and yeah, come on epel10.... hurry up and get here. ;)
<@carlwgeorge:matrix.org>
21:44:34
similar to the provenpackager policy, we can say that <empowered group> should communicate with the maintainer first
<@carlwgeorge:matrix.org>
21:45:15
specifically this part:
> Prior to making changes, provenpackagers should try to communicate with owners of a package in bugzilla, dist-git pull request, IRC, matrix, or email. They should be careful not to change other people’s packages needlessly and try to do the minimal changes required to fix problems
<@nirik:matrix.scrye.com>
21:45:59
+1
<@carlwgeorge:matrix.org>
21:46:04
so if no one is opposed, my question is should we reserve this for provenpackagers, or members of the epel-packagers-sig
<@carlwgeorge:matrix.org>
21:46:15
either one works for me honestly
<@tdawson:fedora.im>
21:46:47
I'm ok with either one.
<@jonathanspw:fedora.im>
21:46:52
I'd say both
<@nhanlon:beeper.com>
21:46:54
+1 from me on either
<@jonathanspw:fedora.im>
21:46:56
Or, either
<@jonathanspw:fedora.im>
21:46:57
semantics
<@nhanlon:beeper.com>
21:47:08
(or both ;) )
<@jonathanspw:fedora.im>
21:47:09
If a user is in either group, let them do it.
<@salimma:fedora.im>
21:47:57
yeah, either
<@carlwgeorge:matrix.org>
21:48:08
i said i'm ok with both, but maybe epel-packagers-sig is the more logical choice. sometimes i'm surprised by who i see is provenpackager.
<@nirik:matrix.scrye.com>
21:48:12
worth pondering on.
<@salimma:fedora.im>
21:48:20
hmm good point
<@smooge:fedora.im>
21:48:33
hey just because they let me into Proven Packagers once.. doesn't mean they are all bad
<@dherrera:fedora.im>
21:49:15
so... should this get requested as a FESco ticket? or can we simply decide on this here?
<@salimma:fedora.im>
21:49:21
the barrier of entry for epel-packagers-sig is quite reasonable, and there's already weird backlash against provenpackagers in Fedora, maybe making it epel-packagers-sig first is a good start
<@tdawson:fedora.im>
21:49:39
I'm ok with just epel-packagers-sig
<@carlwgeorge:matrix.org>
21:49:42
that's exactly what i had in mind
<@carlwgeorge:matrix.org>
21:50:25
did we ask fesco for permission for users to be able to untag their own epel-next builds? this fits in the same sort of bucket i think.
<@tdawson:fedora.im>
21:50:45
Diego Herrera: I believe we have to decide on it here. It's a unique EPEL thing.
<@nirik:matrix.scrye.com>
21:50:58
to be fair, I think that was orig a misconfiguration on the epel-next tags. ;)
<@tdawson:fedora.im>
21:51:22
shhh .... not so loud. :)
<@nirik:matrix.scrye.com>
21:51:28
ha
<@carlwgeorge:matrix.org>
21:51:29
so vote time?
<@nirik:matrix.scrye.com>
21:52:17
I'd vote -1 right now... not because I don't like it, but because I don't like proposing new non time sensitive things, discussing them and approving them all in the same meeting
<@tdawson:fedora.im>
21:52:25
I'd feel better with an issue and an official vote next week. Because this is going to need to be somewhere we can point to for releng.
<@carlwgeorge:matrix.org>
21:53:02
well to be fair i quasi-proposed it in the main channel last week, but sure i can file an issue
<@smooge:fedora.im>
21:53:06
agreed
<@smooge:fedora.im>
21:53:09
with nirik
<@smooge:fedora.im>
21:53:28
this needs a) a ticket b) some discussion and c) a vote
<@carlwgeorge:matrix.org>
21:54:19
alongside the ticket i'll make a discussion thread
<@carlwgeorge:matrix.org>
21:54:35
alongside the ticket i'll make a discussion.fpo thread
<@tdawson:fedora.im>
21:54:56
Carl George: Thank you
<@tdawson:fedora.im>
21:55:07
Any other Open Floor items before we run out of time?
<@tdawson:fedora.im>
21:56:22
Thank you all for comming and for the good discussions.
<@jonathanspw:fedora.im>
21:56:35
y'all have a good rest of the week!
<@nhanlon:beeper.com>
21:56:37
Thank you Troy Dawson for running and being awesome as always! :)
<@nhanlon:beeper.com>
21:56:43
have a good wednesday y'all
<@smooge:fedora.im>
21:56:44
thanks troy
<@tdawson:fedora.im>
21:56:49
And thank you all for all your for on EPEL and it's community.
<@dherrera:fedora.im>
21:56:51
thanks troy :D
<@tdawson:fedora.im>
21:56:54
Talk to you next week.
<@tdawson:fedora.im>
21:57:09
!endmeeting