22:12:26 <nirik> #startmeeting EPEL (2012-05-23)
22:12:27 <zodbot> Meeting started Wed May 23 22:12:26 2012 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:12:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
22:12:27 <nirik> #meetingname epel
22:12:27 <nirik> #topic init process/agenda
22:12:27 <nirik> #chair smooge tremble
22:12:27 <nirik> EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S HackMan
22:12:27 <zodbot> The meeting name has been set to 'epel'
22:12:27 <zodbot> Current chairs: nirik smooge tremble
22:12:34 <nirik> ok look, more meetings.
22:12:38 <nirik> see how productive we are. ;)
22:12:43 <abadger1999> hello goodbye.  goodbye hello :-)
22:12:48 <nirik> quite
22:12:52 <maxamillion> o hai
22:12:54 <dgilmore> gday
22:12:59 <NiveusLuna> fancy seeing you all here
22:13:06 <nirik> anyhow, as I was saying... I will get the script setup somewhere and anyone who cares to poke at it can do so.
22:13:30 <nirik> ok, moving along.
22:13:35 <nirik> #topic RHEL overlaps
22:14:11 <nirik> ok, skvidal and smooge worked on coming up with a list of where we overlap with RHEL.
22:14:14 * stahnma strongly oppose pulling puppet+rubygems from EPEL
22:14:26 <nirik> http://skvidal.fedorapeople.org/misc/epel-clashes/
22:14:44 <nirik> so, first the easy thing that I think we can all agree on:
22:14:50 <stahnma> (disclosure: I work at Puppet Labs)
22:14:51 <nirik> we should fix the overlaps in os/optional.
22:15:11 <nirik> and document the packages we are shipping due to arch needs.
22:15:11 * rbergeron pops in
22:15:33 <nirik> hey smooge and rbergeron
22:15:40 <smooge> sorry missed the transition.. was reading bjs's latest email
22:15:45 <smooge> and not replying anymore
22:16:10 * dgilmore thinks that unless a layered product asks us to remove packages they ship they should remain in epel
22:16:12 <nirik> yeah, so I was saying that we need to fix the overlaps in os/optional. Does anyone disagree with that?
22:16:26 <dgilmore> nirik: no that needs fixed
22:16:28 <smooge> no i think those should get pulled.
22:16:51 <nirik> and we need to document the ones we are shipping for special arch needs that fit into that bucket.
22:16:51 <stahnma> +1
22:16:58 <smooge> dgilmore, what steps would I need to put in something in various trees to help make sure it doesn't happen again
22:16:58 <dgilmore> nirik: anything thats in the channels we use to populate the buildroots should not be replaced
22:17:00 <stahnma> that's been how it worked since EL6 shipped
22:17:03 <abadger1999> +1
22:17:22 <nirik> dgilmore: right. Unless we are allowing it because we need it for 32bit.
22:17:33 <dgilmore> nirik: absolutly
22:17:35 <smooge> eg something like branch glibc/el6 and put a dead.package in it?
22:18:09 <nirik> for preventing, I think perhaps we could try and get RHEL folks to be better about letting us know when something is added?
22:18:13 <nirik> so we can remove it...
22:18:22 <nirik> it's not like it happens all the time, only at releases...
22:18:31 <smooge> basically if there are steps needed to block builds I cand do so to take it off of someones list
22:18:31 <dgilmore> smooge: ideally we have some kind of api we can query when making epel branches that can tell us if its in rhel or not
22:18:44 <smooge> dgilmore, ah ok
22:18:50 <nirik> dgilmore: that would be nice too.
22:18:53 <dgilmore> smooge: then we can also periodically query it to see if things have been added we need to remove
22:19:30 <dgilmore> smooge: base os in there checklists they have steps to check with epel and communicate to epel maintainers
22:19:49 <dgilmore> but layered producst dont have the same things
22:20:12 <dgilmore> im starting some discussions to make sure layered products consider epel in the work they do
22:20:28 <nirik> so, I can try and work on the os/optional overlaps... does anyone else want to help out? if so, we might be able to make short work of it...
22:20:37 <nirik> dgilmore: excellent.
22:20:39 <ktdreyer> dgilmore: that's great
22:20:59 <smooge> well I have a list of the base os overlap already
22:21:06 <stahnma> we've been trying to get the RHEL developers to let us know when stuff changes since the inception of EPEL, and I think that's happened in very minimal ways only
22:21:24 <stahnma> the only communication I ever saw was when RHEL6 was close to shipping, and told us what to pull
22:21:26 <nirik> smooge: yeah, skvidals list is good there, but we still have to check each one and see if we are shipping it for the 32bit
22:21:39 <dgilmore> stahnma: with rhel6 they are supposed to do it, it is in the list of tasks when adding a package
22:21:55 <smooge> well actually I was going to say.. just compare the overlap in i386 channels. If it overlaps there it is a problem.
22:22:01 <stahnma> dgilmore: cool.  So the layered product are not that way?
22:22:11 <nirik> smooge: yeah.
22:22:19 <smooge> that is the list I had done.
22:22:32 <nirik> smooge: do you have that list handy?
22:22:41 <dgilmore> stahnma: no they are not
22:22:53 <stahnma> dgilmore: ok
22:22:57 <dgilmore> stahnma: im starting on a path to fix that
22:23:16 <nirik> I see 11 packages in base.
22:23:21 <stahnma> well, if we pulled things that some of the layered products use from EPEL, I would find EPEL infinitely less helpful
22:23:41 <NiveusLuna> just to clarify: what are layered products?
22:24:01 <nirik> I see 30ish some in optional, and most of those are perl packages.
22:24:01 <smooge> nirik, http://fpaste.org/aMAM/
22:25:25 <nirik> right, ok.
22:25:31 <dgilmore> NiveusLuna: layerd products are things that Red Hat ships that are add on things, Satellite is one for instance
22:25:33 <nirik> we can work on nuking those and blocking them.
22:25:50 <misc> NiveusLuna: or directory server, iirc
22:25:56 <dgilmore> nirik: i bet most/all of the perl ones are because they ship on x86_64 only
22:26:14 <nirik> dgilmore: well, perhaps they once did, but they also overlap in 32bit too.
22:26:18 <smooge> dgilmore, those perl ones are in the i386 channel now
22:26:18 <nirik> now at least
22:26:44 <misc> NiveusLuna: https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux#What.27s_the_difference_between_rebuilds_and_Red_Hat_Enterprise_Linux_.3F
22:26:50 <nirik> NiveusLuna: stuff under: ftp.redhat.com:/pub/redhat/linux/enterprise/6Server/en
22:27:34 <nirik> so, our current policy is:
22:27:46 <nirik> " "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible)."
22:28:27 <nirik> so, how would people want to amend that?
22:28:38 <nirik> if we don't amend it, it means removing a great deal of stuff from EPEL.
22:29:39 <nirik> I'll note that we have overlapped with some of those channels for quite a while... and have heard not much feedback about it.
22:30:09 <smooge> I would like to amend it to enterprise/6*/en/os/
22:30:10 <nirik> the discussion on the list started with glusterfs.
22:30:28 <dgilmore> nirik: maybe add that if a package ships in a layered product we will removeit if asked to but otherwise its ok,  ideally shipping with the same or a lower nvr than shipped in RHN
22:30:35 <nirik> but it turns out the RHS channel glusterfs is in is pretty obscure...
22:30:43 <stahnma> and then I think z00dax said they would just move gluster into centos-plus or something?
22:31:01 <stahnma> what will happen is if EPEL pulls the software people want, another repo will put it in
22:31:09 <stahnma> making the EL world less fun to deal with all the way around
22:31:15 <ktdreyer> stahnma: agreed
22:31:23 <rbergeron> stahnma: yup
22:31:40 <nirik> well, ideally we want to not mess up anyone...
22:32:13 <nirik> including: other oses that use epel and have no layered products and rhel customers who do use layered products
22:32:16 <stahnma> the easiest technical solution would be to have the RH layered products use same versions we ship in EPEL, but I realize that's a bit backwards for the flow
22:32:54 <NiveusLuna> at the same time, the more that's in epel, the less people think they have to use repos that aren't up to our standards
22:32:55 <stahnma> and/or not charge for layered products; but I imagine that is combative with business goals somewhere
22:33:16 <nirik> some of the channels seem very specific to me... and I am having trouble seeing where someone would enable epel on a appliance like thing that uses that specific channel.
22:33:30 <stahnma> nirik: nod
22:33:40 <dgilmore> nirik: i dont think they would
22:33:44 <smooge> and if they do, well they loaded the gun and aimed at their foot.
22:33:46 <nirik> ie, if you are running a Red Hat storage appliance, why would you enable epel on it, it does one thing...
22:33:56 <nirik> or a cloud controller node
22:33:57 <stahnma> there are also cases where tools are used to do setup, but not actually what Red Hat is saying is the value-prop
22:34:08 <stahnma> e.g. MRG using Puppet to set things up (if it still works that way)
22:34:09 <nirik> but I could well be missing use cases.
22:34:59 <stahnma> if we pull nothing, will it encourage collaboration between RH product groups and EPEL maintainers?
22:35:09 <rbergeron> I would expect that there are other projects that use puppet that would be adversely affected.
22:35:33 <stahnma> rbergeron: I would agree =)
22:35:46 <stahnma> on the upside, I would lose like 60 packages that I maintain
22:35:54 <nirik> there are other things too that are popular... mogodb, etc.
22:36:07 <stahnma> yeah, mongo seems again seems somewhat general purpose
22:36:14 <rbergeron> mmhmm
22:36:46 <smooge> ruby-augeus would pull out all the other configuration management tools
22:36:59 <nirik> so the most difficult one I see is the cloudforms channel.
22:37:13 <nirik> as a loophole, I note they only ship 64bit. ;)
22:37:28 <stahnma> having split arch on that stuff isn't fun
22:37:36 <stahnma> esepcially since many of those packages are actually noarch
22:37:41 <nirik> yep.
22:39:19 <rbergeron> what stuff from cloudforms is in epel other than puppet?
22:39:31 <rbergeron> it seems like a crock to have to remove it when aeolus isn't even in EPEL
22:39:39 <nirik> proposal: EPEL6 will not ship any packages that have src.rpms under enterprise/6*/en/os/ with an exception for packages not shipped on one arch. Channels under enterprise/6/en/ may request EPEL remove any overlaping packages, and may be queried by EPEL about such overlaps from time to time.
22:39:41 <rbergeron> unless it used to be and is now disappeared since a few days ago :)
22:39:54 <nirik> http://skvidal.fedorapeople.org/misc/epel-clashes/epel-x86_64-clashes
22:40:10 <nirik> looks at the rhel-x86_64-server-6-cf-ce-1 section
22:41:08 <smooge> rbergeron, many of the items that puppet depends on to work are also used by other configuration management tools either directly or indirectly. Doing a loop of requires grows out to a LOT of packages
22:41:52 <stahnma> yeah, the rubygem stuff is more than half the reason I use EPEL (and maintain those packages)
22:42:22 <nirik> perhaps before deciding anything we could try and open a dialog with those channel owners...
22:42:29 <nirik> ask them what they want us to do...
22:42:58 <nirik> because if the use case doesn't make sense for epel being enabled, they may well not care about overlaps on specific targeted channels.
22:43:07 <stahnma> true
22:43:30 <dgilmore> nirik: i have started a dialog
22:43:38 * nirik is also not sure what makes a channel appear as a src.rpm download on ftp.redhat.com...
22:43:44 <nirik> dgilmore: cool. thanks.
22:43:49 <abadger1999> smooge: Errr --- wouldn't we start building with those layered products repos as part of our epel builder repos?
22:44:16 <abadger1999> (If we don't decided to exclude layered products from our no-overlap policy by default)
22:44:44 <smooge> abadger1999, we may not have access to them
22:44:47 <nirik> abadger1999: we could I suppose. Note that some of them also overlap with base os I think in some places.
22:45:04 <smooge> and our users wouldn't so if they could not download the repository would be broken for them
22:45:15 <abadger1999> smooge: If we don't have access ot them, then it seems like a bo brainer that we can't do a no-conflicts policy with them.
22:45:21 <abadger1999> *no brainer
22:45:46 <nirik> I think we could enable them. I'd just rather not.
22:45:53 <smooge> except their src.rpms are in the sub-trees we said we were going to not conflict with.
22:45:57 <abadger1999> smooge: yeah, there is that other aspect too :-)
22:46:02 <dgilmore> some of the layered products are designed to be standalone and you dont get support mixing and matching
22:46:12 <dgilmore> those we should not worry about
22:46:24 <nirik> so for example, we could drop mongodb because it overlaps, and add that channel so we could build against/use it, but that leaves all the epel consumers in the cold.
22:47:18 <dgilmore> nirik: down the road we may have a different answer
22:47:28 <dgilmore> not sure how much of it i can talk about
22:47:38 <nirik> ok.
22:47:57 <abadger1999> <nod> unless centos-plus pick it up or we decide to do a secondary repo ourselves... I don't know if centos-plus is intended to work with RHEL as well as with centos, though.
22:48:03 <nirik> in the mean time I don't know how much we want to decide today. I think we might want to collect more data...
22:48:49 <nirik> oh man, I just thought of something...
22:48:50 * abadger1999 is generally in favor of the proposal to restrict the products that we check for conflicts.
22:48:56 <stahnma> +1
22:49:18 <nirik> abadger1999: to base os/optional?
22:49:30 <stahnma> that's what seems logical to me
22:50:00 <abadger1999> nirik: that seems like a good semi-historical dividing line.   don't know if there's other sane dividing lines as well.
22:50:11 <abadger1999> or if we care to look for other possible lines :-)
22:50:21 <dgilmore> nirik: sounds ok to me.  what did you think of?
22:50:24 <nirik> well, in rhel5, we used "advanced platform" which was more stuff/channels.
22:51:22 <nirik> smooge: we also need to look at ppc64. ;)
22:51:34 <smooge> I did.. very few overlaps
22:51:37 <dgilmore> nirik: right but that doesnt exist in  el6
22:51:48 <nirik> smooge: xerces-c is one.
22:51:59 <dgilmore> a lot of layered products dont support ppc64
22:52:01 <nirik> it doesn't exist in rhel ppc64.
22:52:18 <nirik> sure, I am talking baseos/optional.
22:52:52 <dgilmore> right
22:53:21 <nirik> ok, so back to the question, do we want to vote on/or agree we have consensus on only avoiding conflict with base os/optional?
22:53:34 <nirik> or wait a week and get more feedback from channel owners, etc?
22:53:41 <stahnma> I like the proposal and will vote for it ;)
22:54:00 <dgilmore> i think baseos/optional ha/lb that we build against are good lines in the sand
22:54:10 <dgilmore> lets get some feedback
22:54:22 * nirik thinks there's at least one person on the list who will hate that, but hard to say. ;)
22:54:45 * nirik is fine with feedback for a week.
22:55:09 <dgilmore> nirik: afaik no one on the list are channel owners
22:55:11 <stahnma> is this the time we're using from now on?
22:55:17 <smooge> dgilmore, ha/lb?
22:55:22 <stahnma> I just note that our european friends probably hate this time...
22:55:26 <nirik> dgilmore: yeah.
22:55:38 <nirik> well, famsco apparently has the main meeting channel at this time.
22:55:45 <dgilmore> smooge: high availablinty and load balancing i believe,  they are what we use to populate the build roots
22:55:49 <nirik> I'm open to other times... wed and friday are mostly non meeting days for me...
22:56:07 <smooge> dgilmore, ah sorry was thinking half pound for some reason
22:56:09 * dgilmore would like to avoid fridays
22:56:18 <stahnma> arlight, discuss timing on list?
22:56:24 <dgilmore> probably best
22:56:26 * stahnma has a hard stop at top of the hour
22:56:31 <nirik> http://koji.fedoraproject.org/koji/taginfo?tagID=140
22:56:44 <nirik> we can... I got crickets last time I tried, but we can try again.
22:56:51 <nirik> #topic Open Floor
22:56:51 <dgilmore> stahnma: ok,  we should start to wrap up
22:57:00 <nirik> any open floor items or shall we close out?
22:57:17 * dgilmore has nothing
22:57:20 <smooge> has nothing.
22:57:23 * stahnma nothing
22:57:37 <nirik> ok, thanks for coming everyone!
22:57:40 <nirik> #endmeeting