epel
LOGS
16:03:36 <smooge> #startmeeting EPEL
16:03:36 <zodbot> Meeting started Mon Aug 23 16:03:36 2010 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:47 <smooge> #chair nirik
16:03:47 <zodbot> Current chairs: nirik smooge
16:03:57 <smooge> Good morning everyone
16:03:59 <nirik> morning
16:04:11 <smooge> #meetingname EPEL
16:04:11 <zodbot> The meeting name has been set to 'epel'
16:04:32 <smooge> anything else I need to do ... versus mailing out 6 months of log links?
16:05:11 <smooge> #topic Roll Call
16:05:14 <smooge> here
16:05:15 * nirik is here.
16:05:19 * sgallagh is here
16:05:23 <smooge> tremble, ?
16:05:30 <smooge> rdieter, ?
16:05:37 <smooge> stahnma, ?
16:06:04 <smooge> nirik you had a topic
16:07:00 <nirik> yeah, security updates. Currently epel allows them to push to stable directly. With fedora requiring time in testing first, do we wish to do the same? or keep allowing direct due to lack of testers?
16:08:45 <sgallagh> nirik: Given lack of testers, I'd suggest leaving it up to the packager. If they feel it needs time in testing, they'll keep it there.
16:09:11 <nirik> I just wanted to bring it up... I don't have a super strong feeling on it...
16:09:19 <smooge> I think it is a good idea, but agree with sgallagh that our testing regime is in the toilet
16:09:53 <nirik> do we have an agenda?
16:10:05 <smooge> no I am in the toilet too
16:10:26 <nirik> :(
16:10:44 <nirik> mondays are also difficult... (in so many ways. ;)
16:10:59 <smooge> Actually I don't remember having an agenda on Fridays either
16:11:08 <smooge> so here we go
16:11:10 <smooge> #topic Agenda
16:11:22 <smooge> 1) Change of Testing Criteria
16:11:42 <smooge> 2) Dealing with Broken Repoclosure
16:11:57 <smooge> 3) Rebooting EPEL
16:12:06 <smooge> done
16:12:19 <smooge> #topic Change of Testing Criteria
16:12:24 <sgallagh> smooge: Could we also discuss EPEL workstation vs. Server?
16:12:44 <smooge> Ok I will move that to 3 and 4 will be rebooting EPEL
16:13:22 <nirik> yeah, so not sure how much testing we have currently.
16:13:35 <smooge> I would like to propose that we mirror our testing requirements to that of Fedora and invite Fedora QA to use EPEL as a guinea pig for any and all new AutoQA methods
16:13:38 <nirik> I'd like to note that I worked with till and got fedora-easy-karma working on el5 at least. ;)
16:14:44 <smooge> cool
16:15:09 <smooge> I played with it but I have not done enough testing of new things. Most of the stuff in testing I don't use
16:16:11 <nirik> yeah, there are many niche things.
16:16:13 <sgallagh> smooge: While I agree with the sentiment, I'm not sure EPEL enjoys a large enough testing community to set those standards
16:16:41 <smooge> sgallagh, well I would like autoqa to deal with a lot of the things that we aren't covering because we don't have a large enough community
16:16:55 <smooge> or am I misunderstanding what autoqa does?
16:17:52 * abadger1999 sits in the bleachers
16:18:47 <smooge> in any case it is an idea. We can discuss it more on the list as we really only have 3 members in standing here :) [4 if we count the bleachers]
16:19:05 <sgallagh> smooge: I don't know enough about autoqa to answer that
16:19:05 <smooge> so lets go to the more important issue...
16:19:10 <smooge> ah ok
16:19:11 <sgallagh> Perhaps we could summon jlaska for input?
16:19:37 <smooge> how about I ask him for next meeting
16:19:44 <sgallagh> Sounds good
16:20:07 <smooge> #action smooge will ask jlaska to next meeting of mailing list to deal with autoqa question
16:20:20 <smooge> #topic Dealing with Broken Repoclosure
16:20:43 <smooge> ok so as Micheal pointed out.. EL4 has broken deps.
16:20:52 <nirik> yeah. ;(
16:21:01 <smooge> turns out it has quite a bit of broken deps though not as much as EL5
16:21:04 <nirik> it's hard to figure which are which tho checking against centos.
16:21:16 <smooge> I am running against EL4 i386 right now and will have a report to the list later today
16:21:36 <smooge> nirik what do you mean?
16:22:09 <nirik> centos has no ppc. Centos has no workstation vs server, we have server + "productivity" channel, etc.
16:22:21 <nirik> but ideally we should have everything sane vs centos too.
16:23:46 <nirik> what we may want to do is try and get a good list...
16:23:51 <nirik> make sure bugs are filed.
16:24:11 <nirik> then, go in and have a bug day and have provenpackagers fix up things that can easily be fixed.
16:24:18 <sgallagh> +1
16:24:23 <smooge> nirik, ok sounds good
16:24:37 <nirik> there are some I know that have bugs and haven't been ever fixed...
16:24:45 <nirik> we may have to look at just dropping some things too.
16:24:47 <smooge> we can remove those
16:25:16 <smooge> to be honest.. if its just 3-5 of us 'doing' things then we should cut down what we can 'deal' with
16:26:15 <smooge> I mean we really can't test PPC beyond the builders which we are shutting off after 12 goes EOL.
16:27:02 <nirik> well, perhaps we can get some qa types interested in helping... even basic testing and adding karma would be most welcome.
16:28:22 <smooge> yes hopefully
16:30:02 <smooge> ok anything else?
16:30:27 <smooge> #topic Server/Workstation (sgallagh)
16:31:01 <nirik> I talked with dgilmore about this...
16:31:14 <nirik> (if it's what I think it is)
16:31:42 <nirik> he's going to try and find out if RHEL6 server will have a 'productivity' channel like 5 does. If so we can just use that...
16:32:28 <sgallagh> nirik: Basically I was just referencing whether we had made a decision on what RHEL channels we were not permitted to override
16:32:42 <nirik> for 6, right?
16:32:45 <sgallagh> Server is obvious, optional is less so, and Workstation is just confusing
16:32:46 <sgallagh> Yes
16:33:08 <nirik> right, dgilmore is going to find out more... server + server optional are being used currently. So those are sure.
16:33:14 <sgallagh> ok
16:33:34 <nirik> I don't think we want to replace workstation / workstation optional... but we need some of it to build some things.
16:34:17 <nirik> we can't just include those, or we will end up shipping things that people on server can't install.
16:34:31 <nirik> so, ideally they will have a productivity channel like 5 does that lets us build things.
16:35:06 <sgallagh> Right, but if we ship the workstation packages, then people on Workstation can't use EPEL because the packages may conflict.
16:35:10 <sgallagh> So do we have two separate EPELs?
16:35:21 <nirik> thats another sad option.
16:35:26 <smooge> ah so thats the problem.. I have workstation/workstation-optional installed on mine
16:35:36 <nirik> I would like to avoid that...
16:35:41 <smooge> oh no we just build against CentOS because they will just have one channel
16:36:31 * smooge probably needs to drink from the company cooler again.. RH koolaid must be low
16:36:44 * nirik notes thats been suggested many times before, but never been workable.
16:37:49 <smooge> so are there conflicts between server/workstation? I mean if someone were to mix all the packages into one repo it would cause issues?
16:38:03 <smooge> I mean we had somehting similar with the 5 Server/Workstation until AP came around?
16:38:34 <nirik> I don't think there are conflicts so much as if we do that some things will require both to install/work.
16:38:35 <sgallagh> smooge: The problem there shouldn't be conflicts
16:38:57 <sgallagh> Yeah, what nirik said. People on one won't be able to install packages that rely on packages only available on the other
16:39:00 <sgallagh> that was unclear
16:39:17 <smooge> well yes. again we had this at the beginning of the RHEL5 didn't we?
16:39:21 <nirik> I think our action here is to wait and see if there is a productivity channel.
16:39:35 <sgallagh> nirik: What about asking for one?
16:39:39 <nirik> yes, and then there was a productivity channel for server that was free/easily available.
16:39:43 <sgallagh> Try to see if it can be included in the schedule
16:40:02 <nirik> sgallagh: I'm sure we can if they don't already plan one. I don't have any idea if they do currently.
16:40:37 <sgallagh> sounds like a question for dgregor *summons*
16:40:55 <nirik> sure, if you know someone to talk to, by all means. ;)
16:42:28 <nirik> perhaps ask out of band and we revisit next week?
16:42:32 <nirik> and move on for now?
16:42:39 <smooge> sounds like a good idea.
16:42:48 <sgallagh> Agreed
16:43:03 <smooge> #action sgallagh to perform dark incantations and get a EL6 knowledgable demon to answer questions
16:43:30 <smooge> #action nirik to get an intern for sacrifice
16:43:35 * sgallagh chuckles
16:43:38 <nirik> ha
16:44:37 <sgallagh> So: "Rebooting EPEL"?
16:44:48 <smooge> #topic Rebooting EPEL
16:45:06 <smooge> I am mostly bringing this up here for starting discussion on the list.
16:45:29 <smooge> a) our population has grown quite small
16:45:51 <smooge> b) our documentation hasn't been updated from Moin-Moin (my fault)
16:46:05 * dgregor reads up
16:46:17 <smooge> c) our packages aren't getting the testing we originally thought we would do
16:46:31 <dgregor> rhel6 workstation and server shouldn't conflict with each other except for the redhat-release-* packages
16:46:35 <smooge> Is it time to look at rebooting and seeing what we can do better by EL-6
16:46:48 <sgallagh> dgregor: Short version: will there be an optional repository for server customers to have access to workstation packages?
16:46:54 <nirik> smooge: well, sure, but how do we 'reboot' ?
16:47:05 <sgallagh> dgregor: Conflicts aren't our worry, it's missing packages from one or the other
16:47:26 <quaid> #idea Talk with Fedora Marketing about getting attention for more contributors
16:47:33 <smooge> delete all the wiki pages :), fire the leader, and get new staff.
16:47:44 <sgallagh> smooge: I thought we already did that :)
16:47:48 <sgallagh> (except the wiki)
16:47:52 <smooge> #idea Talk with Fedora Marketing about getting attention for more contributors
16:47:59 <dgregor> sgallagh, not like there is with rhel5.  there will be a rhel 6 server optional repo, but it will just be the build deps and subpackages of server that aren't in server itself.
16:48:23 <sgallagh> dgregor: Ok, so we're pretty much guaranteed to have to pick one or the other to use as our base, then
16:48:30 <dgregor> so the 'optional' repo in rhel 6 is not the same the "Optional Productivity Apps" channel in rhel 5 server
16:48:43 <quaid> also, EPEL is increasingly important to Red Hat's EL business, maybe there is something more to be done there.
16:48:49 * nirik plays the sad trombone.
16:49:09 <quaid> since they have the marketing reach in to the enterprise that Fedora doesn't
16:49:47 <sgallagh> nirik: So it sounds to me like we either have two EPELs, or we pick one (probably server) and live with shipping rebuilds of Workstation packages when necessary
16:49:47 <dgregor> sgallagh, have we looked to see how significant the diff is between workstation+optional and server+optional?
16:49:51 <smooge> dgregor, so sometime around EL-6.3 we will have an AP channel that mixes them all due to customer demand :)
16:49:55 * dgregor looks
16:50:34 <nirik> theres 2 tickets I know of currently from epel folks who can't build with just server/server-opt
16:50:40 <dgregor> smooge, perhaps.  that's how Optional Productivity Apps came about
16:50:44 <nirik> https://fedorahosted.org/rel-eng/ticket/3916
16:51:07 <nirik> https://fedorahosted.org/rel-eng/ticket/3906
16:52:20 <smooge> my guess will be the usual .. to build some server package we will need something in workstation because of a dependency issue.
16:52:52 <sgallagh> Yes, and as nirik has pointed out, we have existing examples already
16:53:25 <nirik> smooge: anyhow, I'm fine with the reboot idea, but I think we need some more people interested in rebooting before it would do anything.
16:53:27 <sgallagh> Personally, I'd lean toward EPEL being allowed to ship rebuilds of Workstation-only packages until and unless an AP channel appears
16:53:30 <dgilmore> dgregor:  the issue right now is we dont know what things will look like when rhel6 is final
16:53:42 <dgilmore> and we need to know that to know what is the best route to take
16:53:57 * nirik nods.
16:54:26 <quaid> smooge: I can't really drive it myself, but it would be at least a good exercise for some of us to come up with ways that Red Hat's relationships with customers could be used as a channel encourage participation in EPEL; they are already encouraging usage, but I don't think there is any message for e.g. GSS folk to use
16:54:37 <smooge> I remember that our last big "Well we might as well build against CentOS-5" was fixed by AP but beyond that I don't remember particulars
16:54:38 <quaid> in suggesting a customer e.g. maintain a package in EPEL v. roll their own all the time.
16:55:18 <quaid> so, a messaging index of sorts for RHT and RHT partner/SIs to use in encouraging EPEL _participation_
16:55:29 <nirik> yeah, that would be nice.
16:55:31 <smooge> well the issue in the past has been customers are happy with someone else maintaining it but really dont want to do it themselves
16:55:33 <quaid> and a big welcome sign over here.
16:55:45 <quaid> smooge: yes, 90%+ of them
16:55:51 <quaid> which is always  the case, anywhere :)
16:56:34 <quaid> RHT teams have brought plenty of EPEL users, if we give them something to use for messaging, we might get that to adjust a bit.
16:56:39 <smooge> yeah.. so I will be happy to welcome the 8% who are wanting to
16:57:02 <smooge> ok messaging as in "Use EPEL, it sucks, but less."
16:58:32 <smooge> ok sorry.. blood sugar running low
16:58:51 <smooge> I will send this to the list with quaid's ideas added on
16:58:59 <sgallagh> Sounds good
16:59:20 <smooge> nirik I need to get a protein drink .. could you handle for a few?
16:59:30 <nirik> sure, are we about done?
16:59:34 <nirik> #topic Open Floor
16:59:41 <nirik> anything else?
17:00:57 <nirik> will close out the meeting in a minute if nothing comes up.
17:01:49 <nirik> thanks for coming everyone!
17:01:53 <nirik> #endmeeting