20:00:18 <tdawson> #startmeeting EPEL (2022-07-13)
20:00:18 <zodbot> Meeting started Wed Jul 13 20:00:18 2022 UTC.
20:00:18 <zodbot> This meeting is logged and archived in a public location.
20:00:18 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:18 <zodbot> The meeting name has been set to 'epel_(2022-07-13)'
20:00:19 <tdawson> #meetingname epel
20:00:19 <zodbot> The meeting name has been set to 'epel'
20:00:20 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca
20:00:20 <zodbot> Current chairs: carlwgeorge dcavalca nirik pgreco salimma tdawson
20:00:22 <tdawson> #topic aloha
20:00:30 <pgreco> .hi
20:00:31 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:00:35 <nirik> morning
20:00:38 <dherrera> .hi
20:00:39 <michel> .hi
20:00:39 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:00:42 <zodbot> michel: michel 'None' <m.wahlheim@t-online.de>
20:00:45 <gotmax[m]> .hi
20:00:46 <tdawson> Hi pgreco
20:00:46 <zodbot> gotmax[m]: Sorry, but user 'gotmax [m]' does not exist
20:00:47 <rcallicotte> ,hi
20:00:49 <tdawson> Hi nirik
20:00:52 <tdawson> Hi dherrera
20:00:55 <gotmax[m]> .hello gotmax23
20:00:55 * michel is still tidying up the house after movers came in, will be sporadic
20:00:55 <rsc> .hello robert
20:00:55 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
20:00:57 <tdawson> Hi michel
20:00:58 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:01:10 <tdawson> Hi gotmax[m] and rsc
20:01:13 <michel> .hello salimma
20:01:14 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:01:19 <smooge> helo
20:01:26 <gotmax[m]> Hi tdawson!
20:01:33 <tdawson> Hi rcallicotte and smooge
20:01:34 <michel> Hello all
20:01:47 <carlwgeorge> .hi
20:01:47 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:02:09 <tdawson> Hi carlwgeorge
20:02:11 <gotmax[m]> Hi Carl
20:04:26 <carlwgeorge> howdy everyone
20:04:56 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:01 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:21 <smooge> any issues?
20:05:22 <tdawson> The only thing there is the oddly named  one ..
20:05:34 <tdawson> .epel 39
20:05:35 <zodbot> tdawson: Issue #39: End of lifing CEPH in EL7 and process improvement - epel - Pagure.io - https://pagure.io/epel/issue/39
20:05:52 <smooge> geez that person can't sepll
20:05:54 <tdawson> That's really about retiring packages.
20:06:16 <gotmax[m]> Is this the relevant pr from Michel Alexandre Salim 🎩?
20:06:17 <gotmax[m]> https://pagure.io/epel/pull-request/182
20:06:24 <nirik> smooge: can any of us? :)
20:06:27 <tdawson> Yep
20:07:13 <nirik> I think the PR looks good. +1
20:08:19 <tdawson> I still would like one change ... it currently only has two reasons for retiring ..
20:08:34 <carlwgeorge> what about when retiring the epel package for the rhel package results in a version downgrade?
20:09:13 <gotmax[m]> You mean when the RHEL packager has a lower NEVR?
20:09:16 <gotmax[m]> *package
20:09:17 <carlwgeorge> yes
20:09:36 <tdawson> Well ... is there really anything we can do about that?
20:09:44 <carlwgeorge> i.e. foo 4 is in epel, then rhel adds foo 3.  we still have to retire foo from epel.
20:09:53 <gotmax[m]> I'm not sure what else there is to do besides communicating with the RHEL maintainer or expecting people to do distro-sync (or whatever that command is)
20:10:01 <rcallicotte> Ahh I see
20:10:16 <carlwgeorge> as written that wouldn't be announced, but i think it should be
20:10:33 <tdawson> Ahh ... correct.  Yes, that would need to be annouced.
20:10:39 <rcallicotte> I agree.  That should be announced
20:10:48 <nirik> announcement would be good.
20:10:59 <carlwgeorge> it hints at it but it's too vague, and that specific scenario should be explicitly mentioned imo
20:10:59 <gotmax[m]> Would that be a prereq to retiring it?
20:11:06 <tdawson> I'm noticing there aren't many comment on the pull request ... carlwgeorge would you mind putting that in the comments.
20:11:10 <gotmax[m]> Ideally, we'd want to get it out first so nobody else updates to it
20:11:11 <carlwgeorge> of course
20:11:19 <michel> Happy to make any changes needed, please comment on the PR and I'll try to get them done tomorrow
20:11:49 <tdawson> I'll put my comment in too.
20:12:21 <tdawson> Anything else for this?
20:12:27 <pgreco> rhel > epel => retire without notification
20:12:27 <pgreco> rhel < epel => retire and then send notification
20:12:27 <pgreco> selective retirement => wait for approval, then notify, then retire
20:12:33 <michel> If RHEL puts in an older version, should we require the RHEL maintainer to inform the EPEL maintainers? Or do we just want to automate ir
20:12:37 <pgreco> is that analysis ok?
20:13:02 <michel> Matrix is mangling the less than signs for me
20:13:03 <carlwgeorge> pgreco: packages don't usually get removed from rhel, so what would rhel > epel look like?
20:13:26 <gotmax[m]> michel: I don't think we can require RHEL maintainers to do anything...
20:13:28 <nirik> how about we just ask people to announce all of them?
20:13:33 <pgreco> carlwgeorge: added to rhel I mean, with a version > than epel
20:13:35 <michel> gotmax[m]: True
20:13:47 <nirik> gotmax[m]: we can't force epel maintainers either. ;) just ask them politely to do something
20:13:48 <tdawson> That sounds good .. annoucement for all retirements.
20:14:00 <carlwgeorge> ah, yup i see.  that's correct then.
20:14:30 <michel> Also, apologies for missing several meetings in a row and delaying this PR
20:14:31 <carlwgeorge> i don't want to bother with announcements when the rhel package being added is equivalent or newer than the epel package being retired
20:14:54 <carlwgeorge> and i venture to guess most users would see that announcement as pointless as well
20:14:57 <gotmax[m]> I agree, but I don't feel too strongly
20:15:16 <nirik> well, there's some reason for it...
20:15:17 <gotmax[m]> I guess it wouldn't be a huge deal as long as you can retire it before sending the announcement
20:15:17 <carlwgeorge> i like the spirit of that first paragraph as long as the rhel package is a higher nvr
20:15:31 <nirik> I mean if there's bugs you report them another place...
20:16:17 <tdawson> Yep ... the annoucement would be worded differently ... just saying "These packages are now in RHEL"
20:17:18 <tdawson> But I don't feel that strongly about that.
20:17:31 <nirik> or... since theres bugs on these now, perhaps we could just send one email announcement per minor release with all of them?
20:18:11 <tdawson> Ya ... that's what I was thinking.  something along the lines of RHEL 8.7 related packages.
20:18:42 <smooge> taat sounds good to me
20:19:15 <pgreco> that's a good compromise, yeah
20:19:54 <tdawson> Anything else on this before I move on?
20:20:14 <smooge> nope
20:22:11 <tdawson> #topic Old Business
20:22:32 <tdawson> I don't have any old business ... but I wasn't here for most of last week.
20:24:20 <tdawson> sorry ... got interupted
20:24:38 <gotmax[m]> I have some follow up about last week's epel8 python/ansible discussions, but we can wait till `#topic EPEL 8`
20:27:13 <tdawson> #topic EPEL-7
20:27:19 <tdawson> CentOS 7 will go EOL on 2024-06-30
20:27:25 <tdawson> Anything for epel7?
20:27:49 <gotmax[m]> Nothing from me
20:29:04 * nirik has nothing for epel7
20:29:10 <tdawson> #topic EPEL-8
20:29:16 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:29:23 * pgreco has 2 for epel9
20:29:44 <tdawson> Sounded like there was some epel8 stuff.
20:29:46 * rsc has 1 for epel9
20:30:17 <gotmax[m]> So there was some more python module related breakage in c8s this week (python38 and python39) in addition to the python27 one that got fixed earlier.
20:30:18 <gotmax[m]> It's all been fixed now, though
20:30:43 <gotmax[m]> I think I saw somewhere (maybe a CPE update email?) that they put in place some safeguards to prevent this from happening again
20:30:50 <tdawson> Ok, then anything else for epel8?
20:31:00 <smooge> not from me
20:31:14 <tdawson> #topic EPEL-9
20:31:14 <gotmax[m]> I still need to send out my email about the retirements
20:31:15 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
20:31:34 <pgreco> rsc: you go first
20:31:47 <gotmax[m]> I had something else for 8, but whatever
20:31:58 <rsc> pgreco: oh :)
20:32:28 <rsc> Mine is quite simple, https://pagure.io/releng/issue/10884 - I reached the stale EPEL package for the first time...and now I'm wondering about the approval (who approves it?).
20:32:49 <gotmax[m]> releng needs to handle it
20:33:09 <nirik> humaton will get it tomorrow morning when he gets in most likely.
20:33:30 <nirik> or I guess I'm only doing 2 things... I can just process it now. ;)
20:33:34 <rsc> Ah, no epel-sig-approval required?
20:33:45 <gotmax[m]> No
20:33:48 <rsc> So if this is purely releng, then I'm done.
20:34:14 <pgreco> mine are similar, but not that far along yet
20:34:26 <pgreco> https://bugzilla.redhat.com/show_bug.cgi?id=2052868 branched but never pushed, no answer from maintainer
20:34:50 <pgreco> and https://bugzilla.redhat.com/show_bug.cgi?id=2032972 request to branch, but maintainer didn't even ask for the branch
20:34:53 <nirik> rsc: just got it.
20:35:15 <pgreco> both packages build without issues from rawhide branch
20:35:22 <rsc> nirik: awesome, thank you! :)
20:35:44 <tdawson> Anything else before moving on to open Floor ?
20:36:05 <gotmax[m]> pgreco's thing?
20:36:20 <tdawson> Oh ... sorry, lost track of threads.
20:36:38 <pgreco> I can file the releng ticket for both
20:37:10 <gotmax[m]> Is that allowed under the policy even if the maintainer already requested the branch?
20:37:16 <gotmax[m]> I know we wanted to reword that a little bit
20:37:23 <gotmax[m]> but I'm not sure what came of that
20:37:54 <pgreco> the maintainer asked for the branch, but never pushed, and I added a "needinfo" 2 weeks ago, still nothing
20:37:58 <pgreco> I can wait a bit more
20:38:47 <nirik> it's easy to forget those... especially if you have a lot of them in process at once.
20:39:27 <pgreco> so, recommendations?
20:39:27 <gotmax[m]> They requested the branch in February
20:40:35 <pgreco> yeah, and the other one hasn't had an answer since march
20:40:54 <tdawson> pgreco: I would go ahead and build the one that was branched.
20:41:15 <pgreco> I don't have push access, unless the sig gets added
20:41:26 <pgreco> I'm not a proven-packager
20:41:39 <tdawson> Ah ... ok.  I thought you were.
20:41:50 <gotmax[m]> I think we should amend the the stalled request policy to allow requesting access for this type of situation as well
20:42:21 <pgreco> tdawson: I've never got around to having the right "justification" for it
20:43:05 <tdawson> I wonder if "no action on the bug" falls into the category of where they've branched it but haven't done anything.
20:43:05 <nirik> yeah, I'd say just follow the policy...
20:43:10 <carlwgeorge> maybe s/with no action/without being resolved/
20:43:16 <nirik> they are still non responsive, just sligtly differently. ;)
20:43:54 <carlwgeorge> i didn't think there would be this many edge cases for this process
20:43:59 <tdawson> carlwgeorge: I don't like the "without being resolved" because there can be several reasons it wasn't resolved ... such as missing dependencies or waiting for a product release.
20:44:16 <carlwgeorge> yeah true
20:44:20 <gotmax[m]> Or a packager not wanting to branch it
20:44:24 <carlwgeorge> this is a difficult needle to thread
20:44:26 <gotmax[m]> i.e. mock or nose
20:44:36 <carlwgeorge> not wanting to depends on the reason
20:44:49 <gotmax[m]> Miro got 6 branch requests for mock and multiple for nose as well
20:44:51 <carlwgeorge> i agree with not branching python-mock and python-nose
20:44:59 <gotmax[m]> Both of those are deprecated in Fedora
20:45:09 <carlwgeorge> but "i don't care about epel" isn't a valid justification to block someone else from doing it
20:45:16 <gotmax[m]> Agreed
20:45:20 <gotmax[m]> I should've clarified
20:45:21 <tdawson> Yep
20:45:36 <gotmax[m]> The current guidelines don't really have a way to prevent this situation
20:45:46 <gotmax[m]> They say to search for open bugs before creating a new one
20:45:54 <gotmax[m]> But if the maintainer closed them there are no open bugs
20:45:55 <carlwgeorge> anyone want to volunteer to work up phrasing changes in a pr that we can then iterate on?
20:46:31 <carlwgeorge> i suspect we won't solve this in the next 14 minutes
20:47:00 <gotmax[m]> I wanted to suggest creating a tracker bug for EPEL branching requests
20:47:21 <gotmax[m]> That would make it easier for us to track and we could ask people to search that for existing bugs
20:47:49 <carlwgeorge> or step one should be to check if the package is deprecated in fedora
20:47:53 <nirik> it would be hard (at least at first) to get people to add the tracker... but we could.
20:48:08 <gotmax[m]> nirik: Agreed
20:48:18 <gotmax[m]> Especially for users who aren't too familiar with Bugzilla
20:48:22 <tdawson> gotmax[m]: I've got a "bugs that aren't associated with a package" on willit ... it basically is just package requests.
20:48:44 <gotmax[m]> Blocking FE-NEEDSPONSOR is usually the first thing I do on new packagers' review requests
20:48:53 <tdawson> Oh ... willit is currently down.  Hardware issues
20:49:06 <gotmax[m]> What do you mean by aren't associated with a package?
20:49:46 <tdawson> gotmax[m]: Meaning they are for <package> on epel9, but <package> isn't in epel9.
20:49:46 <nirik> the lack of standardization is sometimes anoying... I have bugs with titles like 'epel9 please'
20:49:59 <gotmax[m]> But what about bugs filed against Fedora?
20:50:09 <gotmax[m]> nirik: Agreed
20:50:19 <tdawson> gotmax[m]: Nothing I can do about those ... at least not with willit.
20:50:22 <nirik> or just 'epel support' (which doesn't tell me what package without looking or what branch they want... but anyhow)
20:50:48 <gotmax[m]> I have a script to automate creating bugzilla branching requests and I currently have to use some ugly heuristics to figure out if there's existing branching requests
20:50:58 <gotmax[m]> https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/request_epel.py if anyone's interested
20:51:54 <tdawson> We're getting close to time, and nobody volunteered to re-work documentation ... so I'm going to move on.
20:52:02 <tdawson> #topic General Issues / Open Floor
20:52:11 <gotmax[m]> I can edit the epel-package-request doc about checking if a package is deprecated
20:52:24 <carlwgeorge> in light of other volunteers for the stalled one, i can attempt something
20:52:26 <gotmax[m]> But I'm not sure how to tell people to do that?
20:52:43 <gotmax[m]> carlwgeorge++
20:52:43 <zodbot> gotmax[m]: Karma for carlwgeorge changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:52:59 <carlwgeorge> gotmax[m]: `Provides: deprecated()` in the spec file
20:53:11 <gotmax[m]> I know, but that's not exactly easy to explain
20:53:27 <carlwgeorge> link to https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ i supposed
20:53:36 <gotmax[m]> I know how to do that, but not everyone does
20:53:45 <gotmax[m]> And I'm not sure that would help too much
20:53:53 <gotmax[m]> I guess it's worth adding
20:54:20 <carlwgeorge> yeah some will not understand and skip, but i think it will still help some
20:54:52 <nirik> once we get any helper scripts working, we should stick them in fedora-packager... (should we make a epel-packager?)
20:55:26 <gotmax[m]> What else besides this would go in epel-packager?
20:57:02 <tdawson> I'm not against an epel-packager ... possibly once we have more than one script, we'll find and write more.
20:57:25 <tdawson> I won't be available next week.  Does anyone want to run the meeting?
20:57:42 * smooge pulls out the 'spin-a-meeting-leader'
20:57:49 <tdawson> *laughs*
20:57:56 <carlwgeorge> i can
20:58:05 <tdawson> Thanks carlwgeorge
20:58:14 <gotmax[m]> Thanks
20:58:19 <smooge> .... carlwgeorge ... gotmax[m] ... nirik ... pgreco ... tdawson ... carlwgeorge
20:58:25 <smooge> looks like it will be carlwgeorge
20:58:35 <tdawson> *cheers*
20:58:45 <pgreco> smooge: that didn't look that random, but I'm ok with it
20:58:47 <carlwgeorge> i have no problem bowing out if someone else wants to give it a try
20:58:59 <smooge> its a circle.. with the spinner
20:59:02 <carlwgeorge> it's not hard, just a few commands to remember and watching the time
20:59:17 <smooge> I scribble some names and flick
20:59:19 * gotmax[m] meekly raises his hand
20:59:36 <carlwgeorge> gotmax[m]++
20:59:36 <zodbot> carlwgeorge: Karma for gotmax23 changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:59:47 <carlwgeorge> and i'll be here to help out if you get stuck/lost
21:00:29 <tdawson> Ya gotmax[m] ... go for it.
21:01:04 <tdawson> Looks like our time is up.  Thank you all for being here and for the good discussions.
21:01:28 <tdawson> I'll talk to ya'll in two weeks.  And thanks gotmax[m] for leading the meeting next week.
21:01:41 <gotmax[m]> Thanks tdawson and everyone else!
21:01:43 <tdawson> #endmeeting