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