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