20:00:23 <tdawson> #startmeeting EPEL (2022-10-05)
20:00:23 <zodbot> Meeting started Wed Oct  5 20:00:23 2022 UTC.
20:00:23 <zodbot> This meeting is logged and archived in a public location.
20:00:23 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:23 <zodbot> The meeting name has been set to 'epel_(2022-10-05)'
20:00:24 <tdawson> #meetingname epel
20:00:24 <zodbot> The meeting name has been set to 'epel'
20:00:25 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge
20:00:26 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson
20:00:27 <tdawson> #topic aloha
20:00:37 <smooge> helo
20:00:38 <nirik> morning
20:00:49 <tdawson> Hello smooge
20:00:54 <rcallicotte> .hi
20:00:55 <tdawson> Good morning nirik
20:00:55 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:00:56 <dherrera> .hi
20:00:58 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:00:59 <davide> .hello dcavalca
20:01:00 <tdawson> Hi rcallicotte
20:01:01 <zodbot> davide: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:01:10 <tdawson> Hi dherrera
20:01:15 <tdawson> Hi davide
20:01:43 <salimma> .hi
20:01:44 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:01:51 <tdawson> Hi salimma
20:02:14 <rsc> .hello robert
20:02:15 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:02:35 <tdawson> Hi rsc
20:04:02 <tdawson> I'm sorry about missing the office hours.  I hope they were useful this month ... or at least fun.
20:04:44 * nirik missed also
20:04:44 <salimma> I missed it too
20:05:11 <tdawson> #topic End Of Life (EOL)
20:05:12 <tdawson> RHEL 7 will go EOL on 2024-06-30
20:05:14 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:05:15 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
20:05:36 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:38 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:06:42 <tdawson> So, we've got a new issue, but it's from gotmax[m] ... and I don't see him here yet.
20:07:17 <tdawson> Is there a specific issue people want to go over first?
20:08:00 <salimma> maybe one of smooge's
20:08:10 <salimma> the bz assignee normally takes a lot of time )
20:08:10 <tdawson> Sounds good.
20:08:23 <tdawson> .epel 198
20:08:24 <zodbot> tdawson: Issue #198: Drop modularity from EPEL-8. Do not enable modularity for EPEL-9 - epel - Pagure.io - https://pagure.io/epel/issue/198
20:08:55 <tdawson> We've updated the epel-release, and I sent out the initial emails.
20:09:21 <smooge> i think it is progressing as normal
20:09:29 <tdawson> Yep.
20:09:58 <tdawson> I'm waiting until our internal Red Hat meeting before writting the blog and/or fedora magazine article.
20:10:05 <smooge> I expect we will start seeing questions and things we need to document
20:10:54 <tdawson> Besides answering questions and documentation, is there anything else we need to do before Oct. 31st?
20:12:06 <tdawson> And talking of documentation, thank you dherrera for the pull request - https://pagure.io/epel/pull-request/204
20:12:35 <tdawson> It looks good.
20:12:45 <dherrera> np 👍
20:12:57 <tdawson> I was wondering if we merge it now, or wait until Oct. 31 ?
20:13:00 <nirik> dherrera++
20:13:45 <dherrera> I tried to redact it considering either case, so I don't mind
20:14:08 <dherrera> (I added a FAQ entry about the subject)
20:14:09 <rcallicotte> Would it be "safer" to merge on Oct 31?
20:14:39 <dherrera> I think so too
20:15:32 <tdawson> OK, then let's keep it unmerged, unless people start pestering us about it.
20:16:21 <tdawson> Anything else for removing modularity?
20:16:53 <smooge> waiting for people to post Emperor Palpatine images with 'Do It'
20:17:08 <tdawson> *laughs*
20:17:30 <carlwgeorge> .hi
20:17:31 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:17:36 <carlwgeorge> sorry i'm late
20:17:38 <tdawson> Hi carlwgeorge
20:17:47 <salimma> Hi carl
20:18:07 <tdawson> carlwgeorge: Not a problem, and most of us are sorry we missed the office hours.
20:19:00 <carlwgeorge> it happens
20:19:08 <tdawson> I don't want to disregard the rest of the issues, but without gotmax[m] here ... most of those are his, so I was thinking of moving on to old-business, since we do have one thing there.
20:19:40 <tdawson> #topic Old Business
20:20:08 <tdawson> This was brought up by davide last week on open floor, and he wanted to discuss it more.
20:20:14 <tdawson> corosync packaging issues - https://bugzilla.redhat.com/show_bug.cgi?id=2121777#c19
20:20:56 * gotmax[m] reads the backlog
20:21:12 <tdawson> The summary is that they are trying to figure out a way so that we can put corosync in epel, but not have it conflict if someone has RHEL HA enabled.
20:21:13 <davide> I think the maintainer summarized the situation well in that comment, but the tl;dr is that they have concerns that the EPEL package would potentially replace the one shipped in HA and thus cause issue
20:21:21 <nirik> I'm really sorry we approved limited arch packages... ;(
20:21:44 <davide> my read of the policy is that this is by design, in that we don't expect EPEL to not conflict from other channels, but I'm sympathetic to the issue and I wonder if we can come up with a decent technical solution here
20:22:00 <carlwgeorge> "if someone has RHEL HA enabled" that's already the case for anything else that is duplicated
20:22:04 <davide> note that it's not just this package, kronosnet (one of corosync deps) has the same issue too
20:22:23 <nirik> conflicts is not a very good answer.
20:22:26 <carlwgeorge> this isn't a new thing
20:22:46 <gotmax[m]> Doesn't the policy say that EPEL packages can conflict with/duplicate packages from other channels?
20:22:58 <tdawson> gotmax[m]: Yes it does
20:22:59 <carlwgeorge> my response would be if they're enabling rhel ha channels then they shouldn't enable epel, or they should enable it with an includepkgs directive for the exact things they want
20:23:05 <davide> yes, that's my understanding of it
20:23:12 <nirik> yeah. We just want to try and be as nice as we can tho
20:23:24 <gotmax[m]> For example, nobody's ever asked for ansible 2.9 to be removed when Ansible Engine 2.9 was part of RHEL
20:23:26 <rsc> Why not building with 0.<rel>?
20:23:32 <carlwgeorge> i'm perplexed why the maintainer thought they needed their manager's approval for this
20:23:50 <davide> oh I hadn't thought of using includes/excludes, that might be an ok workaround in practice
20:24:01 <gotmax[m]> But I don't have problems with a zero prefix compromise
20:24:26 * nirik either
20:24:37 <carlwgeorge> 0 prefix in the release is well understood to signify beta/rc/pre-release snapshots of the software
20:25:01 <gotmax[m]> I think the idea was zero prefix in Version
20:25:30 <salimma> 0 prefix in version so HA's copy wins
20:25:45 <nirik> yeah, but I think carlwgeorge meant version there. ;)
20:25:45 <davide> my only worry about the zero prefix thing is that it might cause confusion, if we go down that path IMO we should get it documented so we don't end up with different packages implementing their own workarounds
20:25:48 <salimma> yeah, true
20:25:56 <carlwgeorge> no i meant release, i didn't realize the suggestion was to change the version
20:26:11 <gotmax[m]> Epoch in HA's version would also work, but I wouldn't suggest that
20:26:22 <nirik> Epoch has a lot of problems...
20:26:45 <carlwgeorge> i think lying and calling the version 0.3.1.5 when the actual version is 3.1.5 is problematic and confusing
20:26:46 <davide> I wouldn't expect being able to change something in the HA package in a reasonable timeframe
20:26:53 <nirik> the prefixed 0 in version could also have some issues if there are things that depend on specific versions...
20:26:56 <salimma> can we make the epel version be uninstallable if HA is enabled somehow
20:27:00 <davide> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_upstream_has_never_chosen_a_version seems to agree
20:27:07 <smooge> no we can't
20:27:08 <davide> Version: 0 does have a specific meaning already
20:27:13 <carlwgeorge> i would strongly prefer the rhel version just set an epoch, that seems like a perfectly appropriate useage of epoch to me
20:27:27 <smooge> we have had this same discussion for the last 3 epel's
20:27:30 <gotmax[m]> I was talking about the discussion in the issue and earlier in #epel which was about prefixing Version with `0-` or something.
20:27:31 <salimma> vendor pinning should also help right
20:27:48 <salimma> on systems that has ever installed the HA version it should stick to it
20:27:50 <nirik> yep. or includepkgs/excludepkgs
20:28:11 <rsc> carlwgeorge: well, I meant release, not version, like for -epel
20:28:32 <salimma> documenting it in a README.epel or README-HA.epel would probably help
20:28:47 <gotmax[m]> Michel Alexandre Salim 🎩:  Yes, but I think allow_vendor_change is enabled by default.
20:28:53 <salimma> gotmax[m]: sigh :)
20:28:53 <smooge> I think release should be prefixed with 0 and it should be documented. Beyond that people with HA like to do all kinds of crazy things anyway
20:28:55 <gotmax[m]> So that would have to be done by users manually
20:29:06 <rsc> smooge: +1
20:29:09 <carlwgeorge> between epochs and includepkgs/excludepkgs, i think we should be good and shouldn't overthink this
20:30:09 <smooge> basically we will get blamed for not having it, and we will get blamed for having it
20:30:09 <smooge> cycle back to this conversation in 6 months
20:30:10 <carlwgeorge> here are the versioning guidelines that using a 0 prefix on the release would mess with https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_prerelease_versions
20:30:10 <nirik> indeed.
20:30:13 <davide> so, given that epochs would need to be applied on the HA side of the fence, should RH have a "packages in channels should have an epoch" as a generic policy?
20:30:36 <smooge> no because then they have to change packages that they inherited from Fedora
20:30:44 <nirik> I'm not sure thats a good solution...
20:30:52 <smooge> and you will see that epoch show up in the Fedora package the next time they do a commit
20:31:05 <nirik> also when rhel10 comes out, someone says, OH, I'll just copy this from the rhel channel for the initial version...
20:31:06 <rsc> carlwgeorge: https://docs.fedoraproject.org/en-US/epel/epel-packaging-examples/#_missing_but_built_examples - also uses 0.<rel> in release
20:31:26 <smooge> any change that we are 'requiring' from RH is going to be a boil the ocean to get a cup of tea solution
20:31:28 <rsc> carlwgeorge: I don't see how this missing package is different...
20:32:05 <kalev> another option could be tilde in the version, like 3.1.5~epel (I don't think it's any better than other options already talked about but wanted to throw it out here)
20:33:06 <gotmax[m]> Yeah, I suggested something like that earlier. However, if RHEL e.g. had 3.1.4, the EPEL version would still replace it.
20:33:14 <smooge> repotags would be useful (but I think only nirik and I are old enough to remember that)
20:33:22 <kalev> yeah, then it would also need a policy to never go higher than the rhel version
20:33:23 <tdawson> :)
20:33:27 <rsc> I also recall them :)
20:33:41 <nirik> ah that was a flamewar
20:34:04 <nirik> but hey, el -> epel... so it would work. ;)
20:34:29 <carlwgeorge> i think the policy is clear here, epel packages are allowed to duplicate what's in rhel channels that aren't baseos/appstream/crb.  if rhel wants to add an epoch later, they can.
20:34:43 <smooge> is there a way to see if a package is branched ot the CentOS Stream channels
20:34:58 <nirik> It would also be great if we could see when a channel is enabled from a rpm... Conflicts: ha-channel
20:35:18 <tdawson> smooge: https://gitlab.com/redhat/centos-stream/rpms
20:35:19 <nirik> but alas, I think I'm with carlwgeorge for now.
20:35:40 <gotmax[m]> carlwgeorge: I agree, but it's a bit awkward to say that when the Fedora maintainer is also the RHEL one.
20:36:09 <smooge> I have been with that since day 0. If the packager thinks it is a problem, there is nothing to stop them from also putting the 0. at the beginning of their version string
20:37:06 <tdawson> I have to agree with smooge on this.  We can suggest things, but if they want to put a 0 on, it's their peragotive
20:37:43 <davide> this seems generally ok to me; is there anything we need to update/clarify in our docs around this?
20:37:46 <tdawson> Does anyone want to put some of our suggestions (along with their potential side-effects) into the bugzilla?
20:37:51 <gotmax[m]> Okay, I'd vote to leave the EPEL package alone, point to our policy, and tell them to epoch the HA version if they want (I'm just echoing what carlwgeorge said)
20:38:55 <salimma> davide: I wonder if adding a FAQ for specific case studies would help
20:39:16 * gotmax[m] is not sure what he was saying okay to
20:39:19 <salimma> so we have the 'use include/excludepkgs' written down somewhere
20:39:37 <carlwgeorge> we'll still need the corosync-epel distgit repo because corosynclib is in appstream, and have it ship all the packages that aren't shipped in baseos/appstream/crb
20:39:55 <nirik> perhaps this could be a faq entry? what to do if you want to use a channel and epel has packages from it? and list all the suggestions?
20:40:15 <salimma> nirik: yeah, that's what I was thinking
20:40:23 <carlwgeorge> yeah an faq seems sufficient, probably not enough to say for an entire page
20:40:25 <tdawson> I like that FAQ idea.
20:40:31 <davide> yeah for the record, I've already setup the dist-git repo for this: https://src.fedoraproject.org/rpms/corosync-epel
20:40:32 <davide> as the maintainer didn't know how to do so
20:42:06 <tdawson> Hmm ... I think everyone is waiting for me to either move on or give an action item ...
20:42:17 <tdawson> Oh, I just thought that outloud ... sorry about that.
20:42:30 <davide> ok it sounds like there are two actions here
20:42:43 <davide> 1) comment on the BZ with suggestions 2) write up a faq for the docs
20:43:00 <tdawson> Do I have a volunteer for the FAQ ?
20:43:20 <dherrera> I can do it ✋
20:43:26 <tdawson> dherrera: Thank you
20:43:55 <tdawson> davide: Since you've already been commenting on the bug, do you mind giving a bit of a summary about what we discussed on that?
20:44:05 <davide> yup, I can comment on the BZ and relay the results of this discussion to the maintainer
20:44:22 <tdawson> Sounds good.
20:44:44 <tdawson> I don't have any other old business ....
20:44:51 <tdawson> #topic General Issues / Open Floor
20:44:55 <salimma> we have... 16 minutes for 4 tickets :)
20:44:59 <salimma> now that gotmax (He/Him) is here
20:45:17 <tdawson> True ...gotmax[m] is here
20:45:31 <tdawson> There is the new one on the list ...
20:45:32 <gotmax[m]> There 203
20:45:44 <tdawson> .epel 203
20:45:45 <zodbot> tdawson: Issue #203: Automating adding epel-packagers-sig to packages - epel - Pagure.io - https://pagure.io/epel/issue/203
20:46:09 <gotmax[m]> Can I remove the meeting tag from the modularity ticket and the BR repo ticket?
20:46:36 <salimma> yeah, I think we agree there's nothing to do to modularity until October 31?
20:46:55 <gotmax[m]> But 203 is just continuing the discussion we had last week about preemptively adding epel-packagers-sig to packages
20:46:59 <salimma> we probably want to remember to tag it again for the meeting after that for recap. I wish there's a way to do that
20:47:48 <carlwgeorge> i plan to take a look at creating a non-modular cobbler package just to prove it can be done
20:47:56 <carlwgeorge> (as a replacement for the cobbler module)
20:48:15 <gotmax[m]> Nodejs is also a good example
20:48:34 <gotmax[m]> Does anyone have feedback about the ideas in 203?
20:48:45 <tdawson> Yes.
20:49:16 <carlwgeorge> it's a little weird because rhel8 ships koan/python3-koan in the rhn-tools module (default stream), which are built from the cobbler srpm.  those later split to their own spec file so the cobbler from f35 doesn't have those subpackage, so i think it's just a matter of renaming the spec file to cobbler-epel.
20:49:33 <gotmax[m]> tdawson: Which question are you answering :)?
20:49:41 <tdawson> About the idea of tagging all epel branches withthe epel-packagers-sig, I have mixed emotions.  It would be convenient.  But I'm already starting to get ALOT of pull request noise from packages I don't really own.
20:50:33 <nirik> yeah, wonder if there's some way to tag that kind of thing better.
20:50:34 <tdawson> I've missed a couple of pull requests that legitimatly are mine, because they got lost in epel-packagers-sig pull request noise.
20:50:36 <salimma> email filters? the packaging dashboard has a toggle too so you can toggle between 'all SIG packages / SIG packages I am on the ACL directly / no SIG packages"
20:50:48 * nirik often has to look at PR's and say 'why did I get copied about this?'
20:52:01 <gotmax[m]> nirik: We could create a future-meeting tag or something
20:52:06 <nirik> The problem is that there's no one-size-fits-all
20:52:24 <tdawson> The packaging dashboard, that is nice, but as far as I can tell it can't control emails.
20:52:50 <gotmax[m]> tdawson: For Bugzilla, I believe the Bugzilla Product is available in the email's headers
20:52:55 <gotmax[m]> so you could filter Bugzillas
20:52:57 <gotmax[m]> but not PRs
20:52:58 <salimma> yeah, but you can check your PRs in the dashboard :)
20:53:00 <nirik> FMN is being re-written, so now's a good time to get RFE's in.
20:53:05 <carlwgeorge> it's fine, if you miss an email and it's important eventually someone will dm you about it
20:53:13 <salimma> you can filter pagure emails by who they're sent to, I think
20:53:14 * carlwgeorge doesn't recommend following his approach to email
20:53:33 <salimma> pretty sure I have it set up that way, I can look it up after this (need yubikey to log in to my email)
20:54:13 <tdawson> The problem is that salimma, or someone else adds a package to epel-packagers-sig, and I'm fine with that, but then I don't know about that package until someone does a pull request on it ...
20:55:11 <tdawson> To be honest, the problem isn't that bad, I can handle it.  But if we put all epel packages on the epel-packagers-sig ... then I see a huge problem.
20:55:14 <salimma> tdawson: true. I wonder how the Python SIG does it
20:55:31 <salimma> Rust SIG seems to want to be on every package, so that's not an ideal comparison
20:55:37 <rsc> Don't they use a mailing list?
20:55:48 <nirik> perhaps we instead should look at making epel-packagers-sig more like provenpackager for epel* branches?
20:55:48 <carlwgeorge> i also have trouble finding emails i want to action from the python-sig notifications
20:56:16 <nirik> and then make it default... but that might be controversial.
20:56:19 <carlwgeorge> many of the python packages enforce a pr workflow (a good thing), but that means a lot of pr notification emails
20:56:45 <salimma> nirik: ideally it should work that way, yeah
20:57:29 <salimma> actually, what do we need to do that. just changes to src.fp.o to support branching right?
20:58:14 <tdawson> What about if we automatically branch a package if it was in the previous epel release.  Not do anything to it, just branch it.  Branching has been our biggest issue.
20:58:15 <salimma> if we do that we should probably revisit how provenpackagers actually works. right now it ignores the PR workflow setting - which is probably nice in emergency, but I'd prefer it warns me first
20:58:19 <nirik> I'm not sure. I think it would need changes in hooks and possibly pagure-dist-git
20:58:23 <salimma> tdawson: ooh yeah
20:58:35 <salimma> branch automatically but keep empty
20:59:07 <salimma> after all, we can't automatically determine what's the best version (or even working version) to put in the new branch
20:59:15 <nirik> that could be pretty confusing. would make it hard to tell whats actually in epel?
20:59:32 <smooge> and the usual 'I see its branched, why isn't it built?'
20:59:46 <smooge> sorry 'whhhhhyyyyyyyyyyy'
20:59:49 <gotmax[m]> Yeah, I suggested adding epel-packagers-sig to every package at the end of the ticket. That's the best way I can think to make the epel-packagers-sig more like provenpackagers for EPEL. But then we go back to the problem with who's responsible for what. Whoever branches a package should be the EPEL BZ assignee.
21:00:24 <carlwgeorge> i actually really like tdawson's suggestion
21:00:27 <salimma> and... we have a granularity problem too, since the person who want to maintain it is likely different per branch
21:00:30 <nirik> wonder if we could have default assignees for pr's too. ;)
21:00:39 <carlwgeorge> make an faq item for branch != built, and call it good
21:01:36 <tdawson> Looks like our time is up.  I know we haven't really finished this discussion, but I'm calling it a meeting.
21:01:44 <smooge> good
21:01:46 <gotmax[m]> tdawson: What problem would automatic branching solve?
21:01:49 <salimma> but hmm yes, if we have auto branching but the SIG is not in the ACL, only the ACL members plus provenpackagers can build
21:02:03 <carlwgeorge> last thing for open floor, lots of cve fixes inbound for epel7 packages: git-lfs, luajit, python3-mod_wsgi
21:02:10 <tdawson> Thank you all for the good discussions.  We'll talk to you next week, if not sooner.
21:02:11 <salimma> whereas if you're already in the ACL, not auto branching just means you have to file request-branch and wait a few hours
21:02:19 <tdawson> carlwgeorge: Ya!!!
21:02:22 <gotmax[m]> tdawson: Sorry, I saw that after I sent my message.
21:02:28 <gotmax[m]> Bye everyone!
21:02:32 <salimma> bye all!
21:02:35 <salimma> back to watching conferences
21:02:40 <gotmax[m]> carlwgeorge: Thanks for your work on that!
21:02:44 <tdawson> #endmeeting