20:00:08 <tdawson> #startmeeting EPEL (2023-06-21)
20:00:08 <zodbot> Meeting started Wed Jun 21 20:00:08 2023 UTC.
20:00:08 <zodbot> This meeting is logged and archived in a public location.
20:00:08 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:08 <zodbot> The meeting name has been set to 'epel_(2023-06-21)'
20:00:10 <tdawson> #meetingname epel
20:00:10 <zodbot> The meeting name has been set to 'epel'
20:00:11 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax23 smooge
20:00:11 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax23 nirik pgreco salimma smooge tdawson
20:00:13 <tdawson> #topic aloha
20:00:26 <rcallicotte> .hi
20:00:27 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:00:28 <smooge> .bye
20:00:32 <rcallicotte> lel
20:00:33 <neil> .hi
20:00:34 <zodbot> neil: neil 'Neil Hanlon' <neil@shrug.pw>
20:00:37 <neil> smooge: noooo
20:00:43 <rcallicotte> s/e/o/
20:00:47 <tdawson> Hi rcallicotte  and neil
20:01:08 <tdawson> smooge: leaving already?
20:01:13 <rcallicotte> this might be a fiesty meeting??
20:01:21 <nirik> morning
20:01:28 <davide> .hello dcavalca
20:01:31 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
20:01:32 <carlwgeorge> .hi
20:01:34 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:01:37 <tdawson> rcallicotte: no, I hope not.
20:01:41 <rsc> .hello robert
20:01:42 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:01:45 <tdawson> Morning nirik
20:01:48 <tdawson> Hello davide
20:01:56 <tdawson> Hi carlwgeorge
20:01:59 <tdawson> Hello rsc
20:02:45 <dherrera> .hi
20:02:46 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:02:52 <tdawson> Hi dherrera
20:04:27 <gotmax23> .hi
20:04:28 <zodbot> gotmax23: gotmax23 'Maxwell G' <maxwell@gtmx.me>
20:04:35 <tdawson> Hi gotmax23
20:04:43 * gotmax23 was catching up on the discussion in #epel
20:04:58 <tdawson> #topic End Of Life (EOL)
20:05:00 <tdawson> RHEL 7 / epel-7 will go EOL on 2024-06-30
20:05:01 <tdawson> CentOS Stream 8 / epel-8-next goes EOL in 2024-05-31
20:05:03 <tdawson> CentOS Stream 9 / epel-9-next goes EOL in 2027-05-31
20:05:22 * gotmax23 apologizes in advanced for any migraine related grumpiness
20:05:42 <tdawson> gotmax23: Well ... at least there is a reason, hopefully we don't add to it.
20:05:51 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:53 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:06:15 <gotmax23> Well, I was grumpy before and now it's worse ;)
20:06:35 <yselkowitz[m]> .hello yselkowitz
20:06:36 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
20:06:38 <tdawson> OK, let's start with out open issue.
20:06:41 <gotmax23> 👋
20:06:42 <tdawson> .epel 230
20:06:43 <zodbot> tdawson: Issue #230: old epel7/8 updates in testing - epel - Pagure.io - https://pagure.io/epel/issue/230
20:06:49 <tdawson> Hello yselkowitz[m]
20:07:06 <tdawson> dherrera: I saw you did some updates, would you care to elaborate?
20:07:17 <gotmax23> All the golang ones should just be unpushed
20:07:17 <dherrera> yeah :
20:07:51 <nirik> I'm happy to unpush updates, as long as there is consensus for what ones. ;)
20:07:52 <dherrera> already commented on all the projects that have active maintainers, some of them have responded
20:08:28 <dherrera> the ones that are listed on the issue are the ones that are orphaned or that are retired in some way or another
20:09:23 <dherrera> I think that it wouldn't harm to manually remove the listed updates :)
20:09:36 <nirik> right, I just wanted to make sure before I unpushed them. ;) and that we are ready for someone to show up complaining that they were using the testing version of xyz
20:10:31 <carlwgeorge> i would hope that anyone willing to install from epel-testing would be understanding of our move to unpush these
20:10:40 <dherrera> I would argue that testing should not be used as a place for distribution... but that's my opinion on that matter
20:11:10 <nirik> I wouldn't disagree. ;)
20:11:34 <smooge> so in the long ago past, epel-testing was assumed by some groups to be a place of distribution for breaking changes or dealing with cantankerous packages
20:11:35 <dherrera> I can open an issue on infra to remove these updates so we can close this ticket :)
20:11:52 <smooge> I did not like this but it was seen as the only way to keep some packages in EPEL
20:12:02 <nirik> I'll put it on my todo for later this week unless objections arise.
20:12:07 <nirik> sure, ticket works. ;)
20:12:12 <tdawson> No objection from me.
20:12:13 <nirik> probibly releng makes more sense.
20:12:25 <smooge> it was a driving reason for playground and other types of possible solutions.
20:12:59 <smooge> I think we should be clear somewhere that EPEL-testing should not be used for this and maintainers should use the breaking process or such
20:13:13 <Eighth_Doctor> .hello ngompa
20:13:14 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:13:15 <smooge> anyway.. I am +1 for removing all these
20:13:34 <tdawson> smooge: I undestand and agree ... do you think that would go in the policy section
20:13:44 <dherrera> from a policies perspective, they can stay in testing until they get the propper karma...
20:13:45 <tdawson> Hello Eighth_Doctor
20:14:06 <dherrera> but the listed ones are either orphaned, retired or their update maintainer left the project
20:14:30 <neil> heya Eighth_Doctor
20:15:05 <carlwgeorge> i support the use case of extending the testing period for an incompatible update, i.e. bumping to a month instead of the usual week.  of course that's not the same thing as abandoning an update for years.
20:16:03 <tdawson> Looking at the policy it says "go to a testing branch for a short time period and then are pushed to the stable branch" ... so it's a matter of determining what a "short period of time" is.
20:16:31 <nirik> it's pretty clearly not a few years. ;)
20:16:37 <tdawson> Yep
20:17:14 <Eighth_Doctor> you mean we shouldn't have updates lasting centuries
20:17:17 <Eighth_Doctor> ?
20:17:22 <neil> HEY ! I was relying on that
20:17:34 <smooge> I would say one RHEL sub-release (aka if it was 9.2 then by 9.3).. so say 6 months
20:17:46 <smooge> 9 months for neil
20:17:46 <carlwgeorge> i agree with the wise smooge
20:18:01 <nirik> ha
20:18:17 * neil starts selling EUS for EPEL
20:18:17 <tdawson> Looking at the policy page ... it needs a cleanup ... the last few paragraphs in https://docs.fedoraproject.org/en-US/epel/epel-policy/#package_maintenance_and_update_policy are clearly back from when we had 2 weeks for and update, and RHEL was released quarterly.
20:19:37 <tdawson> I'm ok with 6 months.  Personally, if my package is there for 2 months, I'm going to unpush it (unless I just forgot about it)
20:19:58 <Eighth_Doctor> I would personally not want anything to run up close against the minor version lifecycle boundary
20:20:22 <Eighth_Doctor> so if we're lengthening something, let's just make it either two weeks or four weeks
20:21:10 <tdawson> We're not really lengthening anything.  that majority of these are back before we had the automatic push turned on.
20:21:20 <nirik> I think weeks is too short... there may be updates you want to get more testing time... but yeah, not hitting the minor release boundy is good.
20:21:58 <nirik> we could (if we wanted) possibly also default to setting time to stable to something... but that would be more intrusive/more work.
20:22:41 <tdawson> I'm not sure I understand.  We already have haven't we?  We have it set to 1 week.
20:22:57 <carlwgeorge> 1 week as a minimum, but we don't define the maximum
20:23:28 <carlwgeorge> i think we could just update the policy to say that updates that aren't pushed to stable after 6 months can be unpushed by releng
20:23:43 <tdawson> I thought if you didn't specifically set no-autokarma, you automatically got one week.
20:23:57 <nirik> yeah, I guess default is set now.
20:24:02 <nirik> but wasn't when these old updates existed
20:24:22 <carlwgeorge> with auto-push disabled, you get a message of "maintainer can push to stable" after a week, but then nothing automatic
20:24:39 <nirik> but auto-push is default right?
20:25:09 <tdawson> nirik: correct
20:25:14 <carlwgeorge> correct, but for incompat updates we require it be unchecked
20:25:26 <carlwgeorge> and if an update gets a -1 then it may get stuck forever
20:25:43 <carlwgeorge> i believe even if the karma giver reverts it to +1
20:26:25 <tdawson> Ya, I wish if the negative karma got unset it would revert back to auto ... but it doesn't.
20:26:59 <nirik> it is supposed to cancel out if you later +1 where you -1'ed
20:27:07 <tdawson> Looking at the time ... do we have anyone who wants to take a stab at giving the policy an update?
20:27:47 <tdawson> We don't have to right now, we can leave it at "a short period of time" ... but we really should update it at some point.
20:28:06 <tdawson> I'm not going to touch it at this time beacause I've already got 3 documentation things I'm working on.
20:28:50 <dherrera> I do like carlwgeorge idea of limiting to 6 months and then they can get unpushed
20:28:58 <dherrera> I can send a PR with that
20:29:08 <tdawson> dherrera: That souns great, thank you.
20:29:21 <tdawson> dherrera: And thank you for all the work you've been doing on this issue.
20:29:35 <dherrera> sure 👍️
20:29:38 <gotmax23> Indeed!
20:30:22 <tdawson> I'm going to move on.
20:30:30 <tdawson> #topic Old Business
20:30:55 <tdawson> Do anyone have any old business they want to bring up?
20:31:42 <smooge> not from me
20:31:45 <neil> nor I
20:31:52 <tdawson> OK, I'll let the old business stay still.
20:31:54 <carlwgeorge> i had one thing
20:32:07 <tdawson> carlwgeorge: Sure thing.
20:32:27 <carlwgeorge> follow up from the gpsd thing we talked about and punted to the packaging committee
20:32:29 <carlwgeorge> https://pagure.io/packaging-committee/issue/1283
20:33:13 <carlwgeorge> fpc agreed with my previous feedback of use the existing options following the rules or use copr
20:33:50 <nirik> and the reporter still would like to just do what they proposed?
20:33:53 <carlwgeorge> the maintainer seems to have commented again pushing back.  not sure if we'll talk about it again at the next fpc meeting, but it's probably a closed issue.
20:34:01 <carlwgeorge> nirik: pretty much
20:34:18 <carlwgeorge> i've got the gpsd-latest review assigned to me, and i'm just going to close it linking back to this fpc issue
20:34:41 <yselkowitz[m]> how is this different from postgresql+libpq?
20:35:10 <carlwgeorge> i don't know enough about how postgresql and libpq are packaged to answer that
20:35:15 <davide> the response in that ticket seems pretty conclusive
20:35:32 <carlwgeorge> my summary would be that a special package name doesn't exclude you from following the updates policy
20:35:32 <davide> I'd say close the review and punt to FPC again if they push back
20:36:27 <nirik> postgresql (well, it's modular in many releases), but non modular just does compat packages no?
20:36:36 <nirik> ie, there's no postgresql-latest
20:36:45 <nirik> it's specific versions right?
20:36:55 <davide> I don't think I've ever seen the -latest pattern in practice tbh
20:37:33 <tdawson> carlwgeorge: Thank you for letting us know the outcome.
20:37:41 <tdawson> Any other old business?
20:38:29 <tdawson> #topic General Issues / Open Floor
20:38:37 <tdawson> Do we have anything for Open Floor?
20:38:44 <yselkowitz[m]> I do
20:38:55 <tdawson> yselkowitz[m]: Go for it
20:38:55 <rsc> Yes.
20:39:08 * rcallicotte gets some popcorn and a soda
20:39:52 <yselkowitz[m]> packages that have in previous RHEL versions are being dropped from ELN in preparation for RHEL 10
20:40:12 <yselkowitz[m]> this makes them candidates for ELN Extras (the future EPEL 10) if there are interested maintainers
20:40:23 <neil> ooh! :D
20:40:26 <davide> do you have a list?
20:41:06 <tdawson> Well, there's libreoffice that I know of.
20:41:13 <yselkowitz[m]> gimp, inkscape, libreoffice are some of the notable ones
20:41:36 <nirik> might be good to post to the list? or have a updated page somewhere?
20:41:37 <neil> maybe worth reaching out to the (forming) libreoffice sig
20:41:50 <tdawson> Oh, that's right ... gimp just barely made it into RHEL 9, so I understand it not making 10.
20:42:08 <yselkowitz[m]> so if there are committed EPEL maintainers for these, we could set up ELN Extras configs for them to put them on track early for EPEL 10
20:42:35 <nirik> is there any howto / doc on how to onboard to ELN extras?
20:42:55 <davide> https://docs.fedoraproject.org/en-US/eln/extras/
20:42:56 <carlwgeorge> fun (not fun) fact, gimp is in a super weird state.  el9 has a pre-release of gimp v3 to avoid python2 and gtk2 deps, but rawhide is still on gimp v2
20:43:19 <rcallicotte> ugh thats crazy
20:43:45 <tdawson> Ya ... all I can say is that if you want to take those packages ... realize that there is a reason RHEL is dropping them.
20:43:50 <neil> something something flatpak something
20:43:53 <neil> or snap, i can't remember
20:44:04 <tdawson> *laughs*
20:44:11 <tdawson> Oh snap ... I forgot. ;)
20:44:50 <nirik> har
20:45:14 <tdawson> yselkowitz[m]: If I remember right, they are also trying to get rid of gtk2 in RHEL 10, correct?
20:45:30 <yselkowitz[m]> correct, only one package left (xsane)
20:45:50 <smooge> honestly that should go
20:46:00 <smooge> and be replaced with Nsane
20:46:12 <nirik> in the membrane
20:46:59 <tdawson> yselkowitz[m]: OK, thank you for letting us know.
20:47:20 <tdawson> rsc also had something ...are ok to move on to it?
20:47:29 <yselkowitz[m]> +1
20:47:30 <gotmax23> Yes
20:47:40 <tdawson> rsc: go for it.
20:47:49 <rsc> tdawson: Can I repeat my question/possible issues from #epel - or would you like to summarize it (maybe with a later status already)?
20:47:59 <tdawson> rsc: Sure
20:48:13 <rsc> (sure to the first or the second part?)
20:48:20 <tdawson> Oh, sorry, sure didn't answer the question. :)
20:48:44 <tdawson> rsc: How about you repeat your question, and we'll start with there.
20:48:49 <jonathanspw> .hi
20:48:50 <zodbot> jonathanspw: jonathanspw 'Jonathan Wright' <jonathan@almalinux.org>
20:48:53 <jonathanspw> I'm way late
20:48:54 <tdawson> Hi jonathanspw
20:48:58 <tdawson> Yes you are
20:49:00 <rsc> My understanding of https://www.redhat.com/en/blog/furthering-evolution-centos-stream is that Red Hat will in the future no longer keep c8/c9 branches on git.centos.org in sync with what they release as RHEL X.Y(.Z) RPMs (c8/c9 branches evaluate to RHEL 8.8.z/9.2.z currently; the RHEL EUS add-on not part of this question), instead they only will push to c8s/c9s branches ("CentOS Stream"), but no
20:49:07 <rsc> longer to c8/c9 branches.
20:49:07 <jonathanspw> Busy day 😄
20:49:10 <rsc> Some others seem to share my understanding and thus estimate (negative) impacts for RHEL 8/9 clones. If this is true and if this change will impact RHEL 8/9 clones (negatively), this finally impacts me as an EPEL contributor relying on RHEL 8/9 clones, given the "Red Hat Developer Subscription" doesn't satisfy my private/personal (non-employer-related) needs (I'm running > 16 systems, others might use
20:49:16 <rsc> ppc64le and/or s390x instead).
20:49:18 <rsc> Another impacting issue would be my backport packages from RHEL to EPEL-1, because of some still existing synchronisation issues where sometimes at least c8s is behind c8 (and where I then would have to rely purely on a maybe-not-up2date c8s branch, if the c8 branch would be dead).
20:49:27 <rsc> And if my understanding is wrong, I really would appreciate a non-marketing-fuzzed, but full, clear, technical clarification sooner or later. I know it's hard to impossible for Red Hat folks here to comment on it, but I would like to have it mentioned nevertheless so that it can be relayed to the correct places inside Red Hat.
20:50:09 <tdawson> OK ... a bit larger than I expected, but ok.
20:50:16 <carlwgeorge> on the impact to your personal needs, that's very much off topic for this meeting
20:50:20 <gotmax23> > will in the future no longer keep c8/c9 branches
20:50:21 <gotmax23> it seems to me this is effective immediately?
20:50:25 * nirik reads wall of text.
20:50:41 <carlwgeorge> on the impact to *-epel packages, will have to do their best based on stream sources.
20:51:28 <carlwgeorge> if anyone isn't comfortable with that then retirement is an option.  we have to make due with what we have.  in most cases it will be easy enough to snatch the stream nvr to keep the *-epel packages up to date.
20:51:49 <tdawson> You are correct, that updates will no longer go to git.centos.org c8/c9 areas.  They will got to gitlab centos-stream area - https://gitlab.com/redhat/centos-stream/rpms
20:51:52 <nirik> yeah, IMHO it's too early to tell all the impacts here. rebuilds may be able to use specific stream commits to keep going... I don't know how practical that will be.
20:54:29 <tdawson> rsc: We talked on the other channel about your CentOS Stream 8 updates not getting out in a timely manner.  In fact, this new change will make that better.  Before, RHEL8 would get developed internally, and then they would throw the specs/patches/source over, and a script put them on git.centos.org. for stream 8, and then we manually put them over to gitlab ... it was frought with bugs and problems.
20:55:46 <tdawson> Nowdays, the RHEL developers develop on Stream 8 just like they do with Stream 9, so the code is there already out and available often before RHEL.
20:56:06 <rcallicotte> I honestly dont see what the problem is with this.
20:56:29 <neil> I can confirm from our perspective that the process with 8 has been much closer with 9 lately and we are not having nearly (if any) issues with sources being out of sync, save for the aforementioned edge cases
20:56:31 <gotmax23> Am I understanding correctly that this is effective immediately? There was an ansible-core Z-Stream update pushed out today without a git.centos.org commit.
20:56:51 <gotmax23> And https://bugzilla.redhat.com/show_bug.cgi?id=2215299 was closed
20:57:00 <carlwgeorge> gotmax23: yes
20:57:02 <neil> it's been going on for at least a few days, yes gotmax23
20:57:02 <tdawson> gotmax23: You are correct.  I think today is when it started.
20:57:08 <gotmax23> It seems quite bad to do this without any advanced notice
20:57:13 <tdawson> Oh ... or this week then.
20:57:14 <nirik> I understand the reasoning, but dislike a lot how it was done. ;)
20:57:20 <neil> We (Rocky) noticed this last night, more or less.. and woke up to the news today
20:57:38 <carlwgeorge> so the bug referenced was actually unrelated, it just didn't get fixed because this change was happening this week
20:58:23 <carlwgeorge> on the "advanced notice" thing, we've already learned that no matter how we announce things, even with a year notice, we get accused of doing things "overnight".  so what's the point?
20:58:40 <tdawson> *laughs* well ... there is that.
20:58:44 <gotmax23> Appeal to futility
20:59:13 <neil> I understand the sentiment, but honestly that's a shitty attitude to have towards a community you're ostensibly trying to earn the trust of, again.
20:59:13 <carlwgeorge> even if the announcement today would have been that source exports would stop with el7 eol in 2024, red hat would still get largely the same criticism
20:59:41 <gotmax23> I disagree. At least rebuilds would've had more time to adapt.
20:59:44 <carlwgeorge> and this is why i said it's impossible for hatter to comment on this
20:59:55 <neil> ?
21:00:04 <carlwgeorge> everyone is frustrated, sorry if that's coming out in my replies
21:00:17 <neil> ah. same.
21:00:22 <smooge> I think its time for all of us to put down our shovels
21:00:26 <neil> and pick up our...
21:00:29 <neil> dancing shoes!
21:00:36 <rcallicotte> deal!
21:00:39 <tdawson> Dance ... the night awy. :)
21:01:10 <smooge> i don't think we are going to solve or help on any part of this. it is what it is and we will all deal with it over the coming months as best we can
21:01:14 <neil> i want to note that I'm glad we _can_ have these discussions without devolving into shouting matches. I appreciate y'all.
21:01:20 <gotmax23> Does Rocky Linux / Almalinux have any plans in place to address this?
21:01:39 <tdawson> The time is up ... thank you all for the discussions.  And I agree with neil ... I'm glad we can have these discussions and be able to keep it civil.
21:01:49 <rsc> tdawson: thank you for answering my lengthy question.
21:01:57 <gotmax23> Fair enough :). Thanks everyone!
21:02:11 <tdawson> We can shift that back over to the regular epel channel ... or whatever is appropriate .
21:02:21 <tdawson> Again, thank you all for all you do for the EPEL community and users.
21:02:23 <smooge> thanks everyone
21:02:26 <tdawson> Talk to you next week.
21:02:33 <tdawson> #endmeeting