20:01:53 <tdawson> #startmeeting EPEL (2022-08-31)
20:01:53 <zodbot> Meeting started Wed Aug 31 20:01:53 2022 UTC.
20:01:53 <zodbot> This meeting is logged and archived in a public location.
20:01:53 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:01:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:01:53 <zodbot> The meeting name has been set to 'epel_(2022-08-31)'
20:01:55 <tdawson> #meetingname epel
20:01:55 <zodbot> The meeting name has been set to 'epel'
20:01:56 <nirik> I did. it was lovely... breakfast borittos with some really hot green chilies in it. ;)
20:01:56 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m]
20:01:56 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma tdawson
20:01:58 <tdawson> #topic aloha
20:01:58 <carlwgeorge> .hi
20:01:58 <rsc> .hello robert
20:01:58 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:01:59 <SSmoogen> hello
20:02:01 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:02:07 <nirik> morning everyone
20:02:14 <rcallicotte> .hi
20:02:15 <tdawson> Sorry for being late ... I was busy snacking on nirik's lunch.
20:02:15 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:02:21 <rcallicotte> lol
20:02:25 <nirik> nom nom nom
20:02:28 <davide> .hello dcavalca
20:02:29 <zodbot> davide: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:02:34 <dherrera> .hi
20:02:35 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:03:04 <gotmax[m]> .hello gotmax23
20:03:05 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
20:03:25 * gotmax[m] has a migraine but is here anyways
20:03:44 <tdawson> Hi dherrera davide rcallicotte SSmoogen gotmax[m] pgreco salimma rsc
20:03:46 <rcallicotte> crap... production outage... brb hopefully
20:03:57 <nirik> gotmax[m]: :(
20:03:58 <tdawson> And good morning nirik
20:04:18 <tdawson> Hi carlwgeorge ... sorry, missed ya there.
20:04:19 <gotmax> Yeah. For some reason, I always manage to get a migraine on my birthday.
20:04:19 <salimma> .hi
20:04:20 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:04:21 <carlwgeorge> rcallicotte: good luck
20:04:28 <gotmax[m]> #chair gotmax
20:04:28 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax gotmax[m] nirik pgreco salimma tdawson
20:04:29 <nirik> gotmax: oh. happy b-day!
20:04:34 <salimma> (got prompted to reload Element right now, urgh)
20:04:36 <gotmax> Thanks
20:04:36 <smooge> gotmax, well happy migraine day
20:05:15 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:16 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:52 * salimma wishes gotmax a happy birthday
20:06:02 <tdawson> Looks like we'll finish the one we discussed last week in the pull request.
20:06:11 <tdawson> So that leaves #39
20:06:14 <tdawson> .epel 39
20:06:15 <zodbot> tdawson: Issue #39: Retiring EPEL Packages (End of lifing CEPH in EL7 and process improvement) - epel - Pagure.io - https://pagure.io/epel/issue/39
20:06:48 <tdawson> It's been a while since we talked about this one ...
20:07:59 <tdawson> This has made it to a discussion about "orphaning" ... which has a ... does anyone have the link handy
20:08:08 <gotmax> The one question I had is who is allowed to orphan EPEL branches
20:08:42 <tdawson> https://pagure.io/epel/package-orphan-requests
20:08:45 <gotmax> #link https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/FUAG6FG7DLSIGP2IUN7YAMEMIODE6AKR/#73JA2ADVEXXDVTI5JVDMKF4ELXIPLWVI
20:09:05 <tdawson> Thanks.
20:09:25 <gotmax> And I kind of decided to switch this to using Gitlab. But we don't have an fedora/epel Gitlab namespace.
20:10:21 <tdawson> Right now, I believe the only people who can retire packages are people with Admin on the package, or proven packagers.  But for setting "orphan" ... I think you have to be the owner .
20:10:26 <tdawson> But I'm not positive about that.
20:10:47 <gotmax> Anyone with write permissions can retire
20:10:49 <nirik> note again that orphan and retired are different things (although it's hard to tell if something is retired from pagure)
20:11:11 <gotmax> Only the main admin can set the assignee to orphan
20:11:16 <tdawson> Correct, orphaning can lead to retiring ... but yes, retiring is rather more permanent.
20:11:17 <nirik> right
20:11:42 <gotmax> Retired package branches have no content expect a dead.package file
20:11:45 <nirik> anyhow, for this case I think retirement is correct... do we need more process for it, or tell them to go for it?
20:11:46 <salimma> tdawson: for Fedora, right?
20:12:20 <Eighth_Doctor> .hello ngompa
20:12:21 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:12:25 <nirik> retired packages have dead.package in their branch and are blocked in koji so you can't build them anymore without releng intervention
20:12:28 <tdawson> salimma: For epel, retiring is what I have above ... but for orphaning ... I've never done it in EPEL.
20:12:35 <Eighth_Doctor> hey all
20:12:40 <tdawson> Hi Eighth_Doctor
20:12:44 <nirik> hey Eighth_Doctor. how's life?
20:13:12 * gotmax gets an email about more go security vulnerabilities :(
20:13:30 <gotmax> To summarize what's happened so far:
20:14:28 <gotmax> We're trying to come up with a package retirement policy. Then we realized that there's no way to rescind ownership of a package, while still allowing others to pick it up (i.e. orphaning).
20:15:18 <carlwgeorge> the idea of per-branch ownership really went away with the switch to pagure
20:15:26 <nirik> I think we do want to allow anyone with commit to reassign to orphan too.
20:15:50 <davide> what about collaborator?
20:15:59 <gotmax> Those too, I'd say
20:16:03 <nirik> I would say those too. yeah
20:16:12 <davide> (also, can someone with collaborator do fedpkg retire for their branch?)
20:16:16 <gotmax> Yes
20:16:21 <gotmax> Provenpackagers can too
20:16:22 <nirik> turns out there's already a pr to do this I think.
20:16:25 <davide> ok good
20:16:46 <nirik> yes, written by gotmax. ;)
20:17:10 <carlwgeorge> rescind ownership of a package in epel only basically amounts to removing yourself and dumping responsibility on the other maintainers
20:17:23 <carlwgeorge> unless you retire it first, then remove yourself
20:17:31 <gotmax> The idea I had was to create an issue tracker for people to announce that they'd like to orphan an EPEL branch, and then we'd have a script to go through the tickets and create an announcement email.
20:17:57 * salimma afk for a bit
20:18:04 <carlwgeorge> so emulating the pkgdb of branch owners, but outside of pagure?
20:18:14 <carlwgeorge> *the idea of pkgdb branch owners
20:19:02 <gotmax> I never used pkgdb, so idk. But people could request to pick it up on that issue, and then they be added as a collaborator or whatever.
20:19:10 <gotmax> And if nobody picks it up, we'd retire it
20:19:55 * nirik nods.
20:20:07 <pgreco> can we make it somehow that if someone does drop their epel branches, they get reassigned to the sig
20:20:28 <pgreco> until some wants to take it
20:20:33 <gotmax> So it seems like we agree that any maintainer (admin, commit, collaborator) should be able to "orphan" EPEL branches?
20:20:42 <tdawson> I think gotmax's idea is a good idea.
20:20:46 <carlwgeorge> so i guess the primary goal is to facilitate new collaborators picking up epel work when otherwise the branch would just get retired
20:20:47 <nirik> gotmax: +1
20:20:52 <nirik> yes
20:20:55 <gotmax> Yes
20:21:27 <tdawson> pgreco: The problem with it automatically going to the sig is that it might be something nobody in the sig wants.
20:21:33 <gotmax> Exactly
20:21:43 <carlwgeorge> why couldn't that just happen on the epel-devel list?  i.e. a post like "i don't need foo in epel8 anymore, does anyone want to be a co-maintainer to keep it going there?  otherwise i'll retire it"
20:22:01 <gotmax> It could
20:22:44 <carlwgeorge> that's basically the process in fedora for retirement, common courtesy to post to the fedora devel list and ask if anyone else wants it first
20:22:44 <tdawson> The only problem I see with email to -devel only, is keeping track of things.
20:22:51 <gotmax> Yes
20:23:09 <gotmax> carlwgeorge: No, orphaning is its own separate, automated process
20:23:44 <nirik> right, there's a process for how long something is orphaned for before being retired.
20:23:45 <carlwgeorge> ah yes that's what i meant, i typed the wrong thing.  stupid words.
20:23:47 <gotmax> The maintainer pushes the orphan button in distgit and then they're done.
20:24:06 <gotmax> Then it gets delegated to Miro ;)
20:25:03 <carlwgeorge> having a tracker just seems like a lot of work for something that isn't terribly common
20:25:22 <nirik> do we know how many there are currently?
20:25:43 <nirik> assignee orphan in epel and not blocked/dead.packaged/retired?
20:25:57 <carlwgeorge> not recreating per-branch ownership in pagure was intentional if i remember to encourage greater collaboration between primarily fedora and primarily epel maintainers
20:26:03 <gotmax> Well, we don't know how common it will be, because the current process isn't really well known and is cumbersome.
20:26:53 <carlwgeorge> rather than coming up with a different issue tracker, what about just creating a tracker bug in bugzilla, then make the process involve creating a bug and setting it to block the tracker bug?
20:26:57 <nirik> carlwgeorge: I think it was mainly that pkgdb couldn't handle stream branches so it was shoehorned into pagure-dist-git... ;)
20:27:35 <gotmax> That was also floated
20:27:40 <gotmax> The bugzilla thing
20:27:42 <carlwgeorge> yeah that was around the same time.  greater collab was definitely a goal, even if it wasn't the primary one.
20:27:57 <Eighth_Doctor> yeah, though now pagure grew those features anyway
20:30:11 <tdawson> So ... it's looking like carlwgeorge is leaning towards bugzilla way, while gotmax is leaning toward pagure way.
20:30:39 <tdawson> Although it also sounds like everyone agrees that at the very least, senindg and email to -devel is good.
20:31:14 <nirik> can we see how many exist now? I think we need a script to find them...
20:31:20 <gotmax> I suppose. I'm not sure carlwgeorge actually endorsed bugzilla, just suggested it.
20:31:27 <tdawson> Ah, ok.
20:31:29 <nirik> because maintainers may well not send email or file a bug
20:31:57 <tdawson> nirik: So, the search would be to see if a package is orphaned for epel, but not retired?
20:32:04 <carlwgeorge> sure, i'm undecidedish i guess.  what are the benefits of pagure of a tracker bz?
20:32:27 <carlwgeorge> nirik: people will dork up the process no matter what we do
20:32:39 <tdawson> :)  That is true.
20:32:41 <carlwgeorge> best we can do is make the process as simple as possible and remind people to follow it
20:32:59 <nirik> it would be: package has 'orphan' specifically assigned for epel bugs and the package is not dead.package / blocked in koji on epel branches. Not super easy to find out...
20:33:00 <tdawson> One plus for the pagure, is that you can put a README there, for documentation.
20:33:04 <gotmax> carlwgeorge: You're asking tracker vs tracker bz?
20:33:06 <carlwgeorge> latest example is the re2 soname bump in epel9 with no notice or incompat process
20:33:31 <gotmax> That was even against Fedora Rawhide's policy :(
20:34:02 <carlwgeorge> tdawson: having the process documented in a pagure repo's readme instead of in the main epel docs seems like a mistake to me.  better to keep all the policies in one place.
20:34:36 <carlwgeorge> gotmax: pagure issue tracker vs tracking bug in bugzilla
20:34:37 <gotmax> I still think a Pagure/Gitlab issue tracker is better. It's all in one place, easier to follow, and more user friendly
20:34:42 <tdawson> carlwgeorge: Oh, I'm not saying it wouldn't be in the main epel docs.  I'm just saying that it would be an extra "now I'm here, what do I do"
20:34:45 <carlwgeorge> words are hard
20:35:10 <carlwgeorge> docs in two places are how you get inconsistent docs
20:35:31 <tdawson> That's true.
20:35:34 <gotmax> It seems many people don't know how to use Bugzilla trackers/Blocks.
20:35:35 <carlwgeorge> also the only people reading that readme would be the people that already know there's a process to follow
20:36:52 <gotmax> It could link to the policy and explain how the repo is organized
20:36:58 <carlwgeorge> for all it's flaws bugzilla is a known entity and people more or less know how to use it.  it's assumed it will go away at some point in the distant future after all rhel products using it are eol, but by then fedora will have something else established to take the place of tracker bugs.
20:37:12 <gotmax> But I don't think the presence/lack of a README is a very important detail
20:37:13 <tdawson> So, if it was me, and I needed to orphan a package, I'd prefer pagure.   It would be just one spot, and I wouldn't have to remember to create the bug and then add the bug to the tracker.
20:37:15 <nirik> well, thats why I think a script/report is important. ;) because we can then tell when someone does this and explain the process to them
20:38:03 <nirik> but probibly very few to no one is orphaning now... they are just doing nothing or retiring
20:38:56 <salimma> given how hard it is to orphan now, it's probably not a surprise (also, removing yourself from the ACL is not possible unless you're an admin, right?)
20:39:28 <gotmax> Yeah. I think if we make it easier to give up, we'd end up with less unmaintained packages, which is good.
20:39:30 <tdawson> I'm looking at the time ... and I think we're going to need to put a pin in the discussion and/or move it back to the email.
20:39:37 <gotmax> +1
20:39:49 <salimma> also: no matter where the backend is, would it make sense to have a 'fedpkg orphan' command? and it can do the right thing for both Fedora and EPEL
20:40:04 <salimma> +1 on changing topic
20:40:07 <carlwgeorge> my thing is maintainers already have to look in 1) src.fpo for package sources and maintainer changes, 2) bugzilla for bugs, 3) bodhi for updates and overrides.  not really keen on adding another thing to that list for an orphan process.
20:40:43 <tdawson> Let's continue this via email - https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/FUAG6FG7DLSIGP2IUN7YAMEMIODE6AKR/#73JA2ADVEXXDVTI5JVDMKF4ELXIPLWVI
20:41:05 * carlwgeorge nods
20:41:18 <tdawson> I'm goign to move on to the releases, because we do have something for epel8 this week ... but I'll go in order.
20:41:31 <tdawson> #topic EPEL-7
20:41:32 <tdawson> RHEL 7 will go EOL on 2024-06-30
20:41:59 <tdawson> Anything for epel7 this week?
20:42:42 <smooge> it's not dead yet?
20:42:47 <tdawson> :)
20:42:49 <tdawson> #topic EPEL-8
20:42:51 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:43:32 <tdawson> So, this week an epel8 package was retired because it was going to be released in RHEL 8, but it was retired before it was released in RHEL 8
20:43:44 <salimma> smooge: it's mostly dead
20:43:48 <tdawson> That came out weird, but I think ya'll know what I'm talking about.
20:44:00 <carlwgeorge> salimma: not by usage numbers :D
20:44:09 <salimma> I wonder if we need to incorporate epel8-next somehow
20:44:11 <carlwgeorge> tdawson: xmlstarlet?
20:44:17 <tdawson> Correct
20:44:46 <salimma> e.g. instead of epel8-next being used only to ship newer packages than epel8, maybe figure out also a way to filter out some packages
20:44:54 <tdawson> I was asked to go change the wording of the bugzilla's, but that brings up the question ... what do we really want from the EPEL2RHEL workflow.
20:44:57 <carlwgeorge> #link https://bugzilla.redhat.com/show_bug.cgi?id=2122159#c4
20:45:04 <carlwgeorge> that has a summary i put together the other night
20:45:57 <nirik> fun. ;(
20:46:03 <salimma> if we can automate it that will probably be nice
20:46:09 <tdawson> Are these bug's what we really want?  If so, are they good enough?  Or do we really just want email and/or a list that comes out?
20:46:11 <carlwgeorge> when the process was being worked out i don't think we accounted for a simultaneous current minor + next minor release (8.6 and 8.7 in this case)
20:46:33 <salimma> but that still begs the question: what to do in Stream, because for some time the package will be in C*S and EPEL
20:46:46 <carlwgeorge> i think the bugs are good for this, just need some polish on the phrasing to make it extra clear to maintainers about when to retire
20:47:10 <nirik> and an escape clause like 'if you aren't sure, please mail epel-devel and ask before you do anything hasty'
20:47:23 <carlwgeorge> salimma: up to now we've intentionally looked the other way for centos and epel overlap, since we know it will be short term
20:47:58 <salimma> carlwgeorge: that probably makes sense, esp if the c?s package has a higher NEVRA
20:48:02 <carlwgeorge> for new packages in epel9, fedpkg checks if it's in centos compose metadata before allowing you to request the branch
20:48:17 <salimma> so maybe a policy that say, "hey this is now in stream, freeze the EPEL package please" will be nice
20:48:27 <carlwgeorge> no one wants to see this be common, where the package is retired in epel but only centos users have it in the base distro
20:48:33 <salimma> or at least keep the epel nevra below stream
20:48:46 <carlwgeorge> salimma: good idea
20:48:52 <tdawson> The problem is, that when these bugs are created, it's at the very beginning of the RHEL package addition phase.   They are not in Stream at that point.
20:49:18 <salimma> if the RHEL maintainer picks a lower NEVRA then it's out of our control :) except maybe we can do a MR, since it's now in gitlab
20:49:27 <gotmax> I don't understand the purpose of these bugs. Why do they need to be filed so far in advanced?
20:49:30 <tdawson> And Miro brought up the fun point that if the package ends up being "BuildRoot Only", which means it's allowed in epel, we don't have any way of knowing that.
20:49:54 <carlwgeorge> would a buildroot only package actually trigger this automation?
20:50:07 <tdawson> carlwgeorge: I don't know
20:50:23 <carlwgeorge> gotmax: that's another good point, perhaps we can change the process to file the bug after it's released in rhel
20:50:44 <tdawson> gotmax: Adding a package to RHEL takes between 6 and 9 months.  These bugs get filed on step 2, at the very beginning.
20:50:52 <carlwgeorge> then it changes from "please retire this in the future" to "retire asap", which is what maintainers are doing anyways
20:51:02 <salimma> some packages also got marked buildroot only later, right?
20:51:11 <salimma> so it might have been retired from EPEL, then oopsie, we didn't have to
20:51:28 <tdawson> salimma: I believe that might be the case.
20:51:28 <carlwgeorge> this is one that i think needs more discussion than we can give it in this meeting, but still good to get it on everyone's radar
20:52:01 <tdawson> carlwgeorge: Correct.  I'm goign to send out an email, and at the very least, we need to re-word the bugs.  At the most, change things so they go out later.
20:52:05 <gotmax> Can we just automate this process?
20:52:35 <carlwgeorge> it is an automated process, the question is how much flexibility do we have
20:52:43 <gotmax> We can file a "Heads up: Your package will automatically be retired when RHEL 8.7 is released"
20:52:56 <carlwgeorge> ohhh automate the retiring
20:53:10 <gotmax> Tell people that you have to do something in 6 months but not yet is quite confusing
20:53:20 <tdawson> That's a good idea, let's talk about it in the email.
20:53:24 <gotmax> +1
20:53:24 * carlwgeorge nods
20:53:29 <tdawson> Anything else for epel8?
20:53:44 <carlwgeorge> nextcloud module again
20:53:49 <davide> I'm in the process of branching asterisk
20:54:02 <davide> for epel8 and epel9, which has a bunch of "interesting" dependencies
20:54:03 <carlwgeorge> the maintainer keeps pushing new streams even though none of the packages are installable on epel8 due to missing runtime deps
20:54:09 <davide> I've linked the tickets to the tracker bug
20:54:09 <salimma> davide: brave
20:54:27 <carlwgeorge> # link https://pagure.io/releng/issue/10913
20:54:33 <carlwgeorge> #link https://pagure.io/releng/issue/10913
20:54:37 <tdawson> carlwgeorge: Ugg ... I am so glad we don't have modules in epel9
20:54:40 <smooge> proposal.. drop modules for EPEL
20:54:47 <carlwgeorge> i wouldn't hate that
20:54:48 <davide> I'm also branching the arm-none-eabi (which also has fun dependencies, including prolog...)
20:55:15 <tdawson> Moving on ...
20:55:24 <tdawson> #topic EPEL-9
20:55:25 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
20:55:43 <salimma> impressive that we know the date already almost 4 years out
20:55:54 <salimma> or is that provisional?
20:55:56 <nirik> davide: were you still poking at mailman3 stack? I saw it got orphaned, but I think you took it back up (or someone did)
20:56:18 <carlwgeorge> salimma: yes, it matches the rhel9 end of active phase
20:56:19 <salimma> nirik: that might have been me in both counts
20:56:25 <smooge> tdawson, carlwgeorge I wasn't joking
20:56:34 <salimma> trying to get time to dedicate to it but I welcome any help
20:56:38 <nirik> salimma: ah, perhaps I am mixed up there. :(
20:56:51 <gotmax> I am working on creating go-rpm-macros backport for EPEL
20:56:52 <carlwgeorge> smooge: you have my vote but i don't care to drive that one, sounds like a political fight
20:56:55 <tdawson> smooge: Can we do that?  That would be ... rather nice actually.
20:57:05 <salimma> also, speaking of things that fell by the wayside... ipython is almost ready
20:57:09 <nirik> sure we can...
20:57:16 <gotmax> Partially to work around issues that the RHEL maintainers won't fix and also for other changes
20:57:20 <smooge> I think it is a push of a config change
20:57:38 <smooge> I will write up a proposal to the list
20:57:46 <tdawson> smooge: +1
20:57:47 <salimma> it's effectively already really hard to build modules for EPEL, right?
20:57:56 <smooge> it is nearly impossible
20:58:18 <smooge> they 'build' but are generally non-installable nor can you require/use any modules in RHEL
20:58:25 <nirik> it's more than that. :( It's disabling in bodhi, what to do with existing repos, changing sync scripts, etc.
20:58:28 <salimma> so this will be "it's unsupported, so don't even bother"
20:59:12 <smooge> nirik, yeah I was underplaying it. but it is doable versus waiting until 2029?
20:59:30 <tdawson> I've got that on the agenda for next week ... but smooge it would be great if you sent out and email and/or issue to start the discussion.
20:59:52 <tdawson> Looking at the time ... I'm moving to open floor.
20:59:55 <tdawson> #topic General Issues / Open Floor
21:00:15 <nirik> sure, it's quite doable
21:00:24 <nirik> I had one quick thing...
21:00:43 <nirik> new version of eol policy for review: https://pagure.io/epel/pull-request/196
21:00:45 <nirik> thats all.
21:01:03 <tdawson> Ya! ... thanks for that
21:01:09 <tdawson> Anything else before I close?
21:01:42 <gotmax> Nope
21:01:55 <tdawson> Thank you all for the good discussions today.   And thank you all for all the work you do for the EPEL community.  It is greatly appreciated.
21:02:06 <tdawson> #endmeeting