16:00:36 <smooge> #startmeeting EPEL
16:00:36 <zodbot> Meeting started Fri Oct  3 16:00:36 2014 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:36 <smooge> #meetingname epel
16:00:36 <smooge> #chairs smooge nirik Evolution bstinson dgilmore
16:00:36 <smooge> #topic Greetings and roll call
16:00:37 <zodbot> The meeting name has been set to 'epel'
16:00:57 <bstinson> hi all
16:01:16 <smooge> hi bstinson
16:01:17 * nirik is here
16:01:30 <smooge> dgilmore, is on PTO and out today
16:01:41 <kushal> I am also here (just to read mostly).
16:01:59 <smooge> Evolution, is drinking bourbon and mylanta somewhere
16:02:11 <smooge> hello kushal
16:02:12 <nirik> ha. short meeting then? :)
16:02:22 <smooge> yep.
16:03:30 <smooge> #info we have bare quorum. for anything to be approved all members need to be in agreement with absent members considered -1. We can put off any votes as needed til better quorum is met
16:04:07 <smooge> #topic Old Business?
16:04:37 <smooge> I don't think we have any old business to discuss. I don't have any notes of outstanding items. Anything put off from this meeting will be old business next meeting I think.
16:04:53 <smooge> bstinson, nirik youy have anything outstanding I forgot?
16:04:58 <bstinson> agreed, nothing here
16:04:59 <nirik> not off hand.
16:05:29 <smooge> #topic Current Business (Open Tickets)
16:06:01 <smooge> I wish there was a #subtopic but that is probably too OCD
16:06:04 <smooge> #topic ticket 2 How to handle systemd service activation defaults in EPEL7
16:06:04 <smooge> #url https://fedorahosted.org/epel/ticket/2
16:06:13 <smooge> #topic ticket 2 How to handle systemd service activation defaults in EPEL7
16:06:18 <smooge> #url https://fedorahosted.org/epel/ticket/2
16:06:28 <nirik> so, on this I think we will have to make a presets package, and have epel-release depend on that...
16:06:36 <nirik> adding it to epel-release and changing that all the time is bad.
16:06:52 <smooge> agreed.
16:06:54 <bstinson> +1
16:07:19 <smooge> who normally writes such packages? release engineering (or our equiv here?)
16:07:28 <nirik> yeah, I can try and work on it...
16:07:36 <nirik> I need to look at the fedora setup to make sure that makes sense.
16:08:10 <smooge> ok do you think it would help if two of us got together to work on it. I am wanting to lower your and dgilmore's overall work load. not add to it.
16:08:52 <smooge> if it is more of a one person thing, I understand.. can't have too many cooks on the soup at times
16:08:55 <nirik> sure. also, it will need review.
16:09:05 <nirik> so I could make it and you could review?
16:09:10 <bstinson> what is/will be the policy for adding services to this package?
16:09:21 <bstinson> just open a ticket?
16:09:45 <smooge> I would expect we would open a ticket, it would be reviewed in same way that Fesco monitors that package (if at all) and then added.
16:09:54 <smooge> or not with reasons given.
16:11:00 <smooge> #agreeed will use a subpackage called presets that epel-release will depend on in EL7. This will set up various needed items for systemd. Package to be written by nirik, reviewed by smooge.
16:11:05 <smooge> #agreed will use a subpackage called presets that epel-release will depend on in EL7. This will set up various needed items for systemd. Package to be written by nirik, reviewed by smooge.
16:11:12 <nirik> bstinson: yeah
16:11:33 <smooge> does that sound good for you bstinson ?
16:11:37 <bstinson> i like it
16:12:33 <smooge> #agreed additions and removals are to be added via a ticket to the epel trac. Tickets will be reviewed and approved/dropped by EpSCO and package done.
16:12:41 <smooge> ok I think that is all on this ticket.
16:13:12 <smooge> #topic ticket 4 Decide on criteria to unretire packages.
16:13:12 <smooge> #url https://fedorahosted.org/epel/ticket/4
16:13:51 <nirik> perhaps we should punt this to next week when we have more quorum?
16:14:23 <smooge> bstinson, ?
16:14:30 <bstinson> i agree to pushing this off
16:15:03 <smooge> #agreed Need larger quorum to discuss and come up with policy. Moved to 2014-10-10 meeting
16:15:05 <bstinson> i am definitely in favor of expediting that process if we can, but we should discuss it
16:15:39 <smooge> #topic New Business
16:15:50 * stahnma arrives late
16:15:56 <smooge> #topic Review of xerces-c package
16:16:37 <smooge> Ok since we aren't going to have an expedited process yet.. can someone take a look at the xerces-c package for a re-review?
16:16:48 <nirik> it's been filed? or ?
16:17:00 * stahnma reads the scrollback
16:17:10 <stahnma> having epel-release depend on something seems really strange
16:17:20 * ktdreyer agrees
16:17:25 <stahnma> for all cases of all other repos I know of, you just need the -release rpm and you can go
16:17:31 <stahnma> most people don't use yum to install it
16:17:38 <ktdreyer> it's kind of a bummer to have to change a lot of kickstarts that install one epel-release RPM
16:17:39 <stahnma> so it won't do dep resolution
16:17:47 <nirik> true...
16:17:49 <stahnma> they wget; rpm -Uvh...
16:17:50 <smooge> stahnma, well sadly we would end up with release of the week
16:17:59 <nirik> better ideas welcome.
16:18:08 <nirik> I don't want to bump it all the time tho just to change presets
16:18:09 * stahnma reads the ticket in an attempt to understand the issue
16:18:12 <ktdreyer> does it *have* to be a dep of epel-release?
16:18:16 <nirik> no.
16:18:21 <nirik> that was just an idea
16:18:56 <ktdreyer> my preference would be to just have it available in the repo
16:19:01 <smooge> the problem will be that if it isn't you either end up updating epel-release every package or every package is going to have to depend on it int eh repo
16:19:19 <nirik> ktdreyer: then packages with presets would have problems.
16:19:30 <smooge> well every package with systemd presets
16:19:44 <nirik> well, and a dep there wouldn't make sense.
16:19:52 <ktdreyer> problems, as in, they just wouldn't start on boot?
16:19:55 <stahnma> so just to make sure I understand this, the idea is that if a package ships a service, it can be enabled assuming it's not network based. But to do that, it has to checkin with a known good look-aside cache for what is actually allowed to run on boot?
16:20:01 <nirik> presets are meant to be overridable... so if someone had a local set of them they should be able to use that
16:20:25 <stahnma> why can't the original packager just decide if it meets enablement criteria
16:20:28 <nirik> ktdreyer: right
16:20:32 <stahnma> rather than having a dep on a second package
16:20:37 <stahnma> or am I missing something
16:20:59 <stahnma> (I haven't done lots of service packaging with systemd according to guildelines yet)
16:21:04 <nirik> stahnma: they could... but then presets wouldn't enter in... so if someone wanted to ship a thing with that service off... it would ignore the preset and always be on
16:21:16 <nirik> I suppose we could just say no presets in epel.
16:21:35 <stahnma> That feels more like the EL ecosystem to me
16:21:41 <stahnma> it allows full control to the SA
16:21:43 <ktdreyer> I lean in that direction too
16:22:19 <nirik> it would be a difference that fedora packagers would have to add to specs... but yeah...
16:22:33 <nirik> perhaps we propose that and ask for more feedback on list/ticket/
16:22:50 <stahnma> Could somebody post what the actual packaging differences would be ?
16:22:56 <stahnma> because I'm not sure I understand it yet.
16:23:03 <stahnma> I just really don't want a dep on epel-release
16:23:05 * smooge stahnma could you ask that in the ticket
16:23:07 <stahnma> it will break so many workflows
16:23:09 <stahnma> sure
16:23:28 <smooge> ok #topic back to ticket 2
16:23:57 <smooge> bstinson, nirik with feedback from people.. do you want to revisit our agreement and say we need further info on this?
16:23:58 <nirik> stahnma: the difference in the spec would be between a call to systemd_preset or systemctl enable I guess
16:24:09 <nirik> smooge: sure, I'm happy to gather further feedbac
16:24:14 <stahnma> that's pretty simple :)
16:24:15 <bstinson> i'm ok with re-opening
16:24:33 <smooge> #agreed skip the earlier agreement. we need more info.
16:25:34 <smooge> ktdreyer, stahnma anything else you want to add on ticket 2?
16:25:46 <stahnma> Yeah, updating the ticket now
16:26:03 <smooge> if you do could you add it to the ticket so the sender knows what questions they are looking for?
16:26:29 <smooge> #topic RHEL-5.11/CentOS-5.11
16:27:05 <smooge> It looks like CentOS did its rebuilds of 5.11 this last week. Scientific Linux is still working on theirs I believe.
16:28:05 <smooge> I would like to say that if anyone needs to put in major changes to EL-5 package sets this may be a good time to announce them and we can review and deal with the outrage.
16:28:13 <nirik> yeah, don't think there's anything for us to do here is there?
16:28:22 <smooge> wow.. that was exceedingly tentative on my part.
16:28:23 <nirik> does this move 5.x into 'no new packages' ?
16:28:34 <stahnma> smooge: where would we put that annoucement out?
16:28:39 <stahnma> to epel-announce?
16:28:41 <stahnma> or epel-devel?
16:28:43 <stahnma> or both>
16:28:47 <smooge> stahnma, epel-devel, epel-announce, epel-users
16:28:51 * stahnma has some ruby crap to get updated
16:29:04 <stahnma> thanks
16:29:22 <smooge> epel-users needs the traffic
16:29:37 <stahnma> ok
16:29:45 <smooge> put in a ticket for what you are wanting to do a large update/change for so we can dot t's and cross i's
16:29:52 <stahnma> ok
16:30:14 <smooge> just one ticket for the entire changeset since I wasn't clear :). [Not one for each package.]
16:30:21 <stahnma> gotcha
16:31:12 <smooge> nirik, I think we should have a date for that. Say 6-9 months from now? Then no new packages without review of why and only retirements and removals.
16:31:50 <nirik> I think we were thinking of following rhel lifecycle... let me see if I can find the doc
16:32:31 <smooge> ah I remember then.. that was before they added extra innings and various other things
16:33:03 <smooge> my reason for looking at 5-6 months from now is just in case we have a 5.12
16:34:06 <nirik> https://access.redhat.com/support/policy/updates/errata/
16:34:58 <nirik> end of phase 2 was jan 2014... we are in phase 3 on 5 now
16:35:23 <nirik> so, I guess we could say cut things off sometime before 2017
16:35:30 <nirik> (for new packages)
16:35:53 <smooge> ok sounds good
16:36:47 <smooge> OK looking at the other topics I had on the agenda.. I don't have anything for them. so everyone for going to open flood next?
16:37:09 <bstinson> +1 here
16:37:20 <smooge> #topic Open Flood
16:37:53 <avij> would it be possible to change the mailing list identifier of epel-devel from EPEL to [EPEL] ? That would fix the annoyance of the mailing list software stripping EPEL from subject lines.
16:38:08 <ush> this may be more a kernel.org or centos Q than an EPEL Q, but can I reasonably expect that the epel-release package in  http://mirrors.kernel.org/centos/7/extras/x86_64/Packages/ will have the same version as that in http://mirrors.kernel.org/fedora-epel/7/x86_64/e/ ?
16:38:15 <smooge> Alright people in the audience, anything that EpSCO needs to hear about? [If we miss you please open a ticket in https://fedorahosted.org/epel
16:38:47 <smooge> ush, no there is no expectation they will be the same.
16:39:03 <smooge> ush, however an instlal of that and then a yum update should bring them in line.
16:39:32 <smooge> avij, I will look at that after this meeting. Thanks
16:39:47 <ush> smooge: Thank you.  That's what I guessed.
16:40:06 <smooge> anything else?
16:40:36 * nirik has nada
16:40:39 <tyll> I have something
16:40:40 <avij> ush: it should be the same, but there are no guarantees. centos does not intentionally change that package.
16:41:00 <smooge> tyll, what is it?
16:41:07 <ush> avij: ack
16:41:18 <avij> ush: (apart from re-signing, that is)
16:41:33 <tyll> For Fedora it was decided to retired packages after they were orphaned for 6 weeks and this was reported every week - this is not yet happening, but if I have the tooling ready, is it ok to do the same for EPEL?
16:42:54 <nirik> tyll: I'd be in favor, although we should produce a list of affected packages and wait a few weeks so people know to take them if they care about them.
16:43:52 <smooge> tyll, actually that sounds like a good idea, but I think we need to have that as a formal discussion item with the rest of the group. Could you put in a ticket and maybe a "hey this is what will be retired and what will break because of it?"
16:44:03 <smooge> the second is very very optional :)
16:44:24 <smooge> and I would be in favour as I don't like zombie packages
16:45:25 <bstinson> +1
16:45:30 <tyll> The general idea is to make weekly reports about orphaned packages and then retire them if they were reported six weeks
16:45:39 <tyll> But I can open a ticket off course
16:46:22 <nirik> yeah, but the initial pile of package that are orphaned more than 6 weeks is likely to be both large and might have some people didn't realize are orphaned and they want to take oevr.
16:47:02 <bstinson> can we start the weekly reports to the list and tackle the "when to start orphaning" question at a meeting?
16:47:44 <nirik> works for me
16:48:08 <smooge> bstinson, works for me also. tyll do you need help with setting up where such a script should live/work?
16:49:10 <tyll> I will ask for this when the script is ready and I can use a releng system to develop it
16:49:57 <smooge> cool
16:50:12 <smooge> I will actually open the ticket on this as you have already done a heck of a lot :)
16:50:31 <tyll> thank you
16:50:50 <smooge> is there anything else on this?
16:51:01 <smooge> or other open flood items?
16:51:15 <smooge> I will close out the meeting in 1 minute otherwise
16:51:22 <tyll> not from me
16:51:34 <bstinson> none here
16:52:26 <nirik> php-horde-Horde-Pack-1.0.4-1.el6 not tagged as testing
16:52:35 <nirik> wonder if it was a race?
16:52:55 <smooge> #endmeeting