16:00:36 #startmeeting EPEL 16:00:36 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:36 #meetingname epel 16:00:36 #chairs smooge nirik Evolution bstinson dgilmore 16:00:36 #topic Greetings and roll call 16:00:37 The meeting name has been set to 'epel' 16:00:57 hi all 16:01:16 hi bstinson 16:01:17 * nirik is here 16:01:30 dgilmore, is on PTO and out today 16:01:41 I am also here (just to read mostly). 16:01:59 Evolution, is drinking bourbon and mylanta somewhere 16:02:11 hello kushal 16:02:12 ha. short meeting then? :) 16:02:22 yep. 16:03:30 #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 #topic Old Business? 16:04:37 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 bstinson, nirik youy have anything outstanding I forgot? 16:04:58 agreed, nothing here 16:04:59 not off hand. 16:05:29 #topic Current Business (Open Tickets) 16:06:01 I wish there was a #subtopic but that is probably too OCD 16:06:04 #topic ticket 2 How to handle systemd service activation defaults in EPEL7 16:06:04 #url https://fedorahosted.org/epel/ticket/2 16:06:13 #topic ticket 2 How to handle systemd service activation defaults in EPEL7 16:06:18 #url https://fedorahosted.org/epel/ticket/2 16:06:28 so, on this I think we will have to make a presets package, and have epel-release depend on that... 16:06:36 adding it to epel-release and changing that all the time is bad. 16:06:52 agreed. 16:06:54 +1 16:07:19 who normally writes such packages? release engineering (or our equiv here?) 16:07:28 yeah, I can try and work on it... 16:07:36 I need to look at the fedora setup to make sure that makes sense. 16:08:10 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 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 sure. also, it will need review. 16:09:05 so I could make it and you could review? 16:09:10 what is/will be the policy for adding services to this package? 16:09:21 just open a ticket? 16:09:45 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 or not with reasons given. 16:11:00 #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 #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 bstinson: yeah 16:11:33 does that sound good for you bstinson ? 16:11:37 i like it 16:12:33 #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 ok I think that is all on this ticket. 16:13:12 #topic ticket 4 Decide on criteria to unretire packages. 16:13:12 #url https://fedorahosted.org/epel/ticket/4 16:13:51 perhaps we should punt this to next week when we have more quorum? 16:14:23 bstinson, ? 16:14:30 i agree to pushing this off 16:15:03 #agreed Need larger quorum to discuss and come up with policy. Moved to 2014-10-10 meeting 16:15:05 i am definitely in favor of expediting that process if we can, but we should discuss it 16:15:39 #topic New Business 16:15:50 * stahnma arrives late 16:15:56 #topic Review of xerces-c package 16:16:37 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 it's been filed? or ? 16:17:00 * stahnma reads the scrollback 16:17:10 having epel-release depend on something seems really strange 16:17:20 * ktdreyer agrees 16:17:25 for all cases of all other repos I know of, you just need the -release rpm and you can go 16:17:31 most people don't use yum to install it 16:17:38 it's kind of a bummer to have to change a lot of kickstarts that install one epel-release RPM 16:17:39 so it won't do dep resolution 16:17:47 true... 16:17:49 they wget; rpm -Uvh... 16:17:50 stahnma, well sadly we would end up with release of the week 16:17:59 better ideas welcome. 16:18:08 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 does it *have* to be a dep of epel-release? 16:18:16 no. 16:18:21 that was just an idea 16:18:56 my preference would be to just have it available in the repo 16:19:01 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 ktdreyer: then packages with presets would have problems. 16:19:30 well every package with systemd presets 16:19:44 well, and a dep there wouldn't make sense. 16:19:52 problems, as in, they just wouldn't start on boot? 16:19:55 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 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 why can't the original packager just decide if it meets enablement criteria 16:20:28 ktdreyer: right 16:20:32 rather than having a dep on a second package 16:20:37 or am I missing something 16:20:59 (I haven't done lots of service packaging with systemd according to guildelines yet) 16:21:04 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 I suppose we could just say no presets in epel. 16:21:35 That feels more like the EL ecosystem to me 16:21:41 it allows full control to the SA 16:21:43 I lean in that direction too 16:22:19 it would be a difference that fedora packagers would have to add to specs... but yeah... 16:22:33 perhaps we propose that and ask for more feedback on list/ticket/ 16:22:50 Could somebody post what the actual packaging differences would be ? 16:22:56 because I'm not sure I understand it yet. 16:23:03 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 it will break so many workflows 16:23:09 sure 16:23:28 ok #topic back to ticket 2 16:23:57 bstinson, nirik with feedback from people.. do you want to revisit our agreement and say we need further info on this? 16:23:58 stahnma: the difference in the spec would be between a call to systemd_preset or systemctl enable I guess 16:24:09 smooge: sure, I'm happy to gather further feedbac 16:24:14 that's pretty simple :) 16:24:15 i'm ok with re-opening 16:24:33 #agreed skip the earlier agreement. we need more info. 16:25:34 ktdreyer, stahnma anything else you want to add on ticket 2? 16:25:46 Yeah, updating the ticket now 16:26:03 if you do could you add it to the ticket so the sender knows what questions they are looking for? 16:26:29 #topic RHEL-5.11/CentOS-5.11 16:27:05 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 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 yeah, don't think there's anything for us to do here is there? 16:28:22 wow.. that was exceedingly tentative on my part. 16:28:23 does this move 5.x into 'no new packages' ? 16:28:34 smooge: where would we put that annoucement out? 16:28:39 to epel-announce? 16:28:41 or epel-devel? 16:28:43 or both> 16:28:47 stahnma, epel-devel, epel-announce, epel-users 16:28:51 * stahnma has some ruby crap to get updated 16:29:04 thanks 16:29:22 epel-users needs the traffic 16:29:37 ok 16:29:45 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 ok 16:30:14 just one ticket for the entire changeset since I wasn't clear :). [Not one for each package.] 16:30:21 gotcha 16:31:12 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 I think we were thinking of following rhel lifecycle... let me see if I can find the doc 16:32:31 ah I remember then.. that was before they added extra innings and various other things 16:33:03 my reason for looking at 5-6 months from now is just in case we have a 5.12 16:34:06 https://access.redhat.com/support/policy/updates/errata/ 16:34:58 end of phase 2 was jan 2014... we are in phase 3 on 5 now 16:35:23 so, I guess we could say cut things off sometime before 2017 16:35:30 (for new packages) 16:35:53 ok sounds good 16:36:47 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 +1 here 16:37:20 #topic Open Flood 16:37:53 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 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 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 ush, no there is no expectation they will be the same. 16:39:03 ush, however an instlal of that and then a yum update should bring them in line. 16:39:32 avij, I will look at that after this meeting. Thanks 16:39:47 smooge: Thank you. That's what I guessed. 16:40:06 anything else? 16:40:36 * nirik has nada 16:40:39 I have something 16:40:40 ush: it should be the same, but there are no guarantees. centos does not intentionally change that package. 16:41:00 tyll, what is it? 16:41:07 avij: ack 16:41:18 ush: (apart from re-signing, that is) 16:41:33 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 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 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 the second is very very optional :) 16:44:24 and I would be in favour as I don't like zombie packages 16:45:25 +1 16:45:30 The general idea is to make weekly reports about orphaned packages and then retire them if they were reported six weeks 16:45:39 But I can open a ticket off course 16:46:22 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 can we start the weekly reports to the list and tackle the "when to start orphaning" question at a meeting? 16:47:44 works for me 16:48:08 bstinson, works for me also. tyll do you need help with setting up where such a script should live/work? 16:49:10 I will ask for this when the script is ready and I can use a releng system to develop it 16:49:57 cool 16:50:12 I will actually open the ticket on this as you have already done a heck of a lot :) 16:50:31 thank you 16:50:50 is there anything else on this? 16:51:01 or other open flood items? 16:51:15 I will close out the meeting in 1 minute otherwise 16:51:22 not from me 16:51:34 none here 16:52:26 php-horde-Horde-Pack-1.0.4-1.el6 not tagged as testing 16:52:35 wonder if it was a race? 16:52:55 #endmeeting