20:00:17 <tdawson> #startmeeting EPEL (2022-10-12)
20:00:17 <zodbot> Meeting started Wed Oct 12 20:00:17 2022 UTC.
20:00:17 <zodbot> This meeting is logged and archived in a public location.
20:00:17 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:17 <zodbot> The meeting name has been set to 'epel_(2022-10-12)'
20:00:18 <tdawson> #meetingname epel
20:00:18 <zodbot> The meeting name has been set to 'epel'
20:00:20 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] smooge
20:00:20 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma smooge tdawson
20:00:21 <tdawson> #topic aloha
20:00:29 <rcallicotte> .hi
20:00:30 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org>
20:00:35 <carlwgeorge> .hi
20:00:35 <pgreco> .hi
20:00:35 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:00:38 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:00:47 <dherrera> .hi
20:00:48 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com>
20:00:49 <tdawson> Hi rcallicotte carlwgeorge and pgreco
20:00:49 <pgreco> I'm back, sorta, recovering from the trip :D
20:00:56 <salimma> .hi
20:00:57 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
20:01:04 <tdawson> Hi dherrera and salimma
20:01:19 <salimma> Davide has a conflict but sent me his preference for modularity
20:01:25 <Ebeneezer_Smooge> hello. I am here to step on my own proposal
20:01:31 <tdawson> pgreco: I hope it's just jet-lag you are recovering from, and not some sickness.
20:01:36 <nirik> morning
20:01:53 <tdawson> Hi Ebeneezer_Smooge
20:02:09 <tdawson> morning nirik
20:02:41 <gotmax[m]> .hello gotmax23
20:02:42 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
20:02:46 <tdawson> Hi gotmax[m]
20:03:50 <tdawson> Wow ... we've got pretty much everyone here already ... except davide, who has a conflict.
20:03:56 <pgreco> yeah, jet-lag and 2nd booster
20:04:07 <tdawson> pgreco: Ooof
20:04:20 <gotmax[m]> I'm on the Ansible Community Steering committee now, so I now have two steering committee meetings Wednesday afternoon within two hours of each other. Fun times :)
20:04:46 <rcallicotte> nice
20:04:48 <tdawson> Ya!! the fun never ends. :)
20:05:09 <gotmax[m]> Feel better Davide Cavalca!
20:05:10 <tdawson> #topic End Of Life (EOL)
20:05:11 <tdawson> RHEL 7 will go EOL on 2024-06-30
20:05:13 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31
20:05:14 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31
20:05:18 <tdawson> Time marches on ...
20:05:18 <rsc> .hello robert
20:05:21 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:05:28 <tdawson> Hi rsc
20:05:33 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues
20:05:34 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open
20:05:46 <salimma> gotmax (He/Him): I think you mean pgreco :)
20:05:49 <tdawson> Let's start with the one you all came fore.
20:06:07 <tdawson> .epel 198
20:06:08 <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:06:22 <tdawson> Ebeneezer_Smooge: I'll turn it over to you
20:06:53 <Ebeneezer_Smooge> OK so one of the prolems with the aggressive date I originally proposed is that a lot of Enterprises have already started year-end freezes.
20:07:51 <Ebeneezer_Smooge> Updates and changes to infrastructure will be locked down for Nov/Dec/Jan and this change to modular content would cause issues
20:08:29 <Ebeneezer_Smooge> I would like to propose pushing back the 'getting the axe' to February 14th. We can make it a St Valentine's massacre instead
20:09:00 <Ebeneezer_Smooge> And we would put through multiple documentation in the next month on what could happen and how to deal with it
20:09:03 * nirik is fine with that. no particular rush here.
20:09:08 <rcallicotte> That seems reasonable to me
20:09:25 <tdawson> I'm good with that.
20:09:37 <Ebeneezer_Smooge> End of Post
20:09:38 <carlwgeorge> nothing against waiting longer, although for enterprises that are frozen over the year end i'm not sure what difference it makes
20:09:58 <salimma> oh, that's a good point. I didn't think about it because (a) we already disable most modules and (b) we snapshot the repos
20:10:07 <salimma> I like how we're keeping it special :)
20:10:11 <tdawson> This issue says Feb. 15th ... are you ok with working during a commercially made up holiday?
20:10:18 <rcallicotte> salimma: same here
20:10:49 <nirik> there may be some action needed for satalitte using folks? or no?
20:10:51 <gotmax[m]> Me too
20:10:52 <Ebeneezer_Smooge> Feb 15th is close enough to still be valentines day
20:11:05 <Ebeneezer_Smooge> nirik, that isn't clear and we need to figure that out
20:11:54 <Ebeneezer_Smooge> trying to figure that out by Oct 31st as a volunteer would not be easy for me
20:12:04 <salimma> I guess the problem is if something goes wrong that we don't anticipate, or if the enterprises think something can go wrong
20:13:07 <tdawson> I'm fine with the revised proposal.  The second E in EPEL stands for Enterprise, and one month for a change is rather fast for an Enterprise.
20:13:29 <pgreco> Ebeneezer_Smooge: date seems ok, by that time we'll be closer 8.8 and that will die in archive...
20:14:14 <Ebeneezer_Smooge> Time for a vote?
20:14:19 <tdawson> Yep
20:14:30 <rsc> Can't we align the modularity drop with a Y release?
20:15:17 <tdawson> rsc: That would push it to May ... or Novemember.
20:15:28 <rsc> Uh, okay. I'm taking back my question.
20:15:45 <tdawson> November even.
20:16:12 <tdawson> Any other questions?
20:16:17 <salimma> yeah, if we don't want to delay to Feb, then aligning with November makes sense. but nov 23 is too far
20:16:17 <dherrera> feb sounds far enough
20:16:29 <pgreco> feb for builds, may for archive (release)
20:16:31 <pgreco> and never again
20:18:07 <tdawson> Any comment on pgreco's proposal?
20:18:13 <Ebeneezer_Smooge> nirik, one reason I had for forcing an archive and change in mirrors was that i was worried that the composes would wipe out /pub/epel/8/Modular at some point. I don;'t know if that was reasonable or not
20:19:09 <nirik> I would expect we would remove the part that syncs it when we disable things...
20:20:31 <tdawson> So ... double checking, are we ready for a vote?
20:20:38 <Ebeneezer_Smooge> ok in that case I think we could stop the builds in February and kill the downloads in the original place without problems
20:20:39 <tdawson> We seem paused.
20:20:56 <Ebeneezer_Smooge> I had a point of information. I am ready to vote
20:21:02 <Ebeneezer_Smooge> +1
20:21:21 <nirik> sure. +1
20:21:23 <pgreco> I'm +1 for whatever is easier ;)
20:21:27 <rcallicotte> +1
20:21:31 <salimma> +1 for archiving in feb
20:21:36 <carlwgeorge> +1
20:21:39 <tdawson> +1
20:21:44 <salimma> whatever Smooge wants to do :)
20:21:58 <dherrera> +1
20:22:33 <tdawson> rsc and gotmax[m] ... are you for or against?
20:22:43 <gotmax[m]> +1 to archiving then
20:22:58 <rsc> +1 for the easier way
20:23:45 <tdawson> salimma: Was davide for it?
20:24:08 <salimma> Davide said he doesn't care if it's delayed
20:24:20 <salimma> so I guess +1 or 0 ?
20:24:26 <tdawson> #info Proposal to push modularity removal back to Feb. 2023:  10 for, 0 against
20:24:40 <tdawson> I marked him as +1
20:25:16 <tdawson> I'll move forward on the articles then.
20:25:28 <Ebeneezer_Smooge> thanks everyone.
20:26:12 <tdawson> epel-release ... should we go ahead and push that out to stable?
20:27:19 <gotmax[m]> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-1244a58967 disables the modular repos by default, so I don't think so
20:27:46 <carlwgeorge> would could push that to stable on halloween, it wouldn't affect enterprises that are frozen
20:28:04 <carlwgeorge> if they apply that update, then they aren't frozen
20:28:23 <tdawson> That's sorta what I was thinking.
20:28:27 <carlwgeorge> then save the rest of the changes for feb
20:29:52 <tdawson> That would allow people to see what really changes if their modularity is off.
20:30:41 <Ebeneezer_Smooge> I am ok with it
20:30:55 <Ebeneezer_Smooge> I am actually ready to talk about anything but modularity
20:31:00 <gotmax[m]> It shouldn't affect existing systems or Satellite
20:31:18 <salimma> nice
20:31:30 <salimma> yeah, push that out on Halloween so it's not blocking anyone else if we need to make other changes to epel-release
20:32:27 <tdawson> OK, I'll put that into the articles as well.
20:32:46 <tdawson> And with that, I'm going to "timebox" this issue.
20:33:50 <tdawson> It looks like the other three items marked with "meeting" are on our "give us a few more weeks" ... unless someone wants to specifically bring one up.
20:34:35 <gotmax[m]> There was some discussion on 203 since the last meeting. Link:
20:34:36 <gotmax[m]> .epel 203
20:34:37 <zodbot> gotmax[m]: Issue #203: Automating adding epel-packagers-sig to packages - epel - Pagure.io - https://pagure.io/epel/issue/203
20:34:54 * nirik isnt sure what he thinks of that one...
20:35:35 <tdawson> I too am unsure.
20:35:44 <gotmax[m]> I think carlwgeorge's idea to automatically branch but not build packages that were built for the last EPEL release makes sense
20:35:54 <salimma> I'm knee deep on trying to get the mailman stack branched on epel9, so... anything that's better than the current state is welcome
20:35:57 <carlwgeorge> it was tdawson's idea :D
20:36:04 <tdawson> One the one hand, it would be nice so it would be easier to get packages branched for epel10 ... on the other ... I've already got the permissions setup for all the packages I need to branch.
20:36:06 <carlwgeorge> i'm just a fan
20:36:28 * gotmax[m] keeps confusing who did/said what in this meeting :)
20:36:44 <salimma> if there's better attribution (ideally 'owner has an easy way to say I don't care about EPEL', in which case 'whoever touches EPEL branch X last should get bugs assigned to them')
20:36:51 <carlwgeorge> i like the idea of having a pull request workflow as the entry point for packagers to add something to epel10
20:37:16 <salimma> if we have that sort of magic, it will make things much easier
20:37:29 <salimma> carlwgeorge: who gets to review and merge them though?
20:37:32 <nirik> long ago we used to have a wiki page for that. :)
20:38:17 <salimma> but oh if it's ok for language SIGs I'm OK trying to see if it is OK for us too
20:38:17 <gotmax[m]> I do think it makes sense for packagers to have a way to opt out of the automatic branching
20:38:23 <carlwgeorge> still needs someone with commit on the package to merge and build
20:38:48 <gotmax[m]> Or a provenpackager, but I think we should have a rule about when/if that's allowed
20:39:16 <nirik> yeah, this plan breaks one assumption...
20:39:26 <gotmax[m]> It was previously decided that provenpackagers should not be able to branch packages for EPEL without having direct permissions on the package
20:39:39 <nirik> yeah, that one
20:40:27 <carlwgeorge> the idea is that the autobranching would only be for packages with an epel9 branch, thus making the assumption that if the maintainer was ok with an epel9 branch, they will likely be ok with an epel10 branch
20:40:35 <salimma> given doing a PR is impossible right now if the branch doesn't exist, yeah I think that's worth trying for epel10
20:40:36 <tdawson> I think that came about because some joker ... I think their name started with t, just upped and branched all the packages he needed ... much to the dismay of several package maintainers.
20:40:47 <carlwgeorge> i'll also note how easy it is to retire a branch that ends up not being needed
20:41:18 <Ebeneezer_Smooge> tdawson, it came about because that joker followed one who was named s and caused a lot of problems also
20:41:23 <salimma> sometimes such jokers are how we realize there is a serious lack that needs addresing :)
20:41:25 <carlwgeorge> there is also no harm if a package gets an epel10 branch that ends up being ignored and never built
20:41:51 <salimma> can we say 'epel X+1 is branched if there's a branch for X and it has been built'?
20:41:59 <nirik> that really came about because provenpackagers don't get bugs or notice the ruin they left behind unless they specifically look
20:42:04 <salimma> so e.g. if epel10 is branched but nobody cares about building it, it shouldn't be branched for 11
20:42:45 <tdawson> nirik: Yep, very true.  This time, while I've been getting these packages, I'm now seeing all those bugs.
20:43:00 <nirik> I do think there will be a lot of "oh, but there's an epel branch, why isn't it built". On the other hand theres already a lot of "it was in epel8, why isn't it in epel9"
20:43:08 <carlwgeorge> salimma: i think that would be an edge case that probably doesn't justify the coding time for additional logic
20:43:14 <tdawson> salimma and carlwgeorge - I like that, if it wasn't built, even if it has a branch, it doesn't get the next branch.
20:43:54 <carlwgeorge> nirik: yeah on that all we can do is just have a good faq to point people to and call it good
20:44:00 <carlwgeorge> *good enough
20:44:14 <Eighth_Doctor> .hello ngompa
20:44:15 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:44:19 <tdawson> Hi Eighth_Doctor
20:44:22 <Eighth_Doctor> are we talking about epel branching thingies?
20:44:29 <carlwgeorge> yar
20:44:35 <gotmax[m]> .epel 203
20:44:36 <zodbot> gotmax[m]: Issue #203: Automating adding epel-packagers-sig to packages - epel - Pagure.io - https://pagure.io/epel/issue/203
20:44:43 <Ebeneezer_Smooge> My main problem with this is that it will break various maintainer's workflows
20:44:48 <Ebeneezer_Smooge> somehow
20:45:11 <Ebeneezer_Smooge> but I am mostly having flashbacks
20:45:45 <carlwgeorge> i'm not sure how a branch existing would break someone's workflow, but perhaps i'm not creative enough to see it
20:45:46 <gotmax[m]> I guess it could lead to someone unintentionally pushing to and building from the automatically created branch
20:46:54 <Ebeneezer_Smooge> usually by some script they have which needs massaging
20:46:58 <carlwgeorge> pushing to a branch in git is pretty deliberate.  and even if somehow that happened, i think the build would get garbage collected if it never gets a corresponding bodhi update.
20:47:11 <salimma> it's similar to how as a provenpackager, if I don't check to see if a repo is marked PR only, 'git push' will happily ignore that
20:47:18 <salimma> so I suppose provenpackagers etc might accidentally 'git rebase rawhide' an empty branch
20:47:30 <Ebeneezer_Smooge> but in the end.. I am not hating this
20:47:43 <Ebeneezer_Smooge> and have nothing else to say
20:47:44 <tdawson> carlwgeorge - You were  saying doing the logic for checking if a package was branched and also built would be hard.  As I think about it, it would be easiest to see what packages have been built, and only branch those.
20:47:55 <salimma> yeah, it's better than the current mess of tracking which of your hundred requests need escalating
20:48:12 <nirik> well, you would still need to do that for anything new
20:48:15 <gotmax[m]> Ebeneezer_Smooge: Yeah, I admit that there's drawbacks and edge cases, but I think it could succeed
20:48:15 <salimma> tdawson: oh nice, so just check bodhi and no need to check pagure
20:48:33 <gotmax[m]> There current process is painful
20:48:54 <tdawson> I was thinking koji, but bodhi would do also, yes.
20:50:04 <gotmax[m]> I'd just `repoquery --repo=epel9 --qf=%{source_name}`
20:50:05 <gotmax[m]> * --repo=epel9 --qf=%{source_name}"`
20:50:20 <carlwgeorge> whatever works.  i think checking for an epel9 branch would be fine.  the failure mode is someone says "hey i never did anything with the epel9 branch, and now an epel10 branch got created" is super easy to fix by just retiring both branches, which stops an epel11 branch from coming later.
20:50:39 <tdawson> Actually, bodhi would be better, because if something was built, but never pushed to stable for some reason.
20:50:54 <gotmax[m]> * I'd just `repoquery --repo=epel9 --qf="%{source_name}"`
20:51:18 <rsc> carlwgeorge: does this model also prevent branching if a package slips into RHEL?
20:51:39 <carlwgeorge> that would have to be accounted for as well
20:51:42 <tdawson> carlwgeorge: But ... to check for an epel9 branch, you have to querry all 40,000 Fedora dist-git repo's don't you?  Maybe I just don't know pagure good enough.
20:52:12 <carlwgeorge> perhaps by the time this is needed it won't be in pagure at all
20:52:52 <Ebeneezer_Smooge> hahahahahhaa
20:52:55 <tdawson> Anyway ... it sounds like we're actually coming towards some type of way of implementing this.
20:52:56 <carlwgeorge> but regardless of the forge in question, you'd be looking at one dist-git repo at a time, and then if epel9 exists create an epel10 branch.  seems straightforward to me.
20:52:56 <Ebeneezer_Smooge> hahahahahahhahahaha
20:53:38 <tdawson> carlwgeorge: That sounds like alot more work than one simple koji / bodhi command that spits them all out for you.
20:53:39 <nirik> so are we in any hurry here? This wouldn't be something to do until epel10 right?
20:53:47 <gotmax[m]> Querying the repository is the the most accurate. Branches could be empty or never have been built. But I think what's more important is whether this is a good idea in the first place.
20:54:07 <tdawson> Yep ... We're getting close to the end of our time ... I want to go to Open Floor incase anyone needs anything.
20:54:20 <tdawson> #topic General Issues / Open Floor
20:54:59 <tdawson> carlwgeorge or gotmax[m] Do either of you mind summarizing in the issue for #203?
20:55:08 <nirik> FWIW, I'll not be here next week. :)
20:55:09 <tdawson> Any Open Floor items?
20:55:40 <tdawson> nirik: I hope you are going to be having fun.  Thanks for letting us know.
20:55:49 <Eighth_Doctor> IMO, we should rely on the ELN stuff to figure auto-branching for epel10
20:55:57 <Eighth_Doctor> packages that we want to mark for autobranching should be added to ELN-Extras
20:56:31 <gotmax[m]> I've branched flit-core and tomli for EPEL 8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5e36342ad8
20:56:46 <gotmax[m]> I've been wanting to do this for a while, and I was inspired by the deprecating python-toml change
20:56:57 <gotmax[m]> I'll probably backport this to EPEL 7 also
20:57:02 <carlwgeorge> Eighth_Doctor: a decent enough idea in principle, but it would be far less effective and preventing branch request work as most people ignore eln
20:57:27 <Eighth_Doctor> yes, and that's a mistake
20:57:50 <gotmax[m]> We'd also need to make sure that the package is not part of the RHEL release
20:58:04 <carlwgeorge> could do both checks, if epel9 branch/build exists or if it's set up in eln extras
20:58:12 <tdawson> gotmax[m]:  That part ELN / ELN-extras does automatically.
20:58:28 <Eighth_Doctor> honestly, I want auto-branching in ELN
20:58:29 <carlwgeorge> tdawson: i can add a little summary to that issue of the ideas we talked about
20:58:39 <tdawson> carlwgeorge: Thanks
20:58:42 <Eighth_Doctor> I think it makes no sense to allow autobranching if they're not being continuously evaluated
20:58:47 <gotmax[m]> Thanks!
20:58:55 <Eighth_Doctor> and ELN is our window for continuously evaluating the content split
20:59:47 <tdawson> Yep
21:00:18 <salimma> part of the problem is I think originally we really hesitate to link ELN Extras and EPEL
21:00:24 <tdawson> Looks like our time is up.  Thank you all for the good disucussions, and decisions today.
21:00:31 <tdawson> Talk to ya'll next week, if not sooner.
21:00:31 <Eighth_Doctor> so from my point of view, auto-branching for future EPEL branches should require us to register the package with ELN
21:00:31 <salimma> I'm not sure why
21:00:45 <salimma> but for ELN there's two categories right? the package we actually want, and the packages that get pulled in as dependencies
21:00:58 <Eighth_Doctor> yes
21:01:05 <carlwgeorge> then we will be telling maintainers "well you didn't get an autobranch because you didn't learn this new thing" instead of "we looked at the history and saw you were amenable to your package in epel in the past so we set up the branch in case you need it"
21:01:06 <salimma> maybe if there's a clear report of which packages are dependencies, we can have people sign up for them explicitly
21:01:41 <Eighth_Doctor> we need it because otherwise RHEL can't know what we need to have shipped to build it
21:01:54 <salimma> but yeah... any ELN based solution will have to be amenable to 'the people who want to work on the EPEL branches overlap only a bit with the Fedora maintainers'
21:02:05 <Eighth_Doctor> it's a mess right now getting unshipped stuff analyzed and requested
21:02:05 <salimma> that's basically our pain point. if the two set overlaps fine, we don't have to figure out all this
21:02:30 <Eighth_Doctor> using the ELN automation means that we have _data_ that tdawson can use to make this easier _every future round_
21:03:22 <tdawson> I didn't end the meeting because I wanted to keep this in the meeting logs ... but even though I like and use ELN, I need to end the meeting.
21:03:29 <Eighth_Doctor> it took over a month for me to get just the stuff I needed at work to build because I had to do that analysis manually
21:03:29 <tdawson> #endmeeting