16:00:09 <smooge> #startmeeting EPEL meeting (2014-08-22)
16:00:10 <zodbot> Meeting started Fri Aug 22 16:00:09 2014 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:25 <smooge> .chairs nirik smooge
16:00:36 <nirik> hello.
16:00:41 <Evolution> morning.
16:00:46 <mhroncok> hi
16:00:52 <bstinson> greetings!
16:00:59 <orionp> hello
16:01:08 <smooge> #meetingname EPEL reboot
16:01:08 <zodbot> The meeting name has been set to 'epel_reboot'
16:01:24 <smooge> #topic meet and greets
16:02:01 <smooge> thanks.. I forgot that
16:02:02 <nirik> now it should be able to change the topic. ;)
16:02:07 <smooge> #topic meet and greets
16:02:34 <avij> hello
16:03:14 <smooge> Hi guys this meeting is about EPEL.next or the re invigoration of EPEL for 7
16:03:27 <smooge> suggested topics will be
16:03:56 <smooge> alternate repository ideas
16:04:09 <smooge> Review and cleanup of EPEL policies
16:04:19 <smooge> Moving EPEL7 out of Beta
16:04:23 <smooge> and Open Floor
16:04:39 <smooge> #chair nirik smooge
16:04:39 <zodbot> Current chairs: nirik smooge
16:04:51 <smooge> any other items I should add to the agenda?
16:05:44 <smooge> #topic Fork in the Road (EPIC or EPEL dot releases or same old same old)
16:05:46 * nirik thinks thats fine. I guess we could add a 'should we keep meeting? weekly? bi-weekly? every other fortnight?
16:06:06 <smooge> ok will add that before the end
16:06:54 <nirik> so, personally... I'm fine with the ways things are right now. ;) I know that others are not for various reasons...
16:07:11 <jnix> seconded
16:07:22 <jnix> i like the alternate repo idea but what do i know =)
16:07:33 <smooge> So EPEL is at an interesting crosspoint. It has many many many active users but does not have a lot of developers/contributors and what its needs are fiercely split between I need newer stuff in EPEL-5 and I need the exact old stuff in EPEL-5 (or vice versa)
16:08:29 <smooge> As there is no steering committee to make decisions, we end up making decisions in the end by who shows up at the meeting and going from there.
16:08:34 <orionp> I agree that the need is there, hopefully the packagers will be there too.
16:09:12 <smooge> Well most of the packages that are in EPEL are only there because the Fedora owner was asked to put it in EPEL and that owner has no interest in EPEL
16:09:16 <nirik> between a 'we can make major changes at rhel release points' and a 'seperate repo for fast stuff' I would prefer the seperate repo
16:09:42 <Evolution> to some extent we (the royal CentOS we) can help on the dev side with some things.
16:09:47 <nirik> but, as noted I am mostly happy with things as they are, so I would expect those people who want this to step up and do the work. ;)
16:09:53 <orionp> Can we somehow join forces with centos?
16:10:02 <Evolution> orionp: that's why I'm here :-P
16:10:07 <Evolution> along with avij and bstinson
16:10:10 <orionp> great
16:10:30 <orionp> I like the separate repo for faster stuff
16:10:40 <mhroncok> me too
16:10:44 <nirik> orionp: would that better meet your needs for python3?
16:11:03 <orionp> Can a package be kept at an older version in EPEL and newer in the faster repo (EPIC?)
16:11:08 <Evolution> so, I think we may need to take a step back a second to actually look at the issues.
16:11:23 <Evolution> it seems like we have a couple broad things to touch on.
16:11:33 <nirik> there's about eleventy million things to sort out about another repo. ;) we should probibly make a wiki page or piratepad or something...
16:11:33 <jnix> i'll be getting into epel development as well though i'm nowhere close to being a professional
16:11:38 <nirik> Evolution: +1
16:11:44 <Evolution> one is the epel structure itself.
16:11:48 <smooge> Currently EPEL is tied deeply into Fedora infrastructure. So I get the feeling that a new repository system is going to need to set up either new code in everything from Koji/Bodhi/Fas or set up a new infrastructure with it.
16:11:56 <Evolution> 2 is current epel. 3. would be a new repo.
16:12:05 <smooge> #chair Evolution
16:12:05 <zodbot> Current chairs: Evolution nirik smooge
16:12:35 <nirik> well, thats a outstanding question: would any newer fast repo be also in fedora infra? or completely seperate?
16:12:41 <dgilmore> smooge: its quite easy to setup new tags in koji, bodhi bits etc
16:13:00 <dgilmore> we probably will need to set it up as a new product
16:13:03 <dgilmore> not a huge deal
16:13:07 <smooge> dgilmore, I got a different impression from an email from you earlier. My apologies for misreading
16:13:08 <orionp> Integrating with Fedora git is the best thing about EPEL
16:13:35 <Evolution> so, for a newer fast moving repo, I'd like to see it as a 'separate thing' with people from both centos and fedora
16:13:40 <Evolution> as a collaborative product
16:13:42 <dgilmore> smooge: its not without some cost
16:13:47 <dgilmore> so has to be carefully done
16:13:51 <dgilmore> but its quite doable
16:14:01 <nirik> orionp: right, thats what we drop by having it seperate, but there's other advantages...
16:14:10 <Evolution> it's of huge benefit to us with respect to our SIG effort, so I'm very much interested in how this should play out.
16:14:19 <dgilmore> Evolution: I want to work on ways to enable to contribute to EPEL via a CentOS path
16:14:26 <nirik> Evolution: it would also allow for more easy things like using centos 32bit x86 or whatever.
16:14:51 <smooge> woops tried to do this in a different channel
16:14:54 <smooge> #chair dgilmore
16:14:54 <zodbot> Current chairs: Evolution dgilmore nirik smooge
16:15:05 <Evolution> dgilmore: and vice versa. some of what we do for the sigs may be useful upstream as well.
16:15:05 <jnix> i'd like to see an epel-desktop
16:15:43 <dgilmore> Evolution: sure :) its will take planning and effort and some sharing of resources
16:16:16 <orionp> If we are going to collaborate with centos (which we should), why only for the fast moving repo?
16:16:20 <Evolution> well, since we seem to be down in the weeds already... we had looked at 2 auth platforms. freeipa and fas.
16:16:26 <dgilmore> I think a big plus of how epel works today is the ease of branching from fedora in git
16:16:32 <Evolution> freeipa requires some dev work, and we don't have the $$$ for that.
16:16:57 <dgilmore> orionp: as i said epel also
16:17:05 <orionp> ah
16:17:06 <Evolution> so we're likely going to implement a fas setup. we have koji for our community builders already.
16:17:11 <dgilmore> Evolution: we are looking at a fas3 i believe
16:17:31 <Evolution> dgilmore: feature request for federation then?
16:17:32 <smooge> federated fas
16:17:40 <Evolution> perfect.
16:17:41 <dgilmore> Evolution: sure :)
16:17:52 <nirik> Evolution: yeah, we are going to be working on a fas3 very soon. Good time to get requests in...
16:18:12 <nirik> Evolution: also, there's talk of a FAD to work on it in december. Would be awesome to get some centos folks along...
16:18:12 <Evolution> where's the appropriate place to do that?
16:18:24 <Evolution> nirik: tell me where and when.
16:18:33 <nirik> https://fedoraproject.org/wiki/EPEL-faster-repo-ideas
16:18:38 <dgilmore> Evolution: I think for a seemless CentOS and Fedora pathways to epel contribution it would be much much easier if we shared a kojidb.  we could have seperate hubs and builders
16:18:41 <nirik> (ideas container for questions/comments)
16:19:27 <nirik> Evolution: https://github.com/fedora-infra/fas/issues
16:19:33 <Evolution> dgilmore: we're already working on adapting the fedora toolkit, so this should be possible.
16:19:42 <nirik> https://fedoraproject.org/wiki/FAD_MirrorManager2_FAS3_2014
16:19:51 <nirik> (location is all up in the air right now tho)
16:19:52 <Evolution> dgilmore: bstinson is working on fedpkg->centpkg changes.
16:20:05 <Evolution> I believe he's thrown a couple patches at the list for that already
16:20:11 <dgilmore> Evolution: i look forward to patches
16:20:29 <dgilmore> I pulled some patches in and asked questions on some others
16:20:54 <dgilmore> reminds me i need to get on centos-devel and bitch about how the lookaside cache is setup
16:20:59 <dgilmore> its a nasty nasty thing
16:21:20 <Evolution> dgilmore: you, kb and mikem can all fight that one out :-P
16:21:46 <dgilmore> Evolution: i talked to mikem about it he said to mail the list
16:22:00 * kbsingh pops in
16:22:33 <Evolution> dgilmore: what benefit would a shared kojidb get us?
16:23:18 <nirik> anyhow, we might be difting off here. ;)
16:23:31 * orionp agrees
16:23:59 <dgilmore> Evolution: that people can go to koji.centos.org and see their epel builds
16:24:00 <Evolution> right. so, to the high level topics, what should be addressed first?
16:24:18 <smooge> ok in any case.. we have 3 roads. It looks like most people would like EPEL to stay the same and we look at setting up a new repository for faster moving stuff.
16:24:33 <smooge> does that sound correct to people here?
16:24:40 <mhroncok> yes
16:25:02 <nirik> I like that best personally. Then we don't need to change existing expectations on EPEL much.
16:25:23 <bstinson> so how do we best choose what goes where?
16:25:28 <smooge> #topic EPIC (working title only but that was what EPEL was too)
16:25:36 <Evolution> smooge: I don't think epel has a choice but to  maintain course
16:25:47 <Evolution> changing it at this point would have too great an impact.
16:25:57 <smooge> so EPIC was discussed as the name for a forked repository for faster moving items.
16:26:26 * nirik is happy to use a different name don't care.
16:26:51 <Evolution> I hate the name, but I don't have a better one.
16:27:03 <smooge> I am only using it as a seperate name to keep it clear its not same-old EPEL. If it turns out we call it EPEL.fast or something like that I don't mind
16:27:13 <mhroncok> what would actually "faster moving" means then?
16:27:34 <nirik> good question. ;)
16:27:38 <orionp> I'd prefer epel-<fast/something> to build on the EPEL name
16:27:50 <Evolution> overwriting base packages is the idea.
16:27:51 <smooge> so the general rules for EPEL are: 1) package is to be maintained with only security updates and no ABI/API changes for the 7 year lifetime of RHEL
16:27:59 <nirik> epel-riptide!
16:28:15 <nirik> basically 'no incompatible updates'
16:28:34 <nirik> this new repo could toss that away. But not sure how mad that would make users. ;)
16:28:57 <orionp> I think the main benefit is API/ABI changes,  haven't thought about overriding base - that seems to be a separate issue
16:29:10 <bstinson> what if we make EPIC API/ABI breaks possible at EL point releases?
16:29:12 <mhroncok> nirik: but there has to be limits, otherwise you change stable distro for rawhide
16:29:16 <smooge> 2) Packages can only be updated to a newer version if there are no security fixes being backported to the old software and a window to announce that things are going to break is announced
16:29:42 <nirik> sure. There's lots of possibilities.
16:29:44 <smooge> bstinson, I would like to cover that in a seperate meeting as that might be weeds. At this point I want to stick to the basic question of what goes where
16:30:13 <smooge> 3) Packages needs owners and orphaned packages are removed regularly.
16:30:16 <nirik> breaks at point releases don't work too well I don't think... we can't even build against the new point release until after it's out.
16:30:31 <smooge> nirik, dgilmore anything I missed on what was the EPEL promise to users?
16:30:56 <Evolution> so, one of my more self-serving reasons for being here is the CentOS SIG structure. we have projects like ceph, ovirt etc who need newer packages like libvirt.
16:31:04 <nirik> smooge: we don't actively do 3, although we should. ;)
16:31:24 <Evolution> I think this is a decent place for the sigs to share these packages, and ensure that their changes get upstreamed if possible.
16:31:39 <nirik> Evolution: so those are 'newer than base repo' ?
16:31:51 <Evolution> plus it would ensure that these packages are maintained by these groups.
16:31:53 <Evolution> nirik: yes.
16:31:56 <dgilmore> i prefer EPEL extras as the fast moving repo
16:32:23 <nirik> smooge: oh, yeah, and 4) no overlapping with the things we say we won't overlap with
16:33:01 <Evolution> I would prefer to see a new repo minted as something not epel, and not centos
16:33:07 <Evolution> but as a collaboration between the two.
16:33:35 <dgilmore> Evolution: well I want EPEL to be a collaboration between the two
16:33:45 <dgilmore> and all of this could be an extention on that
16:33:54 <nirik> eptos! :)
16:33:56 <dgilmore> perhaps we need three repos
16:34:02 <dgilmore> epel as is
16:34:19 <dgilmore> epel-extras for things that move fast, mediawiki python3 etc
16:34:39 <dgilmore> epel-universe where we could have newer libvirt etc
16:34:58 <mhroncok> dgilmore: what could depend on what?
16:35:03 <dgilmore> where if you enable it you are accepting that base os things could be replaced
16:35:05 <kbsingh> epel-stable, epel-rolling, epel-edge ?
16:35:17 <nirik> FWIW, I am fine with mediawiki and python3 in epel. with newer parallel installable packages. But I guess a extras could work depending on how it was set to do the updates.
16:35:22 <kbsingh> and things can depend on stuff to their left
16:35:44 <dgilmore> kbsingh: something like that yes
16:35:54 <mhroncok> kbsingh: what if python3 needs a newer library than in epel/rhel?
16:36:13 <kbsingh> mhroncok: then that lib comes at the same level as python3, or a repo on its left
16:36:25 <kbsingh> mhroncok: i think most people should try and go as far left as possible
16:36:27 <dgilmore> nirik: well in extras they wouldnt need to be parallel installable. you know if it comes from extras it may need some work on updates to keep working
16:36:33 <orionp> Things can move to the right if needed?
16:36:36 <nirik> well, here's the issue...
16:37:26 <kbsingh> orionp: things should have a graceful sunset process... and new instances, in newer versions of the same thing can come up on the right side
16:37:36 <nirik> say I use mediawiki in production. It's in epel-extras. The maintainer there says... hey, new incompatible version, pushes it out. I am not ready to upgrade it yet, so either it breaks me, or I avoid the update. Then a security issue comes in the version I am using and no update.
16:37:53 <kbsingh> orionp: the challenge is mostly that people need to not be surprised one morning that ZOMG I'm running yesterdays build of ruby
16:37:55 <nirik> if there's 2 parallel installable versions... _I_ can decide when to move
16:38:02 <dgilmore> nirik: sure. not saying its not easy.
16:38:06 <nirik> right. expectations are key here.
16:38:20 <nirik> we need to have a very clear process for when incompatible changes happen
16:38:27 <dgilmore> nirik: but by putting it in extras its setting an expetctation
16:38:33 <dgilmore> its just an example
16:38:49 <kbsingh> parallel installs are hard as well... the Provides: requires: mapping gets hairy ( eg. pho53 and php52 and php54 -should- all provide PHP - but how does a mediawiki Require its php ? )
16:38:53 <nirik> yeah, althought I might not want to use it if it was in there due to the above reasons.
16:39:04 <mhroncok> it has to bee crystal clear that in soem repos, thing are rolling and can get broken
16:39:05 * nirik nods.
16:40:11 <Evolution> so, what about reducing the life expectancy of the repo as a whole.
16:40:22 <dgilmore> we would need to set expectations clearly
16:40:22 <Evolution> rhel extras has a lifespan of 18 months iirc
16:40:50 <kbsingh> if we want to drive expectation based on repo name, then I'm going to vote we dont use words like 'extras' and 'plus' but more like 'rolling' and 'stable' and 'longterm' and 'edge'
16:41:00 <dgilmore> Evolution: i was thining epel-extras would work somewhat similiar to rhel-extras
16:41:34 <nirik> kbsingh: +1
16:41:38 <mhroncok> dgilmore: and that is?
16:42:21 <dgilmore> https://access.redhat.com/support/policy/updates/extras
16:42:24 <mhroncok> thanks
16:43:04 <dgilmore> so it seems we are all kinda on the same page
16:43:21 <dgilmore> we have some naming, and workflows etc to sort out
16:43:35 <dgilmore> and some implementation details to figure out
16:44:22 <Evolution> that's what other meetings are for
16:44:37 <dgilmore> right
16:44:42 <Evolution> do we want to address the other major point smooge brought up with EPEL policy cleanup?
16:44:43 <mhroncok> rhel extras seems like there are only "extra" packages (as oposite to let's say Debian Backports)
16:44:49 <Evolution> or policy creation in general?
16:45:03 <dgilmore> mhroncok: right extra packages rapidly changing
16:45:35 <mhroncok> dgilmore: and if they need newer dependencies that would break regular epel?
16:45:42 <smooge> question to Evolution and kbsingh .. is RHEL-7-extras rolled into CentOS directly or as a seperate repo?
16:45:52 <kbsingh> into centos extras at the moment
16:46:02 <smooge> thanks
16:46:07 <Evolution> it won't be exactly 1:1
16:46:12 <Evolution> but it rolls right in.
16:46:25 * nirik understands why rhel-extras is there, but it kinda makes me nervous.
16:46:26 <kbsingh> no, i suspect our extras will be larger ( or be epel-stable ) or something similar
16:46:30 <Evolution> the extras repo is where we were going to add things like epel-release
16:46:51 <Evolution> so we would have everything from rhel-extras, plus a bit more.
16:46:52 <kbsingh> if we were able to find a way for EPEL to -be- the CentOS Extras, were winning
16:47:01 <kbsingh> but large chunks of values of 'win'
16:47:16 <kbsingh> since we can then setup EPEL to be the primary target for SIG's and parallel / variant builds and content
16:47:32 <dgilmore> kbsingh: well we decided after Red Hat requested to remove everyting in rhel-extras from epel
16:47:42 <kanarip> (and ISVs)
16:47:52 <kbsingh> ( some might still fork and do their own repos, and thats fine - even good to some extent ) - but if their content was going into a single pool, much win
16:48:17 <dgilmore> kbsingh: im sure there is some need for a copr type setup as well
16:48:36 <dgilmore> which is maybe where ovirt lands with its replacing libvirt etc
16:48:52 <kbsingh> ovirt etc are going ito CentOS SIG's right ?
16:49:06 <Evolution> yes.
16:49:16 <dgilmore> kbsingh: i think so, Evolution said that it wants to replace libvirt
16:49:17 <kbsingh> at the moment they are setting up to be their own repo, only depending on CentOS base + Virt SIG content
16:49:21 <nirik> https://fedoraproject.org/wiki/EPEL-faster-repo-ideas <- have been updating with ideas, everyone feel free to add issues and proposed solutions...
16:49:27 <dgilmore> so we need to work out how to enable that
16:50:01 <kbsingh> so, i have a problem here - need to get onto yet another call, 5th of the day, in 11 min, and want to stretch. How can i follow the convo going forward, is this going to be on epel-devel ?
16:50:20 <nirik> should be good there, yes.
16:50:21 <Evolution> kbsingh: meetbot is logging, so notes should be sent out, yes.
16:51:34 <kbsingh> ta
16:52:46 <Evolution> so, to keep things moving a bit, what else needs to be addressed? smooge || nirik || dgilmore ?
16:53:37 <nirik> lots of policy questions: when are incompatible upgrades allowed? when are overlaps allowed?
16:53:38 <dgilmore> I think at this point we need to outline what we want and take it to the epel and centos communities and get buy in
16:54:00 <nirik> yeah, so I'd say we work on the wiki page/come up with more detailed plans and see what we have next week?
16:54:01 <dgilmore> answering nirik's questions in the process
16:54:29 <dgilmore> we seem largely on teh same page. get things down and present it
16:54:55 <Evolution> okay. dgilmore you'll bring up your comments/question about the buildsys etc on the centos-devel list as well?
16:55:23 <dgilmore> Evolution: sure.
16:55:39 <Evolution> thanks
16:55:46 <billings> nirik: it might be worth putting something on there about rpm spec stylistic guides for providing requirements in a repo-specific way
16:55:58 <billings> requirements *and* provides
16:56:30 <billings> or at least the fact that some sort of suggestions will probably be necessary
16:56:36 <nirik> you mean per repo/branch guidelines for specs?
16:56:42 <billings> yeah
16:56:48 <nirik> sure
16:57:21 <billings> since there's going to be issues with how, say, mediawiki in -edge will require the -edge version of php
16:57:33 <billings> (maybe)
16:57:43 <smooge> have we moved to the next topic or are moving to it.. I got lost in where we are :)
16:57:44 <billings> I'm not sure how the packages from the multiple repos will interact
16:57:57 <Evolution> smooge: so did everyone else I think.
16:58:05 <smooge> ok since we are in the weeds.
16:58:15 <Evolution> it got all "leeeroy jenkins" rather quickly
16:58:26 <nirik> well, it wouldn't have to require a newer php, but it could
16:58:27 <billings> sorry
16:58:56 <RemiFedora> simply have to requires php(language) >= min_version  (which should be provided by all php versions)
16:59:03 <smooge> well I didn't mean for him to leave
16:59:20 <Evolution> I wasn't even directing that at him.
16:59:25 <dgilmore> I need to run, have to go pick up my new laptop and get the brakes on my car fixed
16:59:27 <Evolution> that happened well before he said anything
16:59:29 * nirik hopes that was unrelated. ;)
16:59:41 <nirik> dgilmore: safe travels.
16:59:46 <smooge> #topic Cleanup of Fedora EPEL policies
17:00:02 <smooge> billings if you read this on epel-devel later... sorry we weren't asking you to leave :)
17:00:29 <smooge> ok so our policies have been rather haphazard since the steering committee wandered into the wilderness a long time ago
17:00:53 <smooge> heck I am not sure we ever got to cleaning up our wiki pages from stuff from Extras days
17:01:00 <nirik> well, I think that is largely because there aren't many policies or decisions
17:01:20 <nirik> I did a complete revamp of our wiki stuff when epel6 went out.
17:01:35 <nirik> which people then reverted part of and brought back the horrible faq page. ;(
17:01:53 <Evolution> so, do we re-implement a new committee?
17:01:54 * nirik hasn't done much to wiki space since 6 tho
17:02:37 <Evolution> I dislike wikis in general these days. git+markdown/asciidoc etc makes it remarkably easy for anyone to contribute or fix things.
17:03:07 <Evolution> and there's usually a chance at more sane versioning
17:03:26 <nirik> wikis do tend to get overgrown and horrible
17:03:51 <bstinson> presumably the committee would be charged with directing packages through the workflow?
17:04:55 <smooge> well the first thing would be to document and clear up problems in the workflow :)
17:05:01 <nirik> well, how would we select a committee?
17:05:50 <nirik> I'm fine with people who show up to meetings and do work come to consensus on things... but if people want more formal we could.
17:06:26 <bstinson> i think there should be at least 1 or 2 "formal" members to provide some continuity
17:07:08 <Evolution> I'm fine with lazy consensus for day-to-day business, but I agree with bstinson. there should be a couple people in an official capacity who are ultimately responsible.
17:07:31 <nirik> well, smooge and me and dgilmore have been doing everything... so thats 3... ;)
17:08:09 <Evolution> I'd nominate myself from the centos side if you'll have me.
17:08:21 <nirik> sure.
17:08:25 <bstinson> +1
17:08:53 <nirik> So, start with 4 and add from there? (although 4 means there could a a deadlock if voting is used)
17:10:21 <smooge> I think i was the last chair of the EESCO and put it to bed.. but not sure.
17:10:22 <mhroncok> one more from centos would make sense
17:10:27 <nirik> and to be clear, I'd love for there to be more active people working on things... there's lots of stuff we could do, but don't
17:10:49 <nirik> but that doesn't need any comittee... just people willing to step up and work on things. ;)
17:12:11 <Evolution> nirik: honestly, I'm somewhat alright with the possibility of a deadlock.
17:12:32 <nirik> sure. I don't think it will really happen.. we are all reasonable people.
17:12:37 <smooge> hahahahaha
17:12:42 <smooge> *snort* hahahaahaha
17:12:43 <Evolution> except that smooge character
17:13:09 <nirik> yeah, he's a bit shifty looking.
17:13:21 <nirik> anyhow, I have a ton of other stuff to get to, was there more we wanted to hit today?
17:13:46 <smooge> I would like to end the meeting in 15 at the latest
17:13:56 <smooge> #topic Moving EPEL-7 out of beta
17:14:25 <smooge> so how is our feeling of doing this? In the next week, two weeks after alpha?
17:14:38 <nirik> I'm fine anytime.
17:14:51 <nirik> the problem has been that I don't fully know the process and dgilmore has been too busy.
17:14:57 <nirik> we really need to make a SOP out of it.
17:16:06 <smooge> ok first order of business. SOP needs to be made for moving stuff from beta to production. It will be helpful for any other channels we make
17:16:07 <Evolution> nirik: added a section to your wiki page.
17:16:55 <avij> would signing all the current epel7 beta packages be a suitable first step? or would that need to be redone anyway for all packages? I don't know the release process well enough.
17:16:56 <smooge> I propose that we move EPEL out of beta on Sep 15
17:17:04 <nirik> it's mostly just a matter of changing koji tags, adding stuff to bodhi, making the base repos, etc.
17:17:08 <orionp> Let's do it - need  broken deps check though
17:17:15 <nirik> avij: they are mostly all signed now.
17:17:33 <Evolution> yes. there are still a few things (yumex) with broken deps
17:17:35 <nirik> orionp: we were also going to untag things with broken deps
17:17:38 <avij> nirik: someone complained about fail2ban not being signed a while ago. I have not checked the situation.
17:17:58 <nirik> avij: they are not 100% signed. ;) it's as we do it..
17:18:18 <smooge> that gives us 3 weeks to clean up broken deps, add what stuff needs to be added, get the docs written
17:18:34 <nirik> I'd actually prefer to do it sooner personally.
17:18:49 <nirik> people have been chomping at the bit for it
17:18:51 <orionp> Is there a list of broken deps anywhere?
17:19:06 <nirik> orionp: I sent one to the list a while back, but 'repoclosure' will give you one. ;)
17:19:07 <Evolution> I don't think what's currently epel-7-beta would change in policy from epel-6, which isn't going anywhere.
17:19:26 <Evolution> I'm fine with moving epel-7 to production and growing it within the current scope.
17:19:47 <Evolution> as we adjust/clean-up we do so for all epel, not just a branch or two
17:20:14 <Evolution> tl;dr +1 to nirik's "do it faster"
17:22:16 <smooge> nirik, ok I didn't know how alpha freeze and such would affect things
17:22:44 <nirik> well, we just need to get some cycles from dgilmore. ;)
17:23:16 <nirik> it's also possible that the process for f21 going into alpha freeze has a bunch of overlap with epel7 going out of beta, so we could share sop/process there.
17:24:59 <Evolution> If it makes sense, I'm completely fine with borrowing heavily from working practices.
17:25:10 <Evolution> there's no need to invent new wheels.
17:25:47 <smooge> okie dokie. We can't decide on this without dgilmore so we will need to take this to email then.
17:26:15 <smooge> #topic Open Floor
17:26:42 <smooge> ok any items for open floor.. or everyone typed themselves silly
17:27:33 <nirik> do we want to meet again next week ? same time?
17:28:38 <Evolution> I'm fine with that.
17:29:08 <smooge> I am fine with that. I have had 1600 UTC as a meeting reminder for 2 years
17:29:32 <smooge> so next meeting will be next Friday. It will be 1 hour long period
17:29:42 <Evolution> wfm
17:29:52 <smooge> okie dokie. I will close in 10
17:30:11 <smooge> #endmeeting