20:00:13 <tdawson> #startmeeting EPEL (2022-11-02)
20:00:13 <zodbot> Meeting started Wed Nov  2 20:00:13 2022 UTC.
20:00:13 <zodbot> This meeting is logged and archived in a public location.
20:00:13 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:13 <zodbot> The meeting name has been set to 'epel_(2022-11-02)'
20:00:15 <tdawson> #meetingname epel
20:00:15 <zodbot> The meeting name has been set to 'epel'
20:00:16 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge
20:00:16 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson
20:00:18 <tdawson> #topic aloha
20:00:20 <carlwgeorge> .hi
20:00:21 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:00:24 <pgreco> .hi
20:00:25 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:00:35 <tdawson> Hi carlwgeorge and pgreco
20:00:55 <michel-slm> .hello salimma
20:00:56 <zodbot> michel-slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:00:57 <smooge> hello
20:01:20 <tdawson> Hello michel-slm and smooge
20:01:31 <salimma> #chair michel-slm
20:01:31 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] michel-slm nirik pgreco salimma smooge tdawson
20:01:45 <tdawson> Ha ... beat me to it. :)
20:01:58 <michel-slm> sync to chat.fedoraproject.org is lagging really bad btw
20:02:03 <michel-slm> I'm taking this meeting from IRC :)
20:02:04 <gotmax> .hello gotmax23
20:02:05 <zodbot> gotmax: gotmax23 'Maxwell G' <gotmax@e.email>
20:02:07 <nirik> morning
20:02:08 <rcallicotte> .hi
20:02:10 <dherrera> .hi
20:02:11 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:02:14 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:02:34 <tdawson> Morning nirik
20:02:46 <tdawson> Hi rcallicotte and dherrera
20:02:47 <davide> .hello dcavalca
20:02:48 <zodbot> davide: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:02:54 <tdawson> Hello davide
20:05:02 <tdawson> #topic End Of Life (EOL)
20:05:04 <tdawson> RHEL 7 will go EOL on 2024-06-30
20:05:06 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:05:07 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
20:05:31 <tdawson> I wonder if Stream 8 really will go away in 2024 ...
20:05:41 <michel-slm> tdawson: do you know something we don't? :)
20:05:56 * carlwgeorge raises an eyebrow
20:06:33 <tdawson> No, I really don't.  But if CentOS Stream 8 is changing to be like CentOS Stream 9 ... that means RHEL 8 needs to change it's workflow again, after CentOS STream 8 goes away.
20:07:22 <tdawson> Sorry, this is the wrong meeting to bring that up.
20:08:03 <tdawson> I literally haven't heard a single thing saying it's life will extend longer
20:08:15 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:08:16 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:08:23 <pgreco> tdawson: if it doesn't go away in 2024, it would have been a PR hit for nothing...
20:08:36 <smooge> I expect that comes under 'a bridge we will burn when we cross it'
20:08:44 <tdawson> Hi smooge
20:08:55 <tdawson> pgreco: Correct
20:09:29 <gotmax> There's not a lot on the issue tracker
20:09:33 <tdawson> Anyway, for meeting subjects, I added a blocker tag, so we'd know that something is ... blocking.
20:09:38 <tdawson> Correct.
20:09:56 <tdawson> I put the ipv6 one, because I was wondering if we can close that yet.
20:10:03 <tdawson> .epel 183
20:10:04 <zodbot> tdawson: Issue #183: Fix documentation to point out ipv6 addresses for downloads - epel - Pagure.io - https://pagure.io/epel/issue/183
20:10:26 <tdawson> Does dl.fedoraproject.org have ipv6 yet?
20:10:28 <gotmax> I think we decided not to do this?
20:10:58 <tdawson> Correct, we weren't going to change the documentation ... it's really a matter of "can we close this?"
20:11:02 <smooge> no and I do not expect ipv6 until next year
20:11:54 <carlwgeorge> i think we can close it since we have an faq item covering the ipv6-only scenario now
20:12:08 <gotmax> +1
20:12:18 <tdawson> Sounds good to me.
20:12:24 <davide> Likewise
20:12:24 <smooge> yes sorry my statement was for tdawson: Does dl.fedoraproject.org have ipv6 yet?
20:14:01 <tdawson> Does anyone mind updating and closing it?
20:14:01 <nirik> yeah, we have no specific ETA yet.
20:14:13 <pgreco> +1
20:16:09 <tdawson> OK, moving on ... #35 - I didn't get the writeup written, or the new issue written.  Each time I went to do it something else came up.  So I'm not really blocked, and I expect to get it done by the end of the week (hopefully today)
20:16:31 <smooge> ticket closed
20:16:40 <tdawson> smooge: Thanks
20:17:25 <tdawson> So ... we do have some old business this week
20:17:35 <tdawson> #topic Old Business
20:18:08 <tdawson> carlwgeorge: This is from last week "occasionally i see confusion about bugzilla components that don't match the package name.  i'm working on a pr to the epel request guide for how to locate the component (srpm) name."
20:18:36 <tdawson> carlwgeorge: Any progress on this?  Do you need any input from us?
20:18:51 <carlwgeorge> progress yes, but not complete yet
20:19:18 <tdawson> Sounds good.
20:19:35 <carlwgeorge> I had something I thought was ready, left it for a few days, and now with fresh eyes I don't like the phrasing so I'm gonna refine it some more
20:20:35 <gotmax> Packages on packages.fp.o already have a "File a new bug report" link. I wonder if we could contribute a change to the package template to add a "Request EPEL branch" button.
20:21:21 <nirik> thats a pretty interesting idea...
20:21:32 <davide> Oh that's a great idea
20:21:54 <davide> Especially if we can then autopopulate the BZ with a sane template
20:22:04 * nirik nods
20:22:11 <gotmax> It would be easiest to have it on the pages unconditionally, but I don't want packages to get 10 branching requests
20:22:18 <pgreco> anything that makes things less error prone, I like
20:22:20 <gotmax> Keep in mind that it's a static website
20:22:30 <michel-slm> gotmax: oh nice
20:22:49 <davide> Make it point to a CGI that checks for open bugs and only files one if it's missing?
20:22:56 <davide> Could be expensive on BZ though
20:23:10 <michel-slm> ideally we have a way one of the admins can click, authenticate, and approve a branch creation, but we can simplify the requesting side first
20:23:50 <gotmax> Bugzilla is *really* slow, but there is the Oraculum cache
20:25:25 <nirik> could add a whiteboard keyword and it could search for that...
20:26:43 <tdawson> I like that idea, but I still think carlwgeorge needs to do his writeup.  Sometimes people just don't know what name the source package has.
20:26:51 <gotmax> Agreed
20:26:56 <gotmax> That was a longer term idea
20:26:58 <gotmax> nirik: Do you know how often that site is regenerated?
20:27:17 <nirik> its an openshift app
20:27:27 <nirik> https://pagure.io/fedora-packages-static
20:29:14 <tdawson> Anything else on that before we move on?
20:29:14 <nirik> I guess we could file a RFE and see if anyone wants to implement it? or ?
20:30:38 <tdawson> I'm going to move on.
20:30:46 <tdawson> A lot older topic - EPEL2RHEL - I've already got what the new subject should be, but I'm curious about your opinion on the bugzillas.
20:30:47 <tdawson> Should the bugs continue to be against the package, or should they all be against "distribution" ?
20:31:17 <gotmax> I think they should be filed against the packages
20:31:37 <gotmax> So we're doing the automated retirement thing?
20:31:37 <davide> I have a weak preference for filing them against the packages
20:31:44 <carlwgeorge> would it be worth doing a distribution bug for each minor release, then individual package bugs that block it?
20:31:46 <nirik> it would be nice if those block a tracker in distribution tho... 'epel packages going to rhel in 8.8'
20:32:05 <carlwgeorge> i think me and nirik are saying the same thing
20:32:09 <tdawson> gotmax: Well, I'm going to write up a script, and at least do it manually at first, see if it works, and if it does automate it.
20:32:11 <nirik> yeah.
20:32:46 <nirik> that way you can tell when they are all done, see what was done at that point release easily, etc
20:32:53 <michel-slm> yeah, against the package but blocking a tracker for the minor release
20:32:53 <tdawson> Something other than this - https://bugzilla.redhat.com/show_bug.cgi?id=1998160
20:32:54 <gotmax> I like tracker bugs, so that's fine with me
20:33:10 <davide> Yeah that seems useful
20:33:38 <Eighth_Doctor> .hello ngompa
20:33:39 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:33:41 <nirik> I'd prefer one for each minor, but whoever is doing the work can do it how they like I guess. ;)
20:34:04 <Eighth_Doctor> as long as it's easy for me to subscribe and know what's going on...
20:34:31 <tdawson> The problem is that we couldn't get the "one tracker per release" straight from internal Red Hat.  They want a single bugzilla that they can put all their blocks on.
20:35:19 <tdawson> It's possible that I could have the script create those, but that would add extra logics to it.
20:36:07 <Eighth_Doctor> you could add the minor version to the title of the BZ
20:36:19 <Eighth_Doctor> and still have it block the main tracker
20:36:47 <tdawson> Eighth_Doctor: That is what I have in the "internal" works ... er ... what I'm trying to get done in the internal EPEL2RHEL workflow.
20:37:22 <michel-slm> tdawson: ouch
20:37:41 <michel-slm> one tracker per six month doesn't sound like something too bad, surely
20:37:55 <tdawson> So the subject would be like "Please remove zlib from epel8 when RHEL 8.7 is released"
20:39:39 <nirik> so, they file the bug against the package and set it to block the tracker? we only provide the tracker for them to use?
20:39:40 <tdawson> michel-slm: No, we're talking 2 trackers every 6 months right now, 3 in a few years.
20:39:58 <tdawson> nirik: Correct, that is how it is currently setup.
20:40:21 <michel-slm> RH works on 2 minor releases at... oh one for 8 and one for 9
20:40:48 <gotmax> I'd prefer something like "Heads up: PACKAGE will be automatically retired after the release of RHEL X.X"
20:40:55 <gotmax> To make it clear that no action is required
20:41:05 <tdawson> gotmax: Oohh ... I like that.
20:41:15 <michel-slm> I like that wording. avoids maintainers accidentally retiring early
20:41:52 <davide> Yup I think this works
20:41:53 <carlwgeorge> would also be useful to include in the body a suggestion to not update the package unless absolutely necessary, to avoid the epel package getting ahead of the planned rhel nvr
20:41:54 <nirik> +1
20:42:19 <pgreco> carlwgeorge: soft freeze
20:42:23 <carlwgeorge> yup
20:42:42 <michel-slm> +1
20:42:47 <rcallicotte> +1
20:42:57 <dherrera> +1
20:43:14 <tdawson> carlwgeorge: I like that as well.  I'll see if they can put that in, and if they can't, we'll have the script put it in.
20:43:15 <pgreco> +1
20:44:30 <tdawson> But I think they can.  They already add one extra comment after they create it, so it's in their workflow.
20:44:45 <carlwgeorge> one note about the 3 minor releases at a time comment.  by the time rhel 10.0 arrives, rhel 8 won't have any more minor releases, so it should only ever be 2 minor releases at a time, i think.
20:45:09 <tdawson> carlwgeorge: Ya ... that's true.  Hopefully they aren't adding more packages at that point.
20:45:36 <carlwgeorge> i would think not, things are very static by that point
20:45:48 <pgreco> unless firefox needs something
20:46:17 <smooge> ssssshhhh
20:46:29 <pgreco> firefox/thunderbird are the largest source of disruptions in 7 right now
20:46:32 <smooge> you'll summon the dependency gods
20:46:42 <pgreco> but yeah, other than that, the rule applies ;)
20:47:27 <tdawson> But it's still not "just two", they need to keep track of what bug RHEL 8.6 and 8.7 to track.  Because we've already seen packages going out to to two minor releases at the same time.   Anyway, I'll see what they can do.
20:47:59 <tdawson> Anything else before we move on?
20:48:27 <carlwgeorge> will that process get completely screwed up when rhel10 is using jira instead of bugzilla?
20:48:54 <michel-slm> hmm
20:48:59 <pgreco> and here I thought that me mentioning firefox deps was the worst about this meeting....
20:49:06 <carlwgeorge> lol
20:49:13 <davide> Is the jira stuff setup already?
20:49:15 <carlwgeorge> don't kill the messenger
20:49:30 <carlwgeorge> https://issues.redhat.com
20:49:35 <davide> Last i checked i couldn't see anything on that instance
20:49:37 <tdawson> carlwgeorge: It should be the same unless EPEL changes from bugzilla to jira
20:49:50 <gotmax[m]> Yeah, RHELPLAN is private...
20:50:04 <carlwgeorge> davide: yeah i think there are lot of visibility problems and other tweaks that are yet to be worked out
20:50:25 <gotmax[m]> I also hope that Fedora SSO will be added
20:50:43 <tdawson> Thus far, nobody has suggested that EPEL switch to Jira
20:50:49 <carlwgeorge> so far i haven't seen fedora say outright that they'll join rhel on jira
20:50:57 <pgreco> I don't even wanna thing about the level of modifications in the current bugzilla.r.c
20:51:22 <davide> I'd assume that would need to go through fesco?
20:51:28 <michel-slm> how's JIRA and Bugzilla bridged now, is there any automation?
20:51:35 <davide> It'd be a major engineering lift to switch all the systems over
20:51:40 <davide> Assuming it's even possible
20:51:44 <michel-slm> and... if we want to take a sneak peek at how Jira is used, as Fedora contributors is that possible
20:52:02 <nirik> I doubt very much fedora will move to jira.
20:52:06 <smooge> there is no bridge
20:52:27 <michel-slm> all the tracking is manual? ouch
20:52:35 <gotmax[m]> gotmax[m]: Ansible Galaxy NG uses Jira and people in the Ansible community were not particularly enthused about needing a RH account
20:52:38 <tdawson> michel-slm: davide:  there is currently a bugzilla -> jira sync ... but it's basically one way.
20:52:39 <carlwgeorge> i believe at devconf.us mattdm was saying that he wanted to evaluate what was the best issue tracker for fedora's needs, independent of rhel's needs
20:52:43 <nirik> there's various syncing things, but I am not sure of the details
20:53:02 <smooge> ah I was wrong.. its not a bridge, its a trebuchet
20:53:08 <carlwgeorge> lol
20:53:26 <tdawson> And that sync isn't on every bug, just ... I don't know the criteria ... at least the ones for RHEL.
20:53:35 <tdawson> *laughs*
20:53:38 <gotmax[m]> Sounds like a mess
20:53:48 <smooge> ssssshhhh you will summon the jira gods
20:53:52 <tdawson> Which is why they want to switch to just jira
20:53:54 <davide> At the very least this will have major implications on CentOS
20:53:54 <davide> Even if it's limited to RHEL
20:53:56 <carlwgeorge> i bring it up because i believe the current epel2rhel stuff does dependencies on the private rhel bugs for the package additions
20:54:32 <carlwgeorge> if there are no rhel 10 bzs to depend on, the automation will need some kind of adjustment i imagine
20:54:50 <tdawson> carlwgeorge: good point.
20:55:09 <mattdm> https://discussion.fedoraproject.org/t/the-future-of-bugzilla-in-fedora/37735
20:55:21 * carlwgeorge waves at mattdm
20:55:24 <tdawson> Although I think we have already sorta slid onto Open Floor, I'm going to make it official ...
20:55:29 <tdawson> #topic General Issues / Open Floor
20:55:30 <nirik> the automation is sure to need to change when/if we move from rhbz
20:55:41 <mattdm> (Not sure what meeting this is because zodbot can't change the matrix room title. But I was summoned :) )
20:55:53 <gotmax[m]> EPEL Steering Committee
20:56:44 <carlwgeorge> mattdm: just talking about something i remembered you saying, no input needed at this time.  but thanks for the discussion link, that's useful.
20:56:47 <tdawson> I guess that's a good point.  I suppose EPEL will stick with whatever Fedora is using.  So we should keep up on that discussion.
20:57:19 <carlwgeorge> i guess the main input would be that epel has to think about this sooner than fedora overall does, considering the epel10 implications
20:57:50 <nirik> meh...
20:58:18 <smooge> nirik, how long before we can retire?
20:58:47 * nirik looks at stock market... sighs... never? :)
20:59:02 <tdawson> carlwgeorge: I think those private EPEL2RHEL bugzillas are because they need the bugzillas in order to create the original pull requests.  But it's something I can look at while I'm working with the team doing it.
20:59:06 <michel-slm> FIRE is a lie
20:59:45 <tdawson> We're getting close to the end of the meeting, anything that needs to come up before we go?
20:59:46 <nirik> if epel is seperate from rhel on bugs, thats fine I think, we just need to adjust
21:00:16 <gotmax[m]> python3-tomli and python3-tomli-w are now in all EPEL versions, including EPEL 7.  This should help now that python3-toml is deprecated in Fedora.
21:00:35 <tdawson> Ya!!
21:00:41 <mattdm> yeah -- please bring that as a requirement when bcotton gets around to this thing on his task list (there is a survey he's working on)
21:00:53 <carlwgeorge> the epel-release update for epel8 that disabled epel-modular was pushed to stable on halloween as planned
21:01:02 <tdawson> Thanks gotmax[m] and any else who worked on those.
21:01:30 <tdawson> carlwgeorge: Thanks ... and thus far ... not a single person has complained ... or possibly noticed.
21:01:41 <carlwgeorge> i haven't heard a peep
21:02:42 <michel-slm> Halloween present for everyone
21:02:57 <tdawson> Oh ... and it looks that the new openssl3 has made it into epel8 as well.
21:03:12 <michel-slm> oh yeah, I did that yesterday
21:03:16 <tdawson> Thank you michel-slm and anyone else who helped with that.
21:03:33 <michel-slm> thanks for the Stream folks making the commit available really fast
21:03:47 <tdawson> Looks like our time is up.  Thank you all for coming and the good discussions.
21:03:59 <michel-slm> one update for me (that I mentioned in office hour this morning): 200+ rust crates going to be in EPEL9 soon
21:04:11 <tdawson> michel-slm: Wow!
21:04:25 <michel-slm> I'm using ebranch so I can see which packages have no dependencies, and build them first :)
21:04:42 <smooge> ebranch?
21:05:03 <tdawson> https://pagure.io/epel/ebranch
21:05:21 <michel-slm> it's a helper tool I'm working on that lets you know what dependencies are missing if you want to branch something for a particular epel release
21:05:28 <davide> I'm still working on android-tools, some deps have circular dependencies, so I might end up vendoring them to break the loop
21:05:42 <tdawson> And with that, we're now 5 minutes over ...  Thank you all for coming.
21:05:49 <pgreco> thanks guys, see ya!
21:05:52 <rsc> Args. Right...Europe moved from summer to winter time. No more UTC+02. Oh dear...sorry folks.
21:05:56 <smooge> night
21:06:02 <tdawson> #endmeeting