20:00:12 <tdawson> #startmeeting EPEL (2022-09-07) 20:00:12 <zodbot> Meeting started Wed Sep 7 20:00:12 2022 UTC. 20:00:12 <zodbot> This meeting is logged and archived in a public location. 20:00:12 <zodbot> The chair is tdawson. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 20:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:12 <zodbot> The meeting name has been set to 'epel_(2022-09-07)' 20:00:14 <tdawson> #meetingname epel 20:00:14 <zodbot> The meeting name has been set to 'epel' 20:00:15 <tdawson> #chair nirik tdawson pgreco carlwgeorge salimma dcavalca dherrera gotmax[m] 20:00:15 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax[m] nirik pgreco salimma tdawson 20:00:17 <tdawson> #topic aloha 20:00:31 <rcallicotte> .hi 20:00:32 <zodbot> rcallicotte: rcallicotte 'Robby Callicotte' <rcallicotte@mailbox.org> 20:00:34 <nirik> morning 20:00:34 <salimma> .hi 20:00:35 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name> 20:00:41 <gotmax> .hello gotmax23 20:00:42 <gotmax[m]> #chair gotmax 20:00:42 <zodbot> Current chairs: carlwgeorge dcavalca dherrera gotmax gotmax[m] nirik pgreco salimma tdawson 20:00:42 <zodbot> gotmax: gotmax23 'Maxwell G' <gotmax@e.email> 20:00:43 <carlwgeorge> .hi 20:00:45 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com> 20:00:57 <tdawson> Hi rcallicotte and salimma and gotmax[m] and carlwgeorge 20:01:01 <tdawson> morning nirik 20:01:04 <gotmax> Hi yall 20:01:20 * rcallicotte waves to everybody 20:01:27 * gotmax waves back 20:01:38 <dherrera> .hi 20:01:39 <zodbot> dherrera: dherrera 'Diego Herrera' <dherrera@redhat.com> 20:01:48 <tdawson> Hi dherrera 20:02:16 <pgreco> .hi 20:02:17 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar> 20:02:35 <tdawson> Hi pgreco 20:02:41 * pgreco is in a zoom meeting that overlaps, once again, sad.... 20:03:12 <tdawson> We don't get to see you smily face :( ... only your smily faces. :) 20:03:52 <pgreco> yeah, but we'll get there ;) 20:03:58 <smooge> here 20:04:02 * gotmax counts 9 people 20:04:13 <tdawson> Hi smooge 20:04:33 <gotmax> Which is pretty good if you ask me 20:04:39 <smooge> i am here to defend my proposal about dropping modules from all you people who are against it 20:04:45 <rcallicotte> haha 20:05:10 <tdawson> #topic EPEL Issues https://pagure.io/epel/issues 20:05:11 <tdawson> https://pagure.io/epel/issues?tags=meeting&status=Open 20:05:15 <carlwgeorge> smooge: you have my sword 20:05:25 <tdawson> And with that .. let's let smooge defend his proposal 20:05:29 <tdawson> .epel 198 20:05:30 <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:05:45 <nirik> noooooooooooooooooo... oh, yes. 20:05:50 <rcallicotte> fight fight fight! 20:06:10 <tdawson> I haven't heard a single voice against it ... but ... this should still be good. 20:06:17 <Eighth_Doctor> .hello ngompa 20:06:18 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com> 20:06:18 <pgreco> smooge: I'm really sad to have to agree 20:06:18 <nirik> how many modules do we even have these days? 20:06:22 <tdawson> Hi Eighth_Doctor 20:06:25 <Eighth_Doctor> meh, burn it 20:06:30 <carlwgeorge> i love the idea. my only critique is to separate item 3 (modular release subpackage) to be something we do regardless 20:06:35 <gotmax> I don't think there was significant disagreement. The only question is what to do with the current ones. 20:07:53 <salimma> how many of the current ones... are actually usable? 20:07:55 <nirik> a detailed retirement plan would be nice... 20:08:19 <gotmax> [gotmax@toolbox] ~ >>> sudo dnf module list --repo=epel-modular Last metadata expiration check: 16:39:03 ago on Tue 06 Sep 2022 10:28:09 PM CDT. @modulefailsafe Name Stream Profiles Summary perl 5.26 [e] common, minimal Practical Extraction and Report Language perl-IO-Socket-SSL 2.066 [e] common 20:08:19 <smooge> how much more detailed is needed 20:08:25 <gotmax> Oops 20:08:38 <gotmax> I meant to put the pastebin link, not that 20:08:43 <gotmax> https://paste.sr.ht/~gotmax23/2e2f471c333bd4b5bbe5fc190e2f5f68789d1f23 20:08:48 <gotmax> Sorry everyone 20:08:58 <rcallicotte> no worries 20:09:08 <carlwgeorge> none of the nextcloud ones install https://pagure.io/releng/issue/10913 20:09:10 <gotmax> Nextcloud is unusable 20:09:14 <gotmax> Yeah 20:09:30 <gotmax> I don't know about the others 20:10:18 <nirik> might be nice to mail the maintainers, but not sure how much of a pain that would be 20:10:46 <gotmax> I agree 20:11:03 <smooge> I have heard people complain about ghc and cobbler also but I have not tested myself 20:11:06 <gotmax> I think we can get the data from the src.fp.o repo ACLs 20:11:25 <gotmax> I didn't try to install it, but dnf was at least able to resolve the ghc dependencies 20:12:31 <smooge> the problem the person had may have also been transient. I just decided to skip 20:12:34 <nirik> ghc is in the normal rpm repos now, isn't it? 20:12:49 <gotmax> It's both 20:12:50 <tdawson> carlwgeorge: You emails the module maintainers for the epel9 module investigation. How much of a pain was it? 20:13:23 <carlwgeorge> not too bad, i have the list of email somewhere. it's like a dozen or so people. most didn't reply to my epel9 questions. 20:13:31 <gotmax> FESCo forbade default modules or packages that are only available in modules 20:13:56 * nirik nods 20:14:21 <tdawson> Do we want to contact the module maintainers and get their input? Or are we ok just passing this and moving on to doing the work? 20:14:28 <smooge> i will add that to my steps 20:14:36 <gotmax> I think we should get their feedback and table this 20:15:28 <gotmax> It would look bad to vote without their feedback and then dictate that we're removing all of their modules from EPEL 20:15:31 <carlwgeorge> based on epel9 modular feedback, what you'll get from the epel8 module maintainers is 1) no answer, 2) i'd prefer epelX-modular to exist but will make due without it, 3) you have to do it but i'm not gonna help. 20:15:58 <nirik> gotmax: +1 20:16:18 <carlwgeorge> i'm not actually sure we'll gain any insight from asking them again about epel8-modular that we don't already know from their answers about epel9-modular. perhaps a bit more outrage from taking something away versus not starting something. 20:16:55 <gotmax> Meh, I guess 20:17:05 <gotmax> I'm a bit conflicted about this 20:17:07 <smooge> who needs to email the module maintainers? Me? someone else 20:17:10 <gotmax> whoe issue 20:17:12 <carlwgeorge> but i'm not entirely sure we should block this initiative due to single digit maintainers saying they want it to stick around 20:17:45 <salimma> even if the response is negative, at least we should ask I guess. but is there any threshold beyond which we would decide to maintain modules? 20:17:45 <gotmax> *whole 20:17:49 <nirik> if rhel wasn't so long lived, I would just say to leave it and let it go away with 8, but I suppose it's worth the work to retire 20:17:59 <salimma> e.g. if 2/3 of asked maintainers actually reply and say "please keep modules" 20:18:13 <gotmax> How much work is it right now for releng to maintain epel8-modular? 20:18:14 <salimma> (I bet the rate will be much lower, anyway - aren't some modules accidentally branched?) 20:18:20 <gotmax> Besides what's already done for Fedora 20:18:33 <gotmax> salimma: Yes. See nextcloud 20:18:49 <smooge> gotmax, the issue is that 'nextcloud' is going to be more often as time goes on 20:19:32 <carlwgeorge> what about a compromise, block adding any new modules to epel8-modular, but leave the existing ones to age out 20:19:34 <salimma> smooge: yup. but that means we can ask people and most would probably not object to killing it? 20:19:37 <nirik> well, I don't think it's much over fedora's needs really... 20:19:52 <gotmax> carlwgeorge: I'm amendable to that 20:19:58 <salimma> I think we can at least start by blocking new modules, yeah. and we can vote on that now 20:20:00 <smooge> and modularity is in a sort of circular loop. people don't want it in Fedora but when asked to remove it, there is the 'well EPEL needs it' and then when EPEL says it doesn't 'well Fedora could keep it going' 20:20:09 <Eighth_Doctor> let's go with that 20:20:12 <nirik> carlwgeorge: not sure... that kind of reads like we are favoring these early adopters... but I guess. 20:20:40 <gotmax> Yeah, I'm kind of torn about actively getting rid of it 20:20:47 <smooge> I am not 20:20:48 <carlwgeorge> kinda but we're 3 years into rhel8 lifecycle, not really early anymore 20:21:04 <gotmax> We could put some strong warning in the docs, but you all know how well people read docs... 20:21:35 <smooge> It is a pain in the ass to make work, it is a pain in the ass to keep working with it breaking all the time and needing to keep software no one is maintaining, and about 3-4 more hours of rants from me 20:21:40 <carlwgeorge> to be clear i still support smooge's "kill it with fire", but if there is enough push back i'm also ok with hard deprecation, no new modules or streams, but keep existing ones 20:21:44 * nirik shrugs. Yeah, lets just drop it... but thats more work in the short term for less work in the long term. ;) 20:22:21 <gotmax> I think we should start with deprecation/blocking new modules 20:22:30 <tdawson> I see three things problems that EPEL has that Fedora doesn't, with modules. 1 - grobisplitter getting messed up, usually with epel8-next, but occasionally elsewhere. 2 - Our modules sometimes conflict with RHEL modules. 3 - The occasional Fedora modules that doesn't test anyting on epel, just builds and leaves it. 20:22:33 <nirik> to be clear, I am not pushing back, I was just saying we might ask current maintainers, but you all are right, we probibly know all that they will say 20:22:38 <smooge> motion: carlwgeorge will send me the list of people he emailed. I will email them about the ticket and ask them to put their talk in it with a deadline of Oct 15th. After that we move 20:22:40 <gotmax> How would we prevent new EPEL modules technically? 20:22:51 <gotmax> We can't even prevent Nextcloud from being repeatedly added right now 20:23:01 <tdawson> Any by the time I typed that, the conversation moved on. :) 20:23:29 <nirik> we can tell releng to not process any new epel modular requests? 20:23:34 <carlwgeorge> i'm sure there is a way to do it with tags in koji 20:23:43 <gotmax> tdawson: grobisplitter is kind of separate. That's not related to epel-modular. I'd add not being able to depend on RHEL modules to your list, though. 20:24:02 <gotmax> nirik: I'd just modify fedscm-admin 20:24:09 <tdawson> gotmax: Oh ya .. I forgot about that. 20:24:29 <carlwgeorge> smooge: seconding your motion, i'll find the list 20:24:32 <nirik> gotmax: right. 20:24:33 <smooge> thanks 20:25:04 <tdawson> Sounds good. Thanks smooge. 20:25:14 <smooge> any opposed to my motion? 20:25:16 <gotmax> The PHP situation is a bit sad. They could have been part of EPEL, but remi is not able to maintain them there. 20:25:17 <nirik> (or soon, the toddler) 20:25:29 * gotmax is very excited about that 20:25:34 <gotmax> (the toddler) 20:25:46 <tdawson> #info Vote on epel8 moduels tabled until October 15th while we get feedback from module maintainers and others. 20:26:02 <gotmax> #idea Formally deprecate epel8-modular and prevent new modules from being added 20:26:12 <gotmax> Do we want to vote on that? 20:26:21 <gotmax> Or wait for feedback 20:26:28 <smooge> I am good with that 20:26:41 <gotmax> with what? voting now? 20:26:47 <smooge> I am good with voting on your proposal 20:26:52 <gotmax> Ack 20:26:55 <smooge> second 20:27:24 <gotmax> Meh, I guess I'll vote +1 on that 20:27:29 <smooge> if releng (aka nirik) believes it is possible 20:27:39 <salimma> are we voting already? +1 on preventing new modules 20:27:45 <tdawson> wait ... so is this tabled or are we voting on gotmax's alternative? 20:27:57 <smooge> I think we tabled and moved 20:28:12 <smooge> lets slow down and let the chair take over the meetng again 20:28:49 <tdawson> OK, well, we had two other issues. if we're done with that. 20:29:22 <tdawson> I don't think we'll get through them both, so I'm just randomly picking the next one. 20:29:25 <tdawson> .epel 199 20:29:31 <salimma> yay! 20:30:03 <tdawson> https://pagure.io/epel/issue/199 - ensure EPEL bugzilla assignees point to valid packagers 20:30:11 <tdawson> I'm not sure where zotbot went 20:30:13 <gotmax> davide is in London, but I guess we can still discuss this 20:30:36 <gotmax> .fire zodbot 20:30:36 <zodbot> adamw fires zodbot 20:30:43 <gotmax> Hmm 20:30:46 <salimma> yep, he asked me to keep him updated 20:30:52 <zodbot> tdawson: Issue #199: ensure EPEL bugzilla assignees point to valid packagers - epel - Pagure.io - https://pagure.io/epel/issue/199 20:30:59 <tdawson> Ya! 20:31:03 <rcallicotte> :) 20:31:35 <gotmax> I guess the problem with this whole thing is that we don't know who's really responsible for maintaining these packages 20:31:44 <tdawson> I'm not against cleaning the bz assignment up ... it's a little fuzzy and solid details though. 20:31:49 <nirik> we don't know in fedora either. ;) 20:32:05 <salimma> both cleaning up, and also - how do we prevent it from drifting again 20:32:23 <tdawson> Ha ... I was going to say Fedora needs this too ... so I'm glad someone else did 20:32:55 <nirik> it's a pretty multidimensional problem tho. 20:32:56 <gotmax> Maybe we should start by contacting the maintainers of the packages in https://paste.sr.ht/~gotmax23/1d73c4d9a060c0801f04f0860fc7bda8f790e009? 20:33:04 <nirik> because there's also watchers. They don't need to be packagers 20:33:45 <gotmax> nirik: Yeah, that's true. The bit us when dealing with the new SIG policy. 20:33:47 <nirik> if we narrow the scope here to: epel primary bugzilla assignee, I think we can make a toddler or the like to check/enforce that 20:34:07 <gotmax> I like that idea 20:35:16 <nirik> I suspect lots of those packages got in that state the same way tdawson said he did for a package... ie, orphaned in fedora and set everything orphaned, someone took it in fedora, but left the epel branch going to orphan. 20:35:37 <tdawson> Ha .... So I recognize 5 of the rubygems as mine. 20:35:38 <gotmax> Yeah. The problem is that there's no way for us to know for sure 20:35:56 <gotmax> And the not being able to reset the assignee issue is a pain 20:36:26 <salimma> can we special case claiming an EPEL branch if the assignee is orphan? 20:36:40 <tdawson> Actually ... all the rubygems, that also say epel9 are all mine ... as well as several of the epel7's ... *sigh* 20:36:53 <nirik> and just think...someday if we move from pagure we get to do this all over again! exciting. 20:36:53 <salimma> e.g. file a ticket, toddler or something comes in and check, if the assignee is orphan it grants it 20:37:29 <gotmax> Well, releng is supposed to reset the assignee when branches are created through the stalled request process 20:37:43 <gotmax> I did submit https://pagure.io/pagure-dist-git/pull-request/154# 20:38:49 <salimma> gotmax: related: it's kind of weird that admins (not main admin) can't modify a package's ACL 20:38:54 <nirik> on fedora orphaned packages there's a 'take this' button... perhaps it could be expanded to allow someone to 'take this' and get collaborator for epel* and assignee in bugzilla set... but I have no idea how much coding that would be 20:39:20 * salimma not sure what exactly is the difference between admin and commit in that case 20:39:33 <gotmax> Even if it could get developed, nobody is reviewing pagure-dist-git PRs 20:39:39 <nirik> they can add/remove commiters? 20:39:40 <salimma> nirik: that would be nice 20:40:04 * nirik is planning to try and merge pagure-dist-git stuff and do a release here... if I can get some time with no fires. 20:40:10 <salimma> nirik: I just tried adding epel-packagers-sig to python-matplotlib-inline - which has python-sig as an admin 20:40:15 <salimma> it failed 20:40:29 <gotmax> salimma: Any admin should be able to add people to the package 20:40:32 <salimma> I wonder if it's specific to if you get admin access via group rather than individually though. I can file a bug 20:40:41 <nirik> salimma: did you use @ (it's a group) 20:40:52 <gotmax> It's just the pagure-dist-git stuff (overrides and monitoring) that doesn't work correctly 20:40:59 <salimma> nirik: I tried adding in the 'add group' section 20:41:03 <salimma> but let me double check 20:42:09 <gotmax> Weird. I was able to do it for one of the go-sig packages. 20:42:16 <salimma> oh the UI is horrible 20:42:18 <gotmax> Anyways... 20:42:52 <salimma> yeah, we can continue this later in #epel - moving on 20:42:55 <nirik> so, not sure where we are here really. I think we can do some checks... but we need to be specific. 20:43:04 <tdawson> So ... what is the outcome of this. It seems we all agree this is a problem. Did we have a set solution? Or should we discuss this on the issue another week? 20:43:30 <tdawson> Ha! So, we're ok moving on. 20:43:34 <gotmax> This orphaning/retiring/ACLs/assignees issue is starting to feel like a cyclical discussion 20:43:45 <tdawson> Yep. 20:43:55 <nirik> yeah, more clear docs would help I think... 20:44:07 <gotmax> The nuances of the the way pagure handles permissions are confusing 20:44:09 <nirik> then we could at least see the parts we want to change without having to look at how it works 20:44:17 <gotmax> And we spend a lot of time discussing that 20:44:35 <tdawson> I'm going to move on to the normal EPEL topics to make sure nothing came up this week. 20:44:37 <gotmax> Sorry, if we're moving on, I don't wan tto intrude 20:44:38 * salimma definitely found a bug: if you're admin via a group, you can add users (including yourself) as admin but you can't add another group to the ACL. once you add yourself you can 20:44:59 <tdawson> #topic EPEL-7 20:45:00 <tdawson> RHEL 7 will go EOL on 2024-06-30 20:45:18 <tdawson> Anything for epel7? 20:46:04 <tdawson> #topic EPEL-8 20:46:06 <nirik> salimma: cute. :) 20:46:06 <tdawson> CentOS Stream 8 goes EOL in 2024-05-31 20:47:06 <tdawson> Anything for epel8? 20:47:34 <smooge> not from me. going to throw a hand grenade after this meeting 20:47:37 <tdawson> #topic EPEL-9 20:47:38 <tdawson> CentOS Stream 9 goes EOL in 2027-05-31 20:47:43 * gotmax has something 20:48:06 <gotmax> I feel like I've talked enough, so someone else can feel free to go first 20:48:18 <tdawson> gotmax: Go for it. 20:48:27 <gotmax> #link https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/52 20:48:32 <gotmax> #link https://src.fedoraproject.org/rpms/go-rpm-macros-epel 20:49:07 <gotmax> I've created a new go-rpm-macros-epel package. I'd like to get the go-srpm-macros subpackage added to the buildroot. 20:49:27 <gotmax> That's for EPEL 9, but I plan to create something similar for 8 20:49:27 <nirik> hum. 20:49:36 <Eighth_Doctor> can we do this? 20:49:46 <nirik> I can't recall if this is the right way to do this or not. ;) 20:49:55 <gotmax> I've purposely made it so it doesn't conflict 20:50:07 <nirik> it could also be done in koji 20:50:14 <gotmax> I'd depends on go-rpm-macros and overrides certain things 20:50:18 <nirik> and comps 20:50:51 <gotmax> We usually just add these things to epel-rpm-macros for EPEL or redhat-rpm-config for Fedora 20:51:14 <gotmax> The goal here is to make it as easy as possible for Fedora Go packages to be packaged for EPEL 20:51:28 <gotmax> I'm hoping that this will improve the Go ecosystem 20:51:46 <nirik> yeah, as long as it doesn't pull in a ton of things it should be ok. 20:51:53 <gotmax> I've also added macros to both Fedora and EPEL that make it easier to vendor when that's justifiable 20:51:59 <gotmax> *ecosystem in EPEL 20:52:15 <gotmax> The -srpm-macros subpackage does not pull in anything extra 20:52:34 <salimma> I'll have to take a look at the implementation - curious how this works :) 20:52:45 <salimma> e.g. what if the same macro is defined in go-rpm-macros and go-rpm-macros-epel 20:52:48 <tdawson> gotmax: I'm assuming you've tested this. 20:53:08 <gotmax> I have 20:53:16 <tdawson> Cool 20:53:35 <gotmax> salimma: The macros from my package have higher priority due to their file naming 20:53:49 <salimma> nice 20:53:50 <tdawson> I noticed that. 20:54:00 <gotmax> I wrote a pretty detailed description in the README 20:54:28 <gotmax> And I'm happy to answer questions :) 20:55:11 <carlwgeorge> at this point you may be the most knowledgeable person on how go macros work in fedora/epel/rhel 20:55:24 <tdawson> I know that you tried getting Red Hat to update their macros without success. To me, this looks like the only real solution. So I'm good with it. 20:55:48 <gotmax> Yeah :). The original maintainer is long gone and the RHEL maintainers are well... 20:55:52 <smooge> i would say its about all we can hope for 20:55:59 <carlwgeorge> ship it 20:56:12 <gotmax> Who wants to do the honors of merging the PR? 20:56:22 <smooge> thats carl's job 20:56:29 <smooge> he gets paid the big bucks to have that target 20:56:35 <smooge> sorry honour 20:56:55 <carlwgeorge> if there's no objections, sure 20:57:10 <carlwgeorge> speak now or forever hold the pieces 20:57:12 <tdawson> No objections from me 20:57:32 <salimma> +1 20:57:40 <pgreco> go for it 20:58:11 <tdawson> Since we only have a couple more minutes, I'm going to move the topic to #open Floor 20:58:21 <tdawson> #topic General Issues / Open Floor 20:58:26 <smooge> email to maintainers has been sent 20:58:31 <tdawson> Ya! 20:58:34 <gotmax> Thanks smooge! 20:58:46 <Eighth_Doctor> lol 20:58:47 <Eighth_Doctor> yeah carl 20:58:51 <salimma> smooge++ 20:58:51 <zodbot> salimma: Karma for smooge changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 20:58:51 <Eighth_Doctor> ahh the joys of crap internet 20:58:55 <Eighth_Doctor> smooge++ 20:58:55 <zodbot> Eighth_Doctor: Karma for smooge changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 20:58:59 <pgreco> see ya! 20:59:01 <tdawson> Anything else before we close for the week? 20:59:05 <carlwgeorge> suggestion, lets drop the epel7/8/9 sections from the agenda and just defer anything from those to open floor 20:59:08 <tdawson> By pgreco 20:59:26 <salimma> I'm in Dublin time zone (virtually attending a conference next week) so I might skip 20:59:28 <carlwgeorge> they always take up time and rarely have specific items that couldn't be covered in open floor 20:59:30 <tdawson> carlwgeorge: Ya ... or maybe lump them all together. 20:59:36 <smooge> I agree on this 20:59:47 <gotmax> Or maybe we could ask whether anyone has anything for each at the beginning? 20:59:48 <smooge> when I started that it was helpful to break out people's thoughts 20:59:57 <gotmax> So then we don't waste three minutes on EPEL 7 21:00:02 <tdawson> :) 21:00:04 <gotmax> But still have the organization 21:00:04 <salimma> yeah, epel7 and 8 in particular is often empty anyway 21:00:05 <salimma> or the issue is the same (e.g. "I'm branching X and Y came up" 21:00:29 <salimma> I'm +1 on keeping the EOL date reminders though :) - just lump them up together 21:00:46 <tdawson> Sounds good. I'll adjust the agenda. 21:00:49 <smooge> I would say spout the end of life, go through open tickets, then open floor 21:01:25 <carlwgeorge> agreed 21:01:26 <tdawson> I like that. 21:01:27 <smooge> then before I can derail things, close the meeting 21:01:33 <tdawson> *laughs* 21:01:40 <smooge> so i was thinking... 21:01:53 <tdawson> Thank you all for comming this week :) 21:01:55 <gotmax> smooge v. gotmax: Derailing the meeting 21:02:08 <tdawson> I do mean that. And thank you all for your for for EPEL and it's community. 21:02:20 <tdawson> Talk to you next week. 21:02:28 <tdawson> #endmeeting