22:01:32 <tdawson> #startmeeting EPEL (2021-01-29) 22:01:32 <zodbot> Meeting started Fri Jan 29 22:01:32 2021 UTC. 22:01:32 <zodbot> This meeting is logged and archived in a public location. 22:01:32 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:01:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 22:01:32 <zodbot> The meeting name has been set to 'epel_(2021-01-29)' 22:01:33 <tdawson> #meetingname epel 22:01:33 <zodbot> The meeting name has been set to 'epel' 22:01:35 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel_slm 22:01:35 <zodbot> Current chairs: bstinson carlwgeorge michel_slm nirik pgreco tdawson 22:01:36 <tdawson> #topic aloha 22:01:40 <smooge> Hello 22:01:43 <pgreco> hello! 22:01:47 <tdawson> Hi smooge 22:01:49 <tdawson> Hi pgreco 22:01:50 <michel_slm> hello! 22:01:54 <tdawson> Hi michel_slm 22:01:55 <michel_slm> .hello salimma 22:01:56 <zodbot> michel_slm: salimma 'Michel Alexandre Salim' <michel@michel-slm.name> 22:02:04 <smooge> i have now made 2 meetings this year. 22:02:05 <michel_slm> glad to finally be back. hi tdawson, smooge, pgreco 22:02:10 <tdawson> Hi zodbot 22:02:22 <tdawson> I was hoping ... :) 22:02:25 <michel_slm> pgreco: scuttlebutt says you're into Guix, if so we should chat :D 22:02:37 * nirik is here even tho he's on PTO today 22:02:46 * King_InuYasha waves 22:02:47 <tdawson> michel_slm: It's good to see you again. 22:02:49 <King_InuYasha> .hello ngompa 22:02:50 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com> 22:02:52 <pgreco> michel_slm: yeah, I went to their conference in belgium last year 22:02:56 <tdawson> Hi nirik 22:03:03 <tdawson> Hi King_InuYasha 22:03:09 * King_InuYasha recently finished filing a ticket with zoom to fix their wayland screensharing support 22:03:31 <tdawson> Oohh ... that will be nice. 22:03:43 <pgreco> King_InuYasha: that would be awesome 22:03:57 <pgreco> or not, I have a great excuse not to share my screen 22:04:04 <smooge> me too 22:04:11 <michel_slm> pgreco: ah, yeah, Davide said he saw you there last year. a bit OOT so let's talk about it later 22:04:12 <smooge> you are making me work 22:04:21 <carlwgeorge> howdy yall 22:04:26 * michel_slm trying to clean up the sudo mess at work 22:04:28 <smooge> howdy carlwgeorge 22:04:31 <tdawson> Hi carlwgeorge 22:04:41 <King_InuYasha> oh god 22:04:44 <King_InuYasha> don't remind me about sudo 22:04:48 <tdawson> nirik: Thanks for being here during PTO time. 22:05:21 <pgreco> sudo make zoom support wayland :D 22:05:34 <michel_slm> pgreco: does the bug mean you can do that on King_InuYasha's machines? :P 22:05:34 <tdawson> *laughs* 22:05:38 <smooge> ok I think the gang is all here 22:05:41 <tdawson> #topic Old Business 22:05:43 <tdawson> EPEL-Packaging-SIG 22:05:49 <nirik> hey, who are you calling old? :) 22:06:02 <michel_slm> what's a pain is not all our users are on Fedora so I have to conditionally compute which version is fixed based on distro and version 22:06:38 <King_InuYasha> ugh 22:06:40 <michel_slm> not much to report yet, but... speaking of C9S that will be branched soon. I really want to get the issue of "allow collaborators to request branches" fixed 22:06:43 <tdawson> michel_slm: any new news on the Packaging-SIG? 22:06:54 <King_InuYasha> michel_slm: is there a ticket for that yet? 22:07:00 <michel_slm> because we want to encourage people to grant collaborator access to the SIG and only allowlist epel* branches 22:07:20 <michel_slm> it's on pingou's todo but not sure how much time he has for it. anyone has any idea what's involved or can point me to the code? 22:07:26 <michel_slm> (we should just do this ourselves) 22:07:28 <michel_slm> yes there is. one sec 22:08:08 <michel_slm> #info https://pagure.io/epel/issue/106 is the ticket for allowing collaborators to request branches matching their allowlist - it links to the infra ticket 22:08:42 <nirik> theres also a bodhi pr to allow them to handle updates 22:08:48 <michel_slm> apart from that, all seems good except I'm noticing that people really request for branches in weird ways and our query doesn't catch them all :p 22:08:51 <King_InuYasha> michel_slm: this stuff would probably be codified in pagure-dist-git or the fedscm-admin thingy 22:09:04 <michel_slm> nirik: ah, do you have a link for that? 22:09:20 <michel_slm> King_InuYasha: links? I can take a look 22:09:45 * michel_slm fesses up to being one of those who sat on a branch request -- or worse, branched one of his packages and then forgetting to build *cough luarocks cough for months 22:10:18 <tdawson> I'm wondering if maybe we should have a template for a branch request. Something like in the old days, but maybe not as wordy. 22:10:44 <nirik> not off hand, but I can look for it 22:11:59 <tdawson> I know not everyone will follow it, but at least give our searchs a fighting chance. 22:12:17 <michel_slm> tdawson: yeah. something like the one for review requests. It won't fix everything but it's better than nothing 22:12:26 <michel_slm> can anyone write a template? if so I can do that 22:13:03 <smooge> the old template was mainly something in wiki for people to cut and paste 22:13:11 <King_InuYasha> michel_slm: pagure-dist-git: https://pagure.io/pagure-dist-git 22:13:11 <pgreco> and having a template is a good way to tell people why their requests were ignored 22:13:18 <King_InuYasha> michel_slm: not sure where fedscm-admin is, nirik may know 22:13:21 <nirik> https://github.com/fedora-infra/bodhi/pull/4181 22:13:24 <tdawson> michel_slm: If you've got time, that would be great. If you don't, give me a ping. I think if I start with the review request template, I might be able to get one done. 22:13:31 <nirik> pagure.io/fedscm-admin 22:14:06 <nirik> fedpkg request-branch just fills out a template... it files an issue which fedscm-admin processes. 22:14:22 <michel_slm> tdawson: ah, please do that then, and I can focus on seeing what needs to be done for the collaborator 22:14:45 <tdawson> michel_slm: OK, I've put it on my list. 22:15:08 <michel_slm> nirik: ah, I need to look at fedscm-admin anyway, I've seen two cases recently where people get confused if their ACLs have not refreshed yet 22:15:13 <michel_slm> tdawson++ 22:15:13 <zodbot> michel_slm: Karma for tdawson changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 22:15:31 <michel_slm> it's funny that zodbot doesn't understand CentOS release cycles :D 22:15:54 <nirik> perhaps centbot does? :) 22:16:50 <smooge> well it is hard to make it understand when they keep getting changed. what too soon? 22:16:56 <tdawson> michel_slm: With those links, do you have everything you need? 22:17:01 * michel_slm has just been informed there's now a gcrypt vulnerability https://www.helpnetsecurity.com/2021/01/29/libgcrypt-vulnerability/ 22:17:02 <tdawson> *laughs* 22:17:06 <michel_slm> tdawson: I think so, yeah 22:17:26 <michel_slm> <smooge "well it is hard to make it under"> ask me again at 5 when I plan to drink :P 22:17:30 <tdawson> michel_slm: Thank you so much for your efforts on the SIG ... and now too ... epel-next 22:17:37 <michel_slm> (last comment for smooge, for those not on Matrix) 22:17:57 <tdawson> carlwgeorge: How are things going on the epel8-next? 22:18:31 <carlwgeorge> working on fedpkg changes to support the workflow 22:18:51 <carlwgeorge> i did want to touch on the fedscm-admin changes that were previously discussed 22:18:53 <tdawson> I'm sure the mass rebuild isn't helping that. 22:19:17 <carlwgeorge> the plan was to enforce a requirement that you can't request an epel8-next branch unless you already had an epel8 branch 22:19:58 <tdawson> That makes sense. Looking forward, do you think that logic also works for epel9? 22:20:07 <pgreco> carlwgeorge: that sounds reasonable 22:20:19 <carlwgeorge> well here's the thing, i'm starting to think that is a mistake 22:20:24 <michel_slm> yeah... epel9-next will exist before epel9, right? 22:20:28 <pgreco> but how do we handle that in 9? 22:20:45 <michel_slm> maybe "if epelX exist, a package must exist there to exist in epelX-next"? 22:20:57 <smooge> a package or a branch for that package? 22:21:21 <carlwgeorge> let's say that foo is in cs8, but not rhel8 yet. you want to do an epel8-next branch request for bar, which build requires foo. 22:21:57 <carlwgeorge> yes ideally the epel8 branch would be needed later, but there's no reason to force require it up to 6 months early 22:22:13 <nirik> that would be confusing and mess with people I fear. 22:22:18 <smooge> yep. it is sort of like saying a package can't be in rawhide unless it is already in FCXX 22:23:00 <michel_slm> once -next takes off, an inverted version of the rule might make sense 22:23:03 * nirik is ok with dropping the requirement 22:23:04 <pgreco> ok, but we need to enforce somehow that if package XX is available for stream, it needs to be available for RHEL (when such RHEL exists) 22:23:10 <michel_slm> you can't get an epelX branch until you already test it in X-next 22:23:30 <carlwgeorge> the original thought process was that even with the delay it's better to require it, but i don't see the difference in requiring it and not requiring it, when a maintainer could easily request the epel8 branch and then forget about it 6 months later 22:23:32 <michel_slm> but we can't have that until -next exists and I guess we mass-branch packages? 22:24:09 <carlwgeorge> and as michel_slm pointed out, it will be up to a year gap with cs9 22:24:09 <pgreco> how about branching off automatically epel9 from epel9-next when RHEL becomes GA, or beta? 22:24:24 <King_InuYasha> carlwgeorge: wouldn't it make sense to have epel9-pre before GA, then switch to epel9-next post-GA? 22:24:40 <pgreco> it touches on what tdawson answered today on the mailing list 22:24:54 <pgreco> what will be the state of c9s on rhel9GA 22:25:46 <smooge> the issue is that c9s may be ahead of GA before GA is released. 22:25:53 <tdawson> Well, the packages in epel9-next will still work with centos9 stream on RHEL9 GA. The problem is that they may, or may not, work on RHEL9 GA. 22:25:56 <michel_slm> epel9-next pre-GA will pretty much be epel9-pre, no? 22:26:03 <nirik> you may put something in epel9-next but decide to not persue it for epel9 in the end? 22:26:03 <michel_slm> not sure it's worth creating yet another branch 22:26:06 <carlwgeorge> King_InuYasha: that's just more work than establishing epel9-next using a cs9 buildroot and leaving it that way 22:26:23 <carlwgeorge> pgreco: ideally cs9 will be 9.1 content when 9.0 lands 22:26:33 <michel_slm> does rhel9 plan to have a not-updated beta before GA? 22:26:48 <carlwgeorge> what smooge said 22:26:49 <michel_slm> or would c9s be pretty much that rolling beta 22:26:53 <smooge> plan 2.. put epelX-next in CBS as a continual rebuild/update against stream and have it flag in CA when things break? 22:27:04 <smooge> CI 22:27:27 <smooge> that might be plan 6 or 7 22:28:04 <michel_slm> carlwgeorge: oof, now my brain hurts. I was expecting c9s to move ahead to 9.1 only after 9.0 GA 22:28:12 <tdawson> smooge: Couldn't we put the packages in koschei, on a centos9 stream - https://koschei.fedoraproject.org/ 22:28:22 <King_InuYasha> this is going to be hard :/ 22:28:36 <carlwgeorge> so far cs8 has jumped to the next point release about a month prior to ga of the point release it was on 22:28:39 <pgreco> michel_slm: that's why I suggested beta, if such thing will exist 22:28:49 <King_InuYasha> perhaps we should just do epel9 and then keep doing it until GA, then switch things 22:29:09 <smooge> no I would recommend NOT doing htat 22:29:14 <pgreco> King_InuYasha: epel9-next is born on RHEL9GA? 22:29:19 <King_InuYasha> pgreco: yes 22:29:31 <pgreco> mmmm 22:29:33 <carlwgeorge> or, do epel9-next how it should be, and then do epel9 at 9ga time, and only then do the requirement of epel9-next on epel9 in the repo file packages 22:29:54 <tdawson> carlwgeorge: That's what I was thinking 22:29:58 <pgreco> tdawson: do you know if there will be a RHEL9 beta? 22:30:01 <smooge> packages are going to come in and out of the pre-GA. There were huge differences between 8beta and 8 final (and I was trying 8 snapshots on my home system and those changed a lot) 22:30:10 <carlwgeorge> i feel like trying to move the buildroots around is a recipe for disaster 22:30:16 <King_InuYasha> smooge: yuck, I forgot about that 22:30:19 <smooge> people will see an EPEL9 and consider it solid because its EPEL 22:30:28 <smooge> playground could point to it 22:30:29 <carlwgeorge> yup 22:30:29 <King_InuYasha> the -pre branch would make sense then, even if it's more work 22:30:33 * nirik nods, agrees with smooge 22:30:34 <tdawson> pgreco: I need to double check. I know there will NOT be an Alpha release, which is already a break from tradition. 22:30:38 <King_InuYasha> because everything is going to suck anyway 22:30:56 <King_InuYasha> and that makes it less messy depending on how packages get pulled in and out 22:31:27 <carlwgeorge> we can document that anything built in epel9-next may be retired prior to 9ga if the dependencies go away 22:31:50 <King_InuYasha> I'm really not sure we should reuse epel9-next for this 22:32:10 <carlwgeorge> it's not a reuse, it's what -next is for. build against cs. 22:32:31 <King_InuYasha> -next is named as such because it points to the next minor of EL 22:32:37 <King_InuYasha> which *happens* to be CS 22:32:41 <misc> epel9-rawhide 22:32:48 * King_InuYasha snorts 22:32:48 <misc> (seems to make sysadmin run away) 22:32:51 <carlwgeorge> and when cs9 is out, the next minor it represents is 9.0 22:33:01 <smooge> epelX-playground was originally going ot be rawhide 22:33:05 <nirik> yeah. 22:33:05 <carlwgeorge> RHELhide 22:33:11 <King_InuYasha> :D 22:33:14 <King_InuYasha> there you go 22:33:15 <misc> carlwgeorge++ 22:33:15 <zodbot> misc: Karma for carlwgeorge changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 22:33:27 <Conan_Kudo> carlwgeorge++ for RHELhide 22:33:27 <zodbot> Conan_Kudo: Karma for carlwgeorge changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 22:34:02 <carlwgeorge> for the goals of the distros, rawhide works. rawhide of innovation and integration, or rawhide of stable platform. 22:34:23 <King_InuYasha> epel9-rawhide then? 22:34:25 <nirik> lets not make another name 22:34:43 <King_InuYasha> that would confuse the crap out of people anyway 22:34:50 <carlwgeorge> anyways, back to the point, with cs9 we should create epel9-next, and with rhel9 create epel9 22:35:05 * King_InuYasha shrugs 22:35:11 <carlwgeorge> buildroots are set once and stay the say 22:35:12 <michel_slm> carlwgeorge: +1 22:35:14 <carlwgeorge> *same 22:35:15 <tdawson> I think doing epel9-next just as it is supposed to be, for c9stream. And when RHEL9 is released, do epel9 just like we normally do. Two totally seperate objectives. And we make no garuntee that epel9-next packages will run on RHEL9.0. even though they might. 22:35:18 <King_InuYasha> something about that inverted relationship rubs me the wrong way 22:35:23 * nirik wants to ponder on it more, I don't have enough cycles in it to decide anything today 22:35:53 <carlwgeorge> we have a little while to decide, i'm hearing mid-april is when we want people to start paying attention to cs9 22:36:05 <carlwgeorge> (it may be downloadable before that) 22:36:22 <pgreco> carlwgeorge: I like that, but I don't see a way to enforce that packages need to be available for epel and not only for epel-next 22:36:42 <carlwgeorge> enforce via policy, not tools i guess 22:36:48 <pgreco> I guess 22:37:09 <smooge> branch automatically for 3 sets? 22:37:15 <tdawson> Ya .. I think users will notice and hopefully file a bugzilla saying "why isn't this in epelX when it's in epelX-next" 22:37:22 <carlwgeorge> just like retiring packages that get added to rhel, fix the policy violations when we find them 22:37:29 <nirik> automatically branch what? 22:38:01 <smooge> when someone does a fedpkg branch-request it does it for epelX and epelX-next (and epelX-playground?) 22:38:36 <nirik> I don't think we want that... we just got rid of the automatic playground one. ;) 22:38:53 <michel_slm> if epelX-playground is actually Rawhide (can we call it that?), maybe even make it so if your package is in epel(X-1) / epel(X-1)-next, you automatically get it in epelX-rawhide 22:39:16 <michel_slm> after all, we need to know if it can work or not 22:39:53 <carlwgeorge> hard pass on branch request magic 22:39:54 <tdawson> I think that's what epel-testing is for 22:40:01 <smooge> no I understand where nirik is coming from on this. i think we just do policy 22:40:38 <carlwgeorge> playground was explicitly advertised as "stuff can exist here and never go into main epel" 22:40:52 <smooge> no use painting the shed any colour since it will get complaints no matter what 22:41:07 <tdawson> I'm good with just policy 22:41:07 <michel_slm> tdawson: oh, we have epel-testing? 22:41:23 <smooge> testing is where stuff goes before it goes into epel regular 22:41:34 <nirik> well, there's cases where in fedora you don't want a rawhide version of your package... ie, compat packages or the like 22:41:36 <smooge> when you make a build it goes into testing repo first 22:41:44 <tdawson> michel_slm: Ya, that's where things go when they are in bodhi for two weeks. 22:41:54 <michel_slm> yeah, let's at least start with policy first 22:42:24 <tdawson> michel_slm: That allows people to test them first, while they are in bodi, and give their karma/+1 22:42:34 <michel_slm> oh that (duh) 22:42:43 <tdawson> :) 22:43:00 * michel_slm TGIF 22:43:43 <carlwgeorge> so have we settled on a policy of "if it exists in epel9-next, it must exist in epel9 when possible" 22:43:58 <michel_slm> +1 22:44:02 <tdawson> +1 22:44:13 <tdawson> What about epel8-next? same thing? 22:44:15 <michel_slm> (are we deciding on scrapping the inverse policy too? or have we done that) 22:44:19 <carlwgeorge> i'll work on more formal wording for docs 22:44:22 <carlwgeorge> tdawson: yup 22:44:27 * nirik is not going to vote today on it, need to ponder more. 22:44:35 <pgreco> +1 22:45:02 <nirik> I don't know if that policy makes sense depending on what we do for epel9/epel9-next/epel9-whatever 22:45:09 <carlwgeorge> and the related point of only requiring it via policy, not tools 22:45:38 <King_InuYasha> epel9-yakshaver 22:45:48 <michel_slm> that's the de facto right now, right, we don't have enforcement in tooling anyway 22:45:55 <carlwgeorge> i guess we don't need to have a policy for that, and just leave it up to people to complain and file bugzillas 22:46:32 <carlwgeorge> my main thing was i don't want the tools to force require an epelX branch for an epelX-next branch request 22:46:32 <pgreco> I think it will become important next year, when we don't have centos anymore 22:46:35 <pgreco> only stream 22:46:42 <tdawson> I guess policy, or no policy, we all agree to leave the tools out of it. 22:47:18 <tdawson> Everyone keeps saying what I'm saying, before I say it. :) 22:48:07 <tdawson> carlwgeorge: If you aren't going to do that policy in fedpkg, are there any more changes that you need in there? Can it do epel8-next at this time? 22:48:58 <michel_slm> we have our own internal tdawson in us 22:49:22 <carlwgeorge> fedpkg still needs some work for the branch name 22:49:32 <carlwgeorge> once i get fedpkg into shape via pull request, i think me and mboddu and/or nirik can push forward with koji/bodhi changes 22:49:32 <tdawson> carlwgeorge: OK 22:49:55 <tdawson> Anything else on epel-next? I want to make sure someone isn't waiting to bring up something else 22:50:12 <carlwgeorge> i think we're good 22:50:36 <tdawson> cool. And thank you very much for all the work you've done on the epel-next stuff carlwgeorge 22:51:01 <carlwgeorge> it's going slowly but it's definitely going 22:51:03 <tdawson> #topic EPEL-7 or EPEL-8 22:51:10 <carlwgeorge> dang $dayjob 22:51:30 <tdawson> Anything specific for EPEL7 or 8? 22:51:34 <King_InuYasha> carlwgeorge: lol 22:51:52 * King_InuYasha is waiting for shoes to drop for epel8 22:52:03 <michel_slm> do we know if epel7 branch requests are still being processed? 22:52:13 <smooge> they should be 22:52:21 <michel_slm> someone wanted lua-filesystem branched, I created the request, it's stuck after 2 days 22:52:52 <smooge> I think the requests get processed by a volunteer after their dayjob 22:53:25 <carlwgeorge> ${dayjob}s ruining everything 22:53:35 <nirik> there were some issues due to main branch changes in fedpkg... 22:53:41 <nirik> but it should be processing fine now. 22:54:03 <King_InuYasha> for $dayjob in $dayjobs;? 22:54:24 <tdawson> #topic General Issues / Open Floor 22:55:05 <rsc> michel_slm: did you mix up lua-readline vs. lua-filesystem, maybe? 22:55:06 <michel_slm> oh yeah, it got processed sometime this morning 22:55:13 <smooge> no items from me 22:55:18 <michel_slm> s/lua-filesystem/lua-readline I can't keep my packages straight 22:55:27 <carlwgeorge> my epel7 python3/python36 convo on list has morphed into a broader "EPEL python package prefixes should match the RHEL python stack they are intended to work with" 22:55:27 <michel_slm> rsc: yup woops 22:55:27 <rsc> michel_slm: I'm your co-maintainer ;-) 22:55:45 <nirik> carlwgeorge: no good deed goes unpunished 22:55:59 <michel_slm> ohai robert. didn't notice the different IRC nick. yeah, this explains why I couldn't find that bug report since the default query doesn't handle 'modified' 22:56:01 <smooge> nirik, this is epel.. you can skip the good part of the sentence 22:56:19 <tdawson> *laughs* 22:56:21 <carlwgeorge> i'm ok with it, it makes sense to get a policy for all epels, not just epel7's python36 22:56:23 * King_InuYasha snorts 22:56:26 <michel_slm> the EPEL doesn't fall... I'll show myself out 22:56:36 <carlwgeorge> michel_slm++ 22:56:37 <zodbot> carlwgeorge: Karma for salimma changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 22:57:16 <carlwgeorge> that list convo end goal is updated policy docs, which leads me to my next topic 22:57:39 <carlwgeorge> is anyone opposed to epel switching from wiki to antora format, like fedora uses? 22:57:43 <smooge> moving stuff from wiki to something else? 22:58:00 <nirik> fine with me... but it's gonna be work... 22:58:05 <Conan_Kudo> michel_slm++ 22:58:05 <zodbot> Conan_Kudo: Karma for salimma changed to 3 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 22:58:14 <smooge> carlwgeorge, I started to put the docs in the epel git repo on pagure and then ran out of give-a-f's 22:58:21 <smooge> so I have no problem with it 22:58:33 <tdawson> carlwgeorge: I don't have a problem with it either. 22:58:39 <carlwgeorge> i was thinking of just piggybacking off fedora and make additional pages in their packaging docs 22:59:07 <carlwgeorge> then it's as simple as converting from one format to the other, and eventually clearing out the wiki content with a link to the new spot 22:59:24 <nirik> well, it's more than packaging... but yeah... 22:59:27 <michel_slm> anyone knows if the process is different for new pages as opposed to revisions of existing ones? 22:59:53 <carlwgeorge> as far as i know it's just files in a repo, but i'm not an antora expert 23:00:02 <nirik> a SIG area under https://docs.fedoraproject.org/en-US/engineering/ I guess 23:00:40 <nirik> https://docs.fedoraproject.org/en-US/fedora-docs/contributing/adding-new-docs/ 23:00:46 <michel_slm> ah, I mean the review process. but if we're the SIG itself I guess it's not a problem 23:00:58 <michel_slm> (e.g. new packaging guidelines and revisions presumably need FPC review) 23:01:33 <nirik> FPC doesn't do EPEL... it's up to us to list anytime we diverge from fedora guidelines 23:02:10 <tdawson> So, as much as I hate interupting a good conversation, I also don't like long meetings. 23:02:12 <carlwgeorge> right, and currently we list that in the wiki, but it would be nice to be in the same site 23:02:15 <smooge> in the past... anything to do with EPEL got a hard pass from FPC and similar 23:02:23 <carlwgeorge> we can put a pin in this until next week, it's not urgent 23:02:30 <smooge> I was just going to have a epel.readthedocs 23:02:42 <carlwgeorge> fwiw i brought it up in fpc, and no one had a problem with it 23:02:47 <michel_slm> I'm all in favor of moving more docs into asciidoc 23:02:52 <smooge> ok 23:02:55 <tdawson> Thank you everyone for being here this week, and for the good discussions. You are all great. 23:03:01 <smooge> thanks tdawson 23:03:03 <michel_slm> thanks tdawson 23:03:04 <carlwgeorge> no you're great :D 23:03:07 <nirik> thanks 23:03:07 <tdawson> We'll talk next week, if not sooner. 23:03:13 <tdawson> #endmeeting