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