21:00:13 <tdawson> #startmeeting EPEL (2022-11-30)
21:00:13 <zodbot> Meeting started Wed Nov 30 21:00:13 2022 UTC.
21:00:13 <zodbot> This meeting is logged and archived in a public location.
21:00:13 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
21:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:13 <zodbot> The meeting name has been set to 'epel_(2022-11-30)'
21:00:14 <tdawson> #meetingname epel
21:00:14 <zodbot> The meeting name has been set to 'epel'
21:00:16 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge
21:00:16 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson
21:00:17 <tdawson> #topic aloha
21:00:29 <michel-slm> .hello salimma
21:00:30 <zodbot> michel-slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
21:00:37 <smooge> hello
21:00:38 * nirik is here, but also starting a outage, so ping me if you need me.
21:00:47 <tdawson> Hello smmoge and michel-slm
21:00:56 <salimma> #chair michel-slm
21:00:56 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] michel-slm nirik pgreco salimma smooge tdawson
21:00:59 <carlwgeorge> .hi
21:00:59 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
21:01:09 <tdawson> nirik: Will do.  good luck with the outage
21:01:13 <tdawson> Hi carlwgeorge
21:02:22 <davide> .hello dcavalca
21:02:23 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
21:02:37 <tdawson> pgreco will not be here this week.  He didn't have any extra business to cover.
21:02:41 <tdawson> Hello davide
21:02:46 <neil> o/ heya folks
21:02:59 <tdawson> Heya neil
21:03:01 <neil> (no new business, just hanging out)
21:03:02 <michel-slm> howdy
21:03:20 <tdawson> neil: Always good to see you.
21:03:26 * michel-slm thought for a split second neil is another Neal nick
21:04:16 <smooge> no thats Nael
21:04:48 <smooge> but only when he goes through the Superman canon instead of anime and is Na-el
21:05:09 <tdawson> *laughs and sighs*
21:05:17 <tdawson> #topic End Of Life (EOL)
21:05:18 <tdawson> RHEL 7 will go EOL on 2024-06-30
21:05:20 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
21:05:21 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
21:05:39 <tdawson> Oddly enough, these dates might have something to do with a later discussion.
21:05:48 <smooge> they are getting closer and closer
21:05:59 <tdawson> Yep
21:06:05 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
21:06:06 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
21:06:46 <tdawson> We don't have anything marked with meeting ... which is going to leave alot of time for our one "Old Business" discussion
21:06:58 <tdawson> #topic Old Business
21:07:04 <tdawson> EPEL 10 proposal
21:07:06 <tdawson> https://discussion.fedoraproject.org/t/epel-10-proposal/44304
21:07:12 <carlwgeorge> wheee
21:07:28 <carlwgeorge> thanks everyone that's replied so far with feedback/questions
21:07:56 <davide> thanks for putting this out carlwgeorge, I'm really looking forward to epel 10
21:08:18 <neil> ditto. Thank you carlwgeorge
21:08:21 <carlwgeorge> i was surprised that someone asked if we could backport it to epel 9
21:09:00 <gotmax> I'm mostly enthusiastic about the proposal, but I'm worried about casual EPEL packagers and security fixes/bug fixes not getting backported properly
21:09:14 <gotmax[m]> #chair gotmax
21:09:14 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax gotmax[m] michel-slm nirik pgreco salimma smooge tdawson
21:09:37 <carlwgeorge> i don't think it will be any worse than the current situation.  many cves are ignored for years in epel.
21:09:48 <tdawson> carlwgeorge: I'm a little curious about the discussion about getting releng help.  How realistic does it sound for either a new person for releng, or Red Hat epel people getting the right permissions?
21:10:15 <tdawson> Talking about cve's, thanks to dherrera for giving me a patch to put priorities in willit
21:10:17 <michel-slm> yeah, we tried attacking the CVEs for a while but I think there's stil lmany left
21:10:31 <gotmax> Also, would it be possible to make epel10 point to epel10.10 once CentOS Stream is retired instead of completely retiring the epel10 branch?
21:10:47 <nirik> I think it's completely possible to get perms to folks if they are around long enough and willing to do the work. ;) Or have them automate things.
21:10:49 <carlwgeorge> tdawson: the latter sounds realistic and i believe has buy in from nirik.  the former would be a less likely stretch goal.
21:10:57 * davide would be happy to pitch in and help make this happen
21:11:35 <michel-slm> right. it's roadmap planning season for us at Meta so happy to allocate some time for this if we can decide soon what external contributors can realistically touch
21:11:56 <carlwgeorge> gotmax: what's the benefit of that?  seems like added confusion to me to change what the epel10 branch means halfway through the rhel10 lifecycle.
21:12:03 <tdawson> nirik: carlwgeorge: That's good to hear.  That's one of my worries, is overwheming releng.
21:12:09 <nirik> well, this is also like 2 years away right?
21:12:30 <carlwgeorge> yes, that
21:12:53 <nirik> I think a good thing might be to watch/shadow the next fedora mass branching and help automate that more/identify things that could be reused for epel...
21:13:25 <carlwgeorge> a little birdie told me that the first c10s composes will be towards the end of 2023, so we could really get things started then (about a year away)
21:14:02 <michel-slm> EPEL <3 Rawhide
21:14:25 <carlwgeorge> and probably a full real launch about a year after that, around the same time that centos does their 10 promotion
21:14:27 <smooge> so 2 years from final release, 12 months from metal to the road
21:14:55 <smooge> or something like htat if english was my first language
21:15:11 <gotmax> carlwgeorge: I think slightly changing the meaning of `epel10` is better than completely getting rid of it part way through RHEL 10's lifecycle.
21:15:42 <carlwgeorge> but why change it?  what's the benefit?
21:16:16 <michel-slm> if the 'epel10' name is confusing may I propose 'epel10-stream'
21:16:19 <smooge> carlwgeorge, gotmax I think you two are talking past each other
21:16:37 <smooge> too many side conversations to focus on what is wanted between the two
21:16:37 <gotmax> For people that only have epel10 branches are used to building for that, things would still work after Stream is retired without extra steps
21:16:38 <michel-slm> so it matches directly, and then retag everything into epel10.0, epel10.1, etc.
21:17:11 <gotmax> > After the end of life date for CentOS Stream 10, the epel10 branch would be retired and all work would take place directly on the epel10.10 branch.
21:17:16 <gotmax> is what I'm referring to
21:17:29 <davide> I'm also not following here tbh
21:17:30 <carlwgeorge> it would be the same number of steps to build in the epel10.10 branch as it would be to build in the epel10 branch
21:17:41 <davide> epel10 tracks Stream, so it seems reasonable that it'd be retired when Stream is EOL
21:18:01 <davide> I think I agree with Carl that changing its meaning mid-flight would be confusing
21:18:12 <gotmax> carlwgeorge: You'd have to request an epel10.10 branch and wait for it to be approved
21:18:17 <davide> especially as by that time, we'd have epel11 in flight as well already
21:18:31 <davide> so you'd end up with epel10 and epel11 having different semantics
21:18:42 <smooge> and I think I see where gotmax is coming from.. lots of people are going to use epel10 out of history on regular os and such.. and then have it disappear on production boxes
21:18:44 <carlwgeorge> my plan is to have all the minor version branch creation automated
21:19:37 <michel-slm> agreed about people having the wrong image of what epel10 means, which is why I suggested explicitly adding stream to its name. a bit long though
21:19:43 <carlwgeorge> i agree with davide's point about having epel10 and epel11 mean different things
21:19:45 <michel-slm> epel10s
21:20:02 <smooge> no I think epel10-stream works better.
21:20:25 <carlwgeorge> smooge: production boxes would point to a 10 symlink to a repo and not be disturbed by branch retirements at all
21:20:26 <michel-slm> yeah, shortening -stream to s is not worth it prboably
21:20:38 <davide> I don't think adding -stream to the branch name actually improves this, but I wouldn't veto it if that's what everybody agrees on
21:20:38 <smooge> I think that my objections to epel8-stream and going with epel8-next have proven me to be an idiot
21:20:47 <carlwgeorge> for whatever it's worth, i'm against putting stream in the name for all the same reasons we didn't name epel-next epel-stream
21:21:23 <gotmax> carlwgeorge: Maybe auto branching changes the equation a bit, but I'm still uneasy about getting rid of the `epel10` branch when EPEL 10 is still supported.
21:21:38 <michel-slm> when RHEL 10 you mean
21:21:45 <gotmax> carlwgeorge: Agreed. `Stream` is a cliche that's lost all meaning that this point.
21:22:01 <gotmax> EPEL 10 is supported as long as RHEL 10 is supported
21:22:10 <nirik> I think stream is a bit misleading there too...
21:22:13 <michel-slm> do we see more RHEL 10 minor releases after Stream 10 is EOL? is it just 10.10?
21:22:21 <nirik> because it's stream, but with cutoffs for minor releases.
21:22:21 <tdawson> I wouldn't mind calling it epel10-next ... but I think if we do that, it would add confusion.
21:22:23 <davide> epel10-rawhide
21:22:25 * davide ducks
21:22:35 <neil> 😂
21:22:36 <carlwgeorge> make sure to enable that module stream from the appstream repo on centos stream, which is not the same thing as the appstream package which is also in the appstream repo
21:22:47 <tdawson> *laughs*
21:22:59 <michel-slm> yeah, -next is probably better than stream if we not already have it work differently for 8 and 9
21:23:02 <tdawson> If only that didn't make sense.
21:23:04 <nirik> epel10-wascentos ?
21:23:13 <carlwgeorge> michel-slm: nope, 10.10 is the final minor version and marks the end of c10s
21:23:14 <davide> in all seriousness, just using still epel10 seems the least bad option here...
21:23:15 <michel-slm> epel10.x
21:23:15 <dherrera> I feel that leaving just epel10 has the advantage that it already uses a naming scheme that is known by epel users, and incentivices to add new packages directly there (hi btw)
21:23:17 <smooge> epel10-naming-is-hard
21:23:29 <michel-slm> intentionally put x there to indicate it's floating
21:23:46 <davide> epel10.∞
21:23:55 <neil> throw a zero width space in for **fun**
21:23:58 <michel-slm> but yeah since the alternatives all seem bad I guess epel10 wins by default and we should not bikeshed this too much
21:24:01 <gotmax> Maybe renaming epel10 and having no epel10 branch is better than completely changing its existing meaning now that I think about it
21:24:04 <michel-slm> neil: then we can see who leaks!
21:24:27 <carlwgeorge> also, some users will still request an epel10 branch out of habit.  having that rejected because they didn't ask for epel10-<suffix> is not a good experience.
21:25:17 <carlwgeorge> i would prefer someone who does that at least get a branch that populates the centos epel repo, which later gets into the next rhel epel repo
21:25:21 <michel-slm> if we really want to rename we should make requesting 'epel10' automatically request that, and have 'epel10' point to 'epel10-<suffix>' like main now points to rawhide.
21:25:29 <gotmax> Meh, I guess. However, if we're going to keep it as `epel10`, I don't think we should retire it half way through
21:25:30 <michel-slm> but does not seem to be worth it, the more we go into details
21:25:55 <michel-slm> compromise: when c10s is retired, make epel10 branch be an alias for epel10.10 ?
21:26:11 <carlwgeorge> michel-slm: that's what gotmax suggested
21:26:12 <neil> what michel-slm just said was what I was going to suggest
21:26:17 <bstinson> i think there's enough runway to start with epel10 and handle retirement semantics at a later time
21:26:20 <davide> michel-slm: wouldn't that break things for people with existing checkouts?
21:26:29 <tdawson> I agree with gotmax on this.  If they are use to creating epel10 branches, then halfway through that breaks, not a good eperience.
21:26:32 <neil> or never make a epel10.10 as epel10 == epel10.10, once c10s is retired
21:26:34 <davide> or at least be really confusing, especially if the branches had diverging history by that point
21:26:39 <tdawson> Hi bstinson
21:26:58 * gotmax notes that Pagure has the ability to create aliases like `main -> rawhide`
21:27:11 <gotmax> They are handled server side
21:27:35 <tdawson> I like neil's idea.  Change the epel10 branch to bet the epel10.10 branch.
21:27:45 <michel-slm> davide: good point
21:28:00 <gotmax> epel10 could could just be an alias to the next epel10.X branch
21:28:09 <davide> I guess the way this could maybe work is if we had epel10-stream since the beginning, and epel10 aliased to it
21:28:10 <michel-slm> yeah, if once c10s is gone epel10 means 10.10 that's ok
21:28:11 <carlwgeorge> i think that would break existing checkouts as davide pointed out
21:28:19 <tdawson> Beyond the branch name ... I think the other main concern I saw / see is for "casual maintainers"
21:28:19 <davide> and then later realias epel10 to epel10.10
21:28:22 <michel-slm> and make epel10.10 point to epel10 for consistency, then we're done right?
21:28:29 <davide> but like... this is a lot of moving parts
21:28:44 <davide> I'm not convinced it's actually better
21:28:53 <carlwgeorge> same
21:28:53 <michel-slm> if you're a casual maintainer and only ever touch epel10, your packages will migrate to epel10.x (for x in 1-9) automatically and once they're gone you still have your branch that tracks 10.10
21:28:59 <gotmax> carlwgeorge: It wouldn't affect existing checkouts as long as we copied the contents when we switched the aliases
21:29:38 <tdawson> michel-slm: Yes and no.  If you are a casual mainatiner, you build for epel10, then wonder why your package isn't available for RHEL/Alma/Rocky
21:29:40 <smooge> I am going to go with bstinson and say we have a general idea of what we want to do in 10.10 but reserve the right to change our mind
21:29:50 <davide> do we know for a fact that 10.10 will only exist after Stream EOL?
21:30:07 <davide> if there's an overlap between Stream and 10.10 just changing the alias doesn't work
21:30:18 <davide> as you'll end up with conflicts if the branches diverge
21:30:20 <tdawson> I second smooge ... that's 6 to 7 years down the road, plenty of time to figure it out.
21:30:21 <smooge> we focus on getting the first parts working as they are going to be a 'f*ckload' of work more than the end time
21:30:29 <carlwgeorge> gotmax: is that something you've tested?  i've never tried to see what actually happens to a local checkout when a remote branch changes into an alias.
21:31:04 <carlwgeorge> davide: yes, unless rhel changes it's model
21:31:33 <davide> ok, so at least that concern goes away
21:31:34 <michel-slm> agreed with smooge and tdawson that we should just not nail down what happens post c10s EOL now
21:31:42 <carlwgeorge> 10.10 marks the start of the maintenance phase (no more minor versions), the end of the full support phase, and the eol of c10s
21:32:02 <davide> but yeah, +1 on not getting stuck on EOL specifics now, given that none of this exists yet
21:32:07 <michel-slm> at that time RHEL 10 will be perfect :)
21:32:55 <bstinson> we're learning :)
21:32:56 <carlwgeorge> jim perrin used to tell the joke after the c6 eol that people could finally deploy it because it was finally stable, for real
21:32:57 <gotmax> carlwgeorge: I'm not exactly sure what you mean.
21:33:18 <gotmax> You can push or pull from origin/main or origin/rawhide and they both go to the same place
21:34:19 <carlwgeorge> yes, but main was a new alias and wasn't a branch name before.  what happens to a branch name that changes into a branch alias?  it may work just fine but i'd like to know for sure.
21:34:43 <michel-slm> maybe we should... continue this at a later date?
21:34:47 <tdawson> I think for the casual maintainer, or the first time maintainer, good documentation is a must.
21:34:51 <michel-slm> is there any action we need to take now for the rest of the proposal?
21:35:23 <smooge> hey could we move along here?
21:35:27 <carlwgeorge> adrian brought up some mirrormanager concerns around the symlinks, i'll need to talk with him more to make sure we're prepared there
21:35:31 <smooge> or what michel-slm said
21:36:14 <tdawson> smooge: I think smooge is right.  Alot of this can do onto the discussion board.  Are we ok moving on?
21:36:38 <carlwgeorge> works for me
21:37:02 <tdawson> Of course ... the problem with that is I don't have much else, that's all the old business.
21:37:11 <tdawson> #topic General Issues / Open Floor
21:37:34 <michel-slm> ooh I have one
21:37:42 <tdawson> michel-slm: Go for it.
21:37:58 <michel-slm> so after RHEL 9.1 is released, all those tickets about retiring packages newly added to RHEL become actionable
21:38:29 <tdawson> Correct, and many have already been acted on.
21:38:30 <michel-slm> I happened across one yesterday that... indicates some procedures probably need to be improved. see https://bugzilla.redhat.com/show_bug.cgi?id=2149497
21:39:07 <michel-slm> python-greenlet was added to RHEL, so it should be retired from EPEL. *but* it provides a -devel subpackage, which is used by two other EPEL packages
21:39:13 <michel-slm> and the -devel subpackage is missing from CRB
21:39:20 <smooge> of course it is
21:39:28 <gotmax> :(
21:39:29 <carlwgeorge> that's definitely something to look out for, good thing you caught it
21:39:52 <michel-slm> it happened to pop on my packager dashboard, it's not actually my package (but group-maintained)
21:40:30 <michel-slm> is there anyway we can ... have whatever process file those EPEL2RHEL bugs also automatically flag if there are -devel subpackages?
21:40:48 <gotmax> Can we keep that component and just remove its non -devel subpackages until the -devel package is added to CRB?
21:40:52 <michel-slm> (oh huh, I *am* a comaintainer, it turns out)
21:41:20 <michel-slm> yeah, I was thinking either remove the main package (though to match our guidelines the package really needs to be renamed to -epel)
21:41:23 <carlwgeorge> using the same component would still result in a srpm conflict
21:41:31 <michel-slm> right
21:41:33 <tdawson> That's a very good think to look at in the automation.
21:41:57 <carlwgeorge> i think when this has happened before we just deferred the retirement until the devel package was added
21:41:59 <michel-slm> what's the likelihood that the EL maintainer prioritize adding it to CRB, since.. by right it should have been? if high then we can just wait
21:43:24 <michel-slm> at least the NVR is higher on the RHEL side
21:43:24 <smooge> well has a request to the el maintainer to have tha thappen?
21:43:37 <michel-slm> yes, the bug I linked is for the CRB request
21:43:42 <tdawson> It's very possible they won't notice until we tell them.  I know that some do notice, but several don't.
21:43:44 <carlwgeorge> as much as we would like it to be "right" to just add the devel package, doing so is a separate decision for the rhel maintainer
21:43:44 <smooge> ok sorry missed that
21:43:52 <michel-slm> (because that's the one I have bookmarked; the retirement request is marked as blocked on it)
21:44:01 <michel-slm> np
21:44:45 <carlwgeorge> often they don't care and happily do it, but sometimes they have specific reasons for not wanting to promote building against the devel package, in which case we'd go for python-greenlet-epel
21:45:05 <bstinson> i put that BZ on my roundup list. i can check on it again in a few days if there's no answer
21:45:12 <michel-slm> bstinson: thanks!
21:45:23 <carlwgeorge> lovely having you here bstinson, for things like this
21:45:29 <michel-slm> is the epel2rhel automation public, or is that something only RH folks can work on
21:46:42 <tdawson> As I was going through my -epel packages, I remembered that I have one where they cared so much, that they changed the spec file so it didn't produce the sub-package I needed.  That's when you know they are serious about it not going into CRB.
21:47:18 <tdawson> michel-slm: It's very internal.
21:47:42 <tdawson> At least the part that looks at EPEL and creates the bugzilla's.
21:47:54 <michel-slm> oh wow, looking at the history, this package keeps flip flopping
21:47:56 <michel-slm> https://bugzilla.redhat.com/show_bug.cgi?id=2046450
21:48:18 <michel-slm> greenlet was in RHEL 8, not in 9 so it got added to epel, then... added again in 9.1
21:48:43 <michel-slm> tdawson: yeah. I wonder how in that case RHEL folks use it to build thigns
21:48:57 <smooge> buildroot only maybe?
21:50:21 <nirik> oh, FWIW, I am thinking of dropping out of the epel-package-maintainers group... it's giving me too much info I shouldn't act on. Making it harder to focus on all the packages I do have...
21:50:55 <tdawson> michel-slm: It's part of the "Add a package to RHEL" process.  It's rather strange and I don't know if there is code behind it, or just Jira "scripts" or what.  But things happen, so something is behind it.
21:51:22 <tdawson> nirik: Understood.
21:52:30 <nirik> I wonder if the new FMN could include a 'you are getting this email because you are in group Z and it's watching package foo'
21:52:38 <michel-slm> nirik: you'll be missed, but totally understood
21:52:51 <tdawson> On something I mentioned earlier.  dherrera's change to willit makes looking for high priority CVE's much much easier - https://tdawson.fedorapeople.org/epel/willit/epel8/status-bugz-cve.html
21:53:45 <carlwgeorge> awesome, good job dherrera
21:53:54 <nirik> well, I am happy to do stuff for epel-package-maintainers, just someone will have to ask me to.
21:53:55 <michel-slm> nice!
21:54:06 <dherrera> :) yeah, it let me find an easy to fix important thing on python-twisted :9
21:54:08 <carlwgeorge> next step would be making those sortable columns
21:54:15 <michel-slm> dherrera++
21:54:15 <zodbot> michel-slm: Karma for dherrera changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
21:54:18 <smooge> ok I have to head out. good luck for the evening
21:54:38 <michel-slm> any interest in plugging toddlers to willit so we can automate filing bugs?
21:55:00 <michel-slm> (I can allocate some time for this if it's of interest)
21:55:05 <tdawson> I've never figured out toddlers ... I'd need some help with that.
21:55:38 <michel-slm> I have not used toddlers either, but seems worth exploring (as there's talk about using it for automatic branch creation which has not happened yet)
21:55:40 <tdawson> I really should put willit in it's own git repo ... I think I'll do that this week so people don't have to wade through my other wierd scripts to get to it.
21:55:51 <michel-slm> tdawson: that'll be nice!
21:56:18 <neil> tdawson: if you're not allergic to javascript, datatables.net is pretty easy (and MIT licensed)
21:58:03 <tdawson> I was just looking at a page that has searchable headers ... and looks like they juse datatables.net  ... ok, I'll look into it.
21:58:23 <tdawson> It looks like we're coming to the end of the meeting, anything urgent before we close?
21:58:28 <neil> you can see it in action here http://incoming.releng.rockylinux.org/
21:58:52 <gotmax> tdawson: Nothing from me
21:59:00 <tdawson> neil: Very nice
21:59:34 <tdawson> Thank you all for the good discussions, and for all your help and work on EPEL and it's community.
21:59:40 <tdawson> I'll talk to ya'll next week, if not sooner.
22:00:05 <tdawson> #endmeeting