21:00:14 <tdawson> #startmeeting EPEL (2023-02-08)
21:00:14 <zodbot> Meeting started Wed Feb  8 21:00:14 2023 UTC.
21:00:14 <zodbot> This meeting is logged and archived in a public location.
21:00:14 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
21:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:14 <zodbot> The meeting name has been set to 'epel_(2023-02-08)'
21:00:15 <tdawson> #meetingname epel
21:00:15 <zodbot> The meeting name has been set to 'epel'
21:00:17 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge
21:00:17 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson
21:00:18 <tdawson> #topic aloha
21:00:19 <rsc> .hello robert
21:00:20 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
21:00:29 <tdawson> Hello rsc
21:00:41 <carlwgeorge> .hi
21:00:41 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
21:00:47 <tdawson> Hi carlwgeorge
21:02:03 <yselkowitz[m]> .hello yselkowitz
21:02:03 <gotmax23> .hi
21:02:04 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
21:02:10 * gotmax23 is multitasking
21:02:11 <salimma> .hi
21:02:12 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
21:02:13 <tdawson> Hi gotmax23
21:02:20 <tdawson> Hi salimma
21:02:29 <tdawson> Hello yselkowitz[m]
21:02:47 * gotmax23 waves to tdawson and Michel Alexandre Salim 🎩
21:02:55 <gotmax23> .hello2
21:02:56 <zodbot> gotmax23: gotmax23 'Maxwell G' <gotmax@e.email>
21:03:06 <gotmax23> there we go!
21:03:15 <tdawson> :)
21:03:21 <nirik[m]> morning
21:03:29 <tdawson> Morning nirik[m]
21:04:20 * salimma waves to all
21:04:28 * tdawson wonders if Eighth_Doctor is going to show today
21:04:48 <Eighth_Doctor> .hello ngompa
21:04:49 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
21:04:59 <tdawson> Ah ... I thought I heard a tardis
21:05:03 <tdawson> Hello Eighth_Doctor
21:05:16 <tdawson> #topic End Of Life (EOL)
21:05:17 <tdawson> RHEL 7 will go EOL on 2024-06-30
21:05:19 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
21:05:20 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
21:05:23 <Eighth_Doctor> hey
21:05:41 <salimma> 8 before 7 is a bit funny still :)
21:06:22 <tdawson> Next year is going to be quite the year.  Retire two, start one.
21:06:42 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
21:06:43 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
21:06:48 <salimma> Davide sends his regrets, today is the monthly clash with the CentOS Board
21:06:53 <nirik[m]> take on down, pass it around, 99 distros of beer on the wall..
21:07:05 <carlwgeorge> also pablo mentioned to me that he wasn't going to be able to make it either
21:07:23 <tdawson> OK
21:07:34 <tdawson> So, we do have one issue to discuss
21:07:39 <tdawson> .epel 221
21:07:40 <zodbot> tdawson: Issue #221: Should be providing bind9-next alternative to RHEL bind package allowed? - epel - Pagure.io - https://pagure.io/epel/issue/221
21:08:21 <tdawson> I'll be honest, I don't see much to discuss.  To me it looks like "no"
21:08:53 <carlwgeorge> agreed, but i would like to use it as a spring board for clarifying the policy
21:09:35 <nirik[m]> yeah, I agree with the comments you all added.
21:09:48 <nirik[m]> if it didn't conflict it would be one thing...
21:10:07 <salimma> seems like a clear no to me too
21:10:08 <Eighth_Doctor> likewise
21:10:08 <salimma> that being said I have a related issue to bring up when we get to open floor
21:10:10 <Eighth_Doctor> I actually know of one other package we probably should yank from EPEL based on this policy too
21:10:26 <salimma> ah, which?
21:10:29 <carlwgeorge> i think reasonable people could disagree on whether providing the stock name counts as "only enhance and never disturb" or not, so it would be best to call it out in the policy as not allowed
21:10:47 <Eighth_Doctor> jack-audio-connection-kit
21:10:56 <carlwgeorge> i put four bullet points in my last comment there, does anyone disagree with those?
21:11:17 <tdawson> I just re-read the policy, and you are right, we might need to clarify.  Because as far as I see, we only say we don't conflict with "package names", not with the files.
21:11:33 <rsc> I'm not sure if -devel is a practical issue outside of buildroots...
21:11:33 <nirik[m]> nope. +1 on those
21:11:33 <gotmax23> I wish there was some way to provide compat packages in EPEL. Modularity allowed this in some cases, but it brought along more problems...
21:11:42 <gotmax23> * in EPEL in certain cases. Modularity
21:12:01 <tdawson> My mind implies "enhance and never distrurb" as meaning we don't replace real RHEL files.  But we don't actually say that.
21:12:03 <Eighth_Doctor> since RHEL 9 provides pipewire-jack
21:12:04 <nirik[m]> gotmax: well, you can, but you have to make them not conflict. Sometimes thats... not at all easy
21:12:05 <Eighth_Doctor> which provides some of the files that jack-audio-connection-kit does
21:12:17 <salimma> if both provide a generic virtual provides that's one thing, but providing the actual package name (and shipping similar files)... uh
21:12:28 <gotmax23> nirik: yup, not possible in many cases.
21:12:48 <Eighth_Doctor> I always assumed we don't replace real RHEL files
21:12:49 <nirik[m]> yeah. ;(
21:12:50 <salimma> if clarifying the policy helps, we should certainly do that and make it explicit
21:12:50 <gotmax23> in any case, I agree this is against the (spirit of the) policy
21:13:01 <salimma> but yeah, meanwhile let's say no to this
21:13:18 <carlwgeorge> and clarifying the policy doesn't mean that we can't make exceptions, such as that jack stuff
21:13:37 <Eighth_Doctor> fwiw, I've been working around this in my EPEL packages by explicitly pulling in the pipewire version of the jack stuff at build time
21:13:38 <carlwgeorge> i'm not sure it's justified in that case, but maybe it is
21:13:39 <Eighth_Doctor> otherwise the wrong thing gets linked :(
21:14:19 <Eighth_Doctor> sure, we need to have clarity on this front and probably just be straight up more explicit about the spirit of this rule
21:14:40 <Eighth_Doctor> because we can't cover every potential case there
21:14:52 <Eighth_Doctor> like "technically" the jack case is allowed, but it probably shouldn't be because it causes weird misfires in practice
21:15:03 <tdawson> Does anyone want to volunteer to clarify the policy?
21:15:13 <carlwgeorge> myself and tdawson are in the midst of some doc restructuring, we could include this clarification as part of that
21:15:32 <tdawson> carlwgeorge: Ya, I was about to volunteer for it.
21:15:34 <carlwgeorge> unless we want to get a policy clarification out first
21:15:59 <tdawson> I think getting this out sooner rather than later would be good.
21:16:05 <nirik[m]> it's waited this long. I don't think it's any kind of urgent
21:16:12 <Eighth_Doctor> we can say no to this ticket and then put out the clarification, then re-evaluate the epel package set later
21:16:24 <Eighth_Doctor> there's no rush in particular on any of these things
21:16:49 <salimma> yeah, agreed with Conan Kudo
21:16:50 * nirik[m] nods
21:16:50 <salimma> no reason to delay saying no to the ticket
21:16:50 <salimma> the clarification, let's do it properly and not rush it
21:17:12 <carlwgeorge> i'm kinda curious how bind9-next pass fedora package review
21:17:14 <Eighth_Doctor> but knowing we have two discrete cases we need to think about helps with figuring out the policy
21:17:46 <tdawson> It's not that I'm planning on rushing it.  I just don't want it to get lost in the restructure work that carlwgeorge and I are working on.
21:17:55 <carlwgeorge> tdawson: exactly
21:18:21 <nirik[m]> it's fine for fedora.
21:19:43 <tdawson> Let's do a quick vote, on the issue itself.  All in favore of saying "No" to bind9-next
21:20:03 <salimma> +1
21:20:03 <carlwgeorge> +1
21:20:03 <salimma> (uh +1 means no right)
21:20:04 <nirik[m]> +1 to no
21:20:12 <tdawson> +1 to no
21:20:17 <tdawson> salimma: correct
21:20:43 <carlwgeorge> maybe we should do over the vote to invert so the answer is clear
21:21:05 <carlwgeorge> the subject is "Should be providing bind9-next alternative to RHEL bind package allowed?", and i think we're agreeing the answer should be no
21:21:22 <gotmax23> +1 to denying bind9-next
21:21:23 <Eighth_Doctor> +1
21:21:36 <yselkowitz[m]> I think there is a consensus
21:22:02 <salimma> I think it's clear enough though, the only people voting before me was nirik and Carl
21:22:04 <gotmax23> carlwgeorge:  I don't care how it's displayed in the end. We agree that it shouldn't be allowed.
21:22:17 <tdawson> Yep ... although I wording it poorly, I believe the consensus is that we shouldsn't allow it.
21:22:37 <gotmax23> meh, that came out wrong. I just mean we don't need to revote.
21:22:40 <nirik[m]> right
21:22:47 * gotmax23 nods
21:23:41 <tdawson> #info Vote on "Should be providing bind9-next alternative to RHEL bind package allowed?" - 0 Yes -  6 No
21:24:28 <tdawson> carlwgeorge: Do you mind putting that on the issue?
21:24:35 <Eighth_Doctor> wouldn't we use #agreed for this?
21:24:48 <carlwgeorge> sure, i can.  might as well pull the bodhi update too.
21:24:50 <tdawson> Oh ... we would if I knew of that. :)
21:25:50 * tdawson puts #agreed on his cheat sheat.
21:26:12 * carlwgeorge is curious how that shows up in the meeting summary later
21:27:03 <tdawson> #info tdawson volunteered to draft a miror revision of the policy that explains better what "EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were built for." means.
21:27:32 <tdawson> #undo
21:27:32 <zodbot> Removing item from minutes: INFO by tdawson at 21:27:03 : tdawson volunteered to draft a miror revision of the policy that explains better what "EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were built for." means.
21:27:42 <tdawson> #info tdawson volunteered to draft a minor revision of the policy that explains better what "EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were built for." means.
21:28:05 <tdawson> Anything else on this before we move on?
21:28:38 <tdawson> #topic Old Business
21:29:00 <tdawson> #info EPEL 10 proposal https://discussion.fedoraproject.org/t/epel-10-proposal/44304
21:29:15 <tdawson> I'll turn this over to carlwgeorge
21:29:58 <carlwgeorge> i see tdawson commented shortly before the meeting about a roll back plan.  i can write something up and add it there as a comment.
21:30:36 <salimma> should we still vote now, or do we want to wait until we have details about rolling back?
21:30:39 <carlwgeorge> basically that would look like retiring all the epel10.x branches that exist, changing the epel10 branch to build against rhel instead of centos, and setting up the epel10-next build targets
21:31:19 <salimma> that seems clear enough to vote on
21:31:41 <carlwgeorge> basically switch back to the epel/epel-next structure, undoing the things that are different
21:32:00 <carlwgeorge> of course will all appropriate announcements and documentation changes
21:32:04 <nirik[m]> Personally, I think this will be more releng work, but I hope some folks will help with that part... and it might be confusing for maintainers/users, but I think if we provide lots of docs with examples everyone should get the hang of it. I'm game to give it a try and if it doesn't work out we can always punt back...
21:32:29 * carlwgeorge volunteers
21:32:53 <salimma> if there's anything non-RH folks can help with, I'm happy to help. this will save time down the road
21:33:19 <salimma> caveat: I'm off for a month mid-March to mid-April :)
21:33:21 <nirik[m]> I think just some simple examples will go a long way... ie, "I'm a maintainer, what do I do" etc
21:33:21 <carlwgeorge> as part of the doc restructure i mentioned, i'd like to work in some workflow guides.  we already could use it for epel-next, and even with the proposal we'd need it to explain how 9 and 10 workflows differ.
21:34:59 <tdawson> Are we ready to vote?  Or do we want to discuss any of the points?
21:35:14 <carlwgeorge> if we're going to vote on something today, i suggest that we vote on the general direction, not necessarily any of the specific implementation details
21:35:43 <nirik[m]> +1 to the general idea.
21:35:45 <carlwgeorge> i.e. yes or no to epel10 having a repo per minor version, as that's the core of the proposal
21:36:06 <salimma> +1 to the general idea
21:36:07 <salimma> (just to make it clear that we agree it's a good idea to proceed)
21:37:14 <tdawson> +1 to the general idea
21:37:22 <dherrera> +1
21:37:37 <dherrera> (hi btw)
21:38:08 <salimma> hi Diego!
21:38:27 <tdawson> Eighth_Doctor: A few weeks ago I know you had some concerns, and I haven't heard you say anthing during this dicussion.  Have your concerns been addressed, or are you typing a really long question/concern?
21:38:35 <tdawson> Hi dherrera
21:38:58 <Eighth_Doctor> I don't feel like they're addressed
21:39:01 <salimma> fwiw I'm on the Matrix side and Neal only started typing just now
21:39:11 <salimma> is there a TL;DR?
21:39:21 <Eighth_Doctor> (I'm juggling the CentOS Board and EPEL meeting at once)
21:39:24 <carlwgeorge> Eighth_Doctor: i asked some follow up questions in discourse but never saw you reply
21:39:42 <Eighth_Doctor> yeah, real-life things got in the way
21:40:04 <Eighth_Doctor> as now the cat's out of the bag, I left my previous employer and joined Red Hat this week
21:40:12 <Eighth_Doctor> that has sucked almost all of my time and energy for the past month
21:40:51 <Eighth_Doctor> I'm currently deeply underwater in new-hire things
21:41:11 <carlwgeorge> ah yes, the new hire firehose
21:41:53 <carlwgeorge> correct me if i'm wrong, but those concerns were all on the finer details, not really disagreeing with the overall direction, right?
21:43:54 <carlwgeorge> as miro said recently on the thread, there seem to be lots of likes and no real objections, just implementation details.  which is partially why i want to limit the scope of the current vote to the overall idea.  i don't want the idea held hostage over a small detail, and i don't want people with concerns to feel that they're not being heard.
21:44:44 <nirik[m]> I'm sure we will adjust / tweak / fix things as we move along...
21:44:59 <yselkowitz[m]> if there are still implementation details to work out, then what exactly are you voting on today?
21:45:47 <carlwgeorge> yes or no to epel10 having a repo per minor version
21:45:55 <tdawson> yselkowitz[m]: Whether we would move forward to work out those implementation details, or if we should just drop it.
21:46:05 <yselkowitz[m]> this sounds like a vote on second reading then
21:46:46 * salimma hasn't brushed up on parliamentary procedures
21:46:54 <tdawson> *laughs*
21:47:16 <carlwgeorge> if everyone hated it and we decided to stick with the epel-next model for 10, i don't think the world would fall apart.  we would just keep having the same issues we have now.
21:48:02 <carlwgeorge> or if we started implementing it, decided it won't work, and did the roll back plan
21:48:32 <tdawson> I don't hate it.  Honestly it feels like it was written for me, cuz it goes along with my workflow.  But that makes me nervous that others won't like that workflow.
21:48:57 <carlwgeorge> the kde issues people see were a big inspiration
21:50:32 <salimma> wearing my work hat, this is nice since we don't have to make a special branch for next if something breaks in our cXs install
21:50:56 <salimma> wearing my Fedora hat, sometimes Rust packaging gets blocked as crates start requiring new compilers, and we juggle too many branches already we'd prefer not to cut -next branches, so this also helps :)
21:51:51 * carlwgeorge was confused about "second reading" but finally googled it
21:51:55 <tdawson> It's getting late in the meeting.  Thus far we have 5 +1 for the general idea.  Nobody has said "No" to the general idea.  But we have 2 that haven't said either way.
21:52:51 <tdawson> And smooge isn't here, so he would be an absentee.
21:53:30 <tdawson> I'm going to call it, that it passed.
21:53:33 <rsc> Personally, I'm torn (if that's the correct word): It adds more complexity for EPEL packagers, but also more flexibility. But it seems to add more complexity for EPEL users, right?
21:54:04 <carlwgeorge> for most users i would think no
21:54:10 <salimma> it should be transparent from the user POV right?
21:54:44 <salimma> I almost never poke into exactly where the repos point to on my system provided they work
21:54:45 <carlwgeorge> centos users and rhel rebuild users would just run `dnf install epel-release` like always and they should get the correct package
21:54:55 <carlwgeorge> *always have
21:55:58 <rsc> Really? I refer to "epel-release-centos and epel-release-rhel"
21:56:20 <carlwgeorge> yes, both would provide epel-release i think for compat
21:56:44 <salimma> rsc: this is already the case now, right
21:56:45 <carlwgeorge> centos would only put epel-release-centos in it's extras repo, and rhel rebuilds would only put epel-release-rhel in their extras repo
21:56:45 <salimma> if you're on stream you need to install epel-next-release which pulls in epel-release
21:57:20 <carlwgeorge> other way around was the intent, epel-release recommends epel-next-release if centos-stream-release is installed
21:57:30 <carlwgeorge> but i guess it works the way you described too
21:57:34 <yselkowitz[m]> table until next time?
21:57:43 <carlwgeorge> for maintainers i don't think this adds more complexity per say, it trades the epel-next complexity for a different complexity that is arguable easier to get right by accident
21:58:35 <carlwgeorge> i'm happy to revisit this at future meetings, or carry on the conversation in discourse
21:58:57 <carlwgeorge> i'll be replying there anyways about the rollback plan
21:59:12 <tdawson> carlwgeorge: Well ... think about asking for a package to be branched for a package you want available for RHEL right now.  "Please banch foo for RHEL 10, 10.5 and 10.6"
21:59:35 <tdawson> sorry /RHEL/EPEL/
21:59:49 <yselkowitz[m]> we're out of time folks
22:00:07 <tdawson> Yep, let's table this until next week.
22:00:34 <tdawson> Thank you all for comming and for the good discussions.  And thank you for all you do for EPEL and it's community.
22:00:46 <carlwgeorge> tdawson: it wouldn't be 10.5 and 10.6 simultaneously, so at most two branch requests, same as if a package depends on a library that is different in centos and and epel9-next branch is needed
22:01:06 <gotmax23> Would epel-release-centos Obsolete epel-next-release?
22:01:18 <tdawson> carlwgeorge: I'll explain my thinking in discourse.
22:01:33 <carlwgeorge> gotmax23: i don't think so
22:01:46 <tdawson> #endmeeting