12:02 p.m.
==================================
#fedora-meeting: EPEL (2012-06-08)
==================================
Meeting started by nirik at 16:00:52 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-08/epel.2012-06-0...
.
Meeting summary
---------------
* init process/agenda (nirik, 16:00:52)
* Broken Deps reports (nirik, 16:04:00)
* nirik to public broken dep script so people can review/hack on it
(maxamillion, 16:05:21)
* nirik to public broken dep script so people can review/hack on it
(maxamillion, 16:05:49)
* RHEL overlap policy (nirik, 16:06:27)
* LINK: http://koji.fedoraproject.org/koji/taginfo?tagID=140 (nirik,
16:14:32)
* LINK: http://fpaste.org/xAPF/ (nirik, 16:19:47)
* LINK: http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/*
(maxamillion, 16:28:20)
* LINK:
http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
(nirik, 16:42:22)
* proposals on list, further discussion. (nirik, 17:01:04)
* Open Floor (nirik, 17:01:10)
Meeting ended at 17:02:01 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (91)
* abadger1999 (30)
* maxamillion (27)
* smooge (20)
* zodbot (5)
* dgilmore (5)
* os_ (4)
* cobra-the-joker (4)
* strace (3)
* Jeff_S (1)
* tremble (0)
--
16:00:52 <nirik> #startmeeting EPEL (2012-06-08)
16:00:52 <zodbot> Meeting started Fri Jun 8 16:00:52 2012 UTC. The chair is nirik.
Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:52 <nirik> #meetingname epel
16:00:52 <zodbot> The meeting name has been set to 'epel'
16:00:52 <nirik> #topic init process/agenda
16:00:52 <nirik> #chair smooge tremble dgilmore
16:00:52 <nirik> EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge
nb maxamillion tremble Jeff_S HackMan
16:00:52 <zodbot> Current chairs: dgilmore nirik smooge tremble
16:00:53 * nirik looks at zodbot.
16:01:06 <smooge> here here here
16:01:24 * maxamillion is here
16:02:19 <dgilmore> hi
16:02:36 <cobra-the-joker> HERE !
16:02:46 * nirik waits a few more for folks to arrive.
16:03:51 <nirik> ok, lets go ahead and dive in then...
16:04:00 <nirik> #topic Broken Deps reports
16:04:19 <nirik> I meant to publish the basic script I had so people could work on
it.
16:04:28 <nirik> but I failed. I will do so after the meeting. ;)
16:05:14 <nirik> Basically I have a script that works for epel6, it needs reworking
so it could work for epel6+testing and epel5/epel5+testing...
16:05:21 <maxamillion> #info nirik to public broken dep script so people can
review/hack on it
16:05:29 <maxamillion> oh wait, that's a chair thing isn't it?
16:05:37 <nirik> if someone can get it all set, I can add it to puppet, etc.
16:05:39 <nirik> maxamillion: yeah.
16:05:41 <nirik> #chair maxamillion
16:05:41 <zodbot> Current chairs: dgilmore maxamillion nirik smooge tremble
16:05:47 <maxamillion> oh goodness
16:05:49 <maxamillion> #info nirik to public broken dep script so people can
review/hack on it
16:06:11 <nirik> ok, any questions there? if not, moving on...
16:06:24 * abadger1999 here
16:06:27 <nirik> #topic RHEL overlap policy
16:06:30 * Jeff_S here for one minute then need to run.
16:06:46 <nirik> so, we talked last time about a new policy, and there's been
tons of discussion on list.
16:06:58 <nirik> Does anyone have any wording to propose? or further discussion to
make on it?
16:07:28 <cobra-the-joker> everyone is sleepy o_0
16:07:38 <smooge> I believe the wording we had last time to cover just stuff under 6
basic is all that is needed
16:07:40 <nirik> yeah, I don't blame them. ;)
16:07:51 <maxamillion> smooge: +1
16:08:41 <nirik> what was that wording? because I want an actual thing we can look
at. ;)
16:09:29 * nirik looks
16:10:08 <nirik> "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."
16:10:14 <smooge> <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.
16:11:06 <os_> cobra-the-joker, noy me
16:11:09 <os_> cobra-the-joker, not me
16:11:24 <cobra-the-joker> ؟!
16:11:34 <os_> <cobra-the-joker> everyone is sleepy o_0
16:11:38 <smooge> os_, please stay on topic here
16:11:40 <nirik> so, where does that leave the lb and ha channels? we currently use
them in our build repo...
16:11:41 <cobra-the-joker> aha
16:11:44 <os_> sorry
16:12:09 <smooge> I think we need to see what gets pulled because of that
16:12:23 <nirik> and it leaves our users kind of unsure which channel is in what
state... overlap ok, not ok, changed from ok to not ok... etc
16:13:20 <smooge> nirik, my main questions would be: Does CentOS/SciLin ship those
rpms and does a basic subscription get those channels?
16:13:30 <nirik> I'd guess we would need a table on the wiki with that info...
16:13:47 <nirik> I think the answer is no, and yes.
16:13:56 <nirik> but I would have to look to be sure.
16:14:07 <abadger1999> smooge: and, can we use them in our buildsystem.
16:14:25 <nirik> abadger1999: we do currently.
16:14:32 <nirik> http://koji.fedoraproject.org/koji/taginfo?tagID=140
16:14:41 <nirik> server, optional, lb and ha
16:14:47 <abadger1999> yeah. true for those channels. I wasn't sure if
smooge's quesetions were more broad.
16:15:29 <nirik> I think it's completely impractical/impossible for us to just
enable all channels. Some channels conflict with each other.
16:15:41 <dgilmore> nirik: right
16:15:55 <dgilmore> and some ship different versions of the same thing
16:15:59 <nirik> or at least both provide different versions of the same package.
16:16:06 <smooge> Well if a basic subscription gives those channels then we should
go with that. If it doesn't then we shouldn't.
16:16:07 <dgilmore> that could in theory have different sonames etc
16:16:15 * nirik nods.
16:16:20 <maxamillion> smooge: +1
16:16:28 <abadger1999> <nod> Which for me means we should either always allow
overlap with those channels or pick one and allow overlap with the other because of the
conflict.
16:16:42 <nirik> I have no idea off hand what a basic subscription provides channel
wise.
16:16:51 <maxamillion> lemme look
16:16:58 <abadger1999> smooge: I like that position.
16:17:24 <strace> smooge: +1
16:17:29 <nirik> so that would be 'no overlap with channels in a basic
subscription' ?
16:18:26 <maxamillion> crap, RHN changed ... I can't find anything
16:18:31 <strace> Actually, how are we defining "basic subscription"? Just
RHEL Server or are we defining it as RHEL Desktop?
16:18:33 <smooge> yeah.. the question is how can we get a basic supscription
16:19:00 <nirik> strace: server I assume, thats what we build against.
16:19:06 <strace> ok
16:19:23 <maxamillion> I would think either server or workstation
16:19:33 <maxamillion> probably server though
16:19:47 <nirik> http://fpaste.org/xAPF/
16:20:33 * nirik thinks this is getting too complex again.
16:21:02 <maxamillion> I say we do Server and Optional
16:21:15 <maxamillion> because I think we require Optional anyways don't we?
16:21:21 <nirik> pulling ha and lb would probibly nuke a number of things. I know it
will kill heartbeat.
16:22:00 <smooge> Well in that case, could we go with the "we will rebuild with
source from channel but at a NVR less than in channel?"
16:22:30 <maxamillion> I feel like that would be a pain to maintain
16:22:34 <nirik> we can, but thats a gigantic pain.
16:22:43 <nirik> I suspect many of the packages we have doing that now are doing it
wrong.
16:22:56 <smooge> yeah probably
16:23:24 <smooge> sigh. I propose we end EPEL and let someone else handle this.
16:23:57 <smooge> not too seriously.
16:24:41 <nirik> well, I think any plan we come up with may make some people
unhappy, but such is life I fear.
16:25:14 <maxamillion> +1
16:25:37 <maxamillion> can't always satisfy everyone and no matter what,
someone's going to complain
16:25:57 <nirik> I guess I am leaning toward: No overlap with os/optional. No
overlap with lb or ha (current list, will add channels as requested). Arch exceptions
allowed for any overlaps.
16:26:19 <nirik> then when we add a channel on request for no overlaps, we add it to
the buildsys and check it then for overlaping.
16:26:27 <abadger1999> How many packages are in ha and lb? How many important ones
are?
16:26:29 <nirik> but I don't know if channel owners are going to know to request
that.
16:26:47 * nirik looks
16:26:58 <abadger1999> It's possible that we can get those into EPEL.
16:27:36 <nirik> which? all the lb/ha contents?
16:28:01 <maxamillion> we could always say "we don't overlap with anything
in http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/ and if you need something
there, just pay for it" ... I feel like that would simplify things (but likely upset
some folks)
16:28:18 <maxamillion> erm
16:28:20 <maxamillion> http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/*
16:28:26 <maxamillion> asterisk is important ;)
16:29:15 <nirik> maxamillion: that would result in a large drop in epel packages.
16:29:30 <smooge> like over half
16:29:51 <maxamillion> it would make things more simple though ... didn't say it
was the greatest suggestion in the world
16:30:16 <abadger1999> maxamillion: Just started browsing and already spotted
conflicts there.
16:30:18 <nirik> maxamillion: well, it would make things more simple for end
consumers, it would be a nightmare on the rel-eng side.
16:30:18 <maxamillion> I'm just throwing ideas out there and I'm open to
others ... certainly not married to any of them
16:30:29 <maxamillion> nirik: oh?
16:30:31 <nirik> yeah, there's not a great answer here.
16:30:35 <abadger1999> CloudForms has a different mod_wsgi package from os
16:30:47 <nirik> and a different puppet from epel
16:30:48 <maxamillion> abadger1999: heh, of course it does
16:31:48 <abadger1999> nirik: yeah, all the lb/ha content
16:33:00 <maxamillion> so is LB/HA considered wide spread enough that we don't
want to conflict with it because it would impact a large enough user base that it could be
problematic where as other additional subscription channels are a bit more niche or
aren't likely candidate deployments for adding in EPEL? (just trying to clarify for
myself)
16:33:13 <nirik> since the channels are so different, I don't think we are going
to get one size fits all here.
16:33:50 <nirik> maxamillion: yeah, I would agree with that. Base sub allows you to
use lb and ha... and they have many popular packages for rhel.
16:34:34 <abadger1999> <nod>
16:34:59 * abadger1999 looks at the list of what's available with base sub again
16:35:14 <nirik> there's some more than I pasted... there's beta ones.
16:35:26 <nirik> but I don't think those should count.
16:36:16 <nirik> lb has 3 packages in it.
16:36:34 <nirik> ha has 158
16:37:00 <abadger1999> Additional channels are: Resilient Storage, Supplementary
V2VWin RHN Tools for RHEL, RH Ent Virt Agent, FasTrack (which is a different
"type" of channel?)
16:37:20 <nirik> yeah, fastrack is different.
16:39:36 <nirik> so, anyone want to push a proposal? or shall we try and ponder on
it more?
16:40:21 <smooge> Well I think status quo works best.
16:40:32 <maxamillion> "status quo" ?
16:40:45 <smooge> ServerOS, LB, HA
16:40:46 <nirik> I guess I will put forth:
16:40:49 <maxamillion> smooge: +1
16:41:15 <abadger1999> nirik: What was "Arch exceptions allowed for any
overlaps" above?
16:41:50 * abadger1999 has some wording but would like to incorporate that idea as well.
16:41:58 <nirik> EPEL6 will not conflict with os and optional. Addtionally, it will
not conflict with: lb, ha (this list subject to additions). Arch overlaps allowed when
there's overlaping.
16:42:05 <nirik> abadger1999: let me get a link, just a sec.
16:42:22 <nirik> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
16:42:37 <abadger1999> <nod> k
16:43:13 * nirik notes that inode0 didn't like per channel exceptions as it seemed
potentitally confusing to end users, but I'm not sure how to avoid it.
16:43:52 <abadger1999> How about changing your "this list subject to additions)
to: (this list subject to additions available to a base subscription where the channels do
not conflict with each other, os, or optional)
16:44:44 <nirik> hum, that reads more confusing to me. what does that get us?
16:44:56 * abadger1999 works on the language some
16:45:04 <abadger1999> it gets us a better set of expectations.
16:45:54 <nirik> I see that ha and rs have overlapping packages...
16:45:57 <smooge> does "Overlaps are allowed in arches that do not ship
packages in those channels." work better for the second sentence?
16:46:07 <nirik> at least from a quick glance, cluster-glue is shipped in both
16:46:10 <abadger1999> rather than Oh, someone asked that we add this random channel
so we should add it and cause disruption to users, it limits the set of channels that
could potentially be added.
16:46:21 <nirik> ah, I see...
16:46:38 <nirik> so if we got some other channel telling us not to overlap, we could
say sorry/
16:47:56 <abadger1999> yeah.
16:48:16 * nirik doesn't want to cause problems for other channels... you would think
they would have a good reason for asking us not to overlap.
16:50:22 <abadger1999> EPEL6 will not conflict with os, optional and certain
channels available to a Base Subscription. Currently, those channels are lb and ha but
other base subscription channels may be added if they do not conflict with os and
optional. Overlaps are allowed to resolve packages missing on a specific arch according
to [link].
16:51:06 <abadger1999> that doesn't quite capture things like conflict between
ha and rs... hmmm...
16:51:12 <nirik> yeah.
16:51:18 <nirik> I think we need to be more generic.
16:52:00 <smooge> EPEL6 will not conflict with os, optional and certain channels
available to a Base Subscription. People who have a problem with this are to see Dennis
Gilmore in Blind Dark Alley.
16:52:40 <nirik> EPEL6 will not conflict with os, optional and specific other RHEL
channels. Currently those are lb and ha. Other channels may be added on a case by case
basis. Overlaps are allowed to resolve packages missing on specific arches according to
<link>
16:52:47 <nirik> smooge: +1
16:53:33 <abadger1999> So... od we all agree on the idea of limiting additional
channels to (1) no conflicts with the channels already in the buildroot. (2) available to
a base subscription?
16:53:36 <abadger1999> *do
16:53:46 <smooge> I do
16:53:48 <nirik> dgilmore: you've been trying to talk with channel owners? How
possible is it to find out who owns a channel and communicate with them about this?
16:54:16 <dgilmore> nirik: so far ive not gotten very far
16:54:16 <nirik> abadger1999: I'm not sure about the base subscription thing...
16:54:50 <nirik> I guess the idea is that people with more niche subscriptions would
know better how to deal with conflicts/overlaps?
16:55:44 <nirik> but I can think of cases where channel foo ships package bar thats
also in epel, and a different version and it's causing them support problems with
people overlaping and they ask us to remove bar...
16:56:19 * nirik notes we are coming up on an hour now.
16:56:31 <abadger1999> I was thinking more of the "can contributors still build
and run the packages" aspect.
16:56:58 <abadger1999> a base subscription seems like a reasonable line to draw
there.
16:57:19 <nirik> yeah, true.
16:57:42 <abadger1999> that said, I feel no conflicts is a blocker for me.
16:57:52 <nirik> yeah.
16:58:02 <abadger1999> base subscription would be very nice, but I could live
without it.
16:58:09 <nirik> for example the cluster-glue in ha and rs is the exact same
version... does that mean they keep in sync? no idea.
16:58:38 <abadger1999> yeah.
16:59:52 <nirik> so, where shall we go here? proposals on list? more thoughts?
different meeting time? ;)
17:00:10 <smooge> I think this time as good as it gets at the moment
17:00:22 <smooge> proposals on list with vote next week
17:00:57 <nirik> ok.
17:01:04 <nirik> #info proposals on list, further discussion.
17:01:10 <nirik> #topic Open Floor
17:01:15 <nirik> anything for open floor real quick?
17:01:50 <nirik> ok, will close out in a minute then.
17:01:53 <nirik> thanks for coming everyone.
17:02:01 <nirik> #endmeeting