16:01:37 <smooge> #startmeeting EPEL meeting
16:01:37 <zodbot> Meeting started Fri Oct 10 16:01:37 2014 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:44 <smooge> #meetingname epel
16:01:44 <zodbot> The meeting name has been set to 'epel'
16:02:20 <nirik> morning
16:02:28 <bstinson> hi all
16:02:29 <smooge> #topic robot rollcall
16:02:49 <smooge> morning everyone
16:02:57 <avij> good evening
16:03:00 <smooge> I think dgilmore-bne is on pto still
16:03:03 <nirik> croooooow... sorry, hi.
16:03:05 <smooge> evening
16:03:20 <smooge> gypsy
16:03:47 <smooge> Evolution, you around?
16:04:27 <smooge> and I take it the coffee machine ate him
16:04:35 <smooge> ok anyone else ?
16:04:43 * bstinson hopes he brings enough for everyone
16:04:46 <smooge> #topic Wrangling business
16:05:24 <smooge> ok I am putting this section on the meeting list like our apprentice list in infrastructure. It will be a point where wranglers will hopefully go over problems and fixes
16:05:49 * maxamillion is here ... late, but here
16:05:54 <smooge> but since its new.. and there are only 4 wranglers.. none of them here I think. wait there's one
16:06:04 <smooge> hello maxamillion
16:07:06 <maxamillion> smooge: I wanted to ask about the wrangler tickets and general "expectations" or even "proper course of action" ... for things like the CVEs is it appropriate to just go in and swing the provenpackager hammer to fix them and move on or should there be a process of trying to prod the owners in the even there is one?
16:07:34 <smooge> ok.. my opinion only....
16:07:36 <maxamillion> also, for the orphaned ones I'm going to claim ownership of ones that I feel like I can comfortably support/patch/update and such as needed
16:08:02 <nirik> maxamillion: thats always welcome. ;)
16:08:31 <maxamillion> nirik: which part?
16:08:52 <smooge> EPEL is in a sad state. We have a ton of packages that no one is looking at. At this point we have cattle all over the valley and no one knows what they are doing.. so if I had provenpackager I would be doing the following: 1) alert the owner (who should have been alerted multiple times already) 2) fix the problem, 3) move to the next cowpatty
16:08:52 <nirik> taking on orphans and feeding them and giving them a safe place to sleep. ;)
16:09:21 <nirik> smooge: +1. Try and ping maintainer, but if they don't wake up, just fix it(tm)
16:10:14 <Evolution> I'm here.
16:10:32 <smooge> if the fix requires an api break or something, make a ticket with some info on why it wasn't easy and we will deal with it over the next week.
16:10:38 <smooge> we as in EpSCO
16:11:42 * nirik nods. sounds reasonable to me
16:11:45 <Evolution> smooge: for those of us without godlike powers, what should we be doing?
16:11:48 <Evolution> as wranglers
16:12:15 <maxamillion> nirik: +1
16:12:29 <smooge> well what I would like to talk about for us in EpSCO to think about is looking at putting various packages in group ownership as co-maintainers or something
16:12:38 <maxamillion> smooge: alright, +1
16:12:57 <nirik> folks without provenpackager could triage bugs, get patches ready for others, help coordinate?
16:13:10 <smooge> but that will take some jawin' and thinkin' and so I was goin' to say what nirik plum said
16:13:27 * smooge has watched way too many old time cowboy serials
16:13:57 <smooge> so nirik +1
16:14:00 <nirik> smooge: another option, but would need more work... make the epel wranglers just like provenpackager for epel packages in acls. But that might add some confusion... dunno, just a random thought
16:14:15 <maxamillion> how would I write a request to EpSCO to write a formal guideline for that? I just want to make sure it's written down somewhere so people don't get upset if an epel wrangler moves on to #2 and just updates their package
16:14:44 <smooge> maxamillion, I am going to defer to nirik on that as I don't know how FESCO does such things
16:14:45 <nirik> maxamillion: you could tell them to complain to EpSCO?
16:14:51 <bstinson> what are the downsides to having someone "Just do it", EpSCO should be ready to arbitrate
16:15:07 <nirik> bstinson: +1
16:15:40 <nirik> the downside might be the wrangler doesn't fix it right or messes up some coordination they don't know about... but if the maintainer answers a ping they could convey that.
16:16:17 <nirik> and really, if it's not right, they can say the entire time it's in testing. ;)
16:16:33 <maxamillion> nirik: right, I'm fine sending them to EpSCO so long as EpSCO has a published guideline on how that stuff is handled that I can reference in the event someone gets upset abou tit
16:16:36 <maxamillion> about it*
16:17:22 * nirik shrugs, we can put it on the wiki for sure.
16:17:51 <smooge> maxamillion, put in a ticket please just saying "I would like a written policy." I will try and get it done by next meeting
16:18:02 <smooge> but at this point, you have carte blanche
16:18:03 <maxamillion> smooge: sounds good, thanks
16:18:15 <nirik> fix all the things. ;)
16:18:42 <maxamillion> smooge: is there an EpSCO trak instance somewhere or does that share space with the epel wranglers?
16:19:31 <smooge> there is just the EPEL trac for all of this
16:19:39 <maxamillion> cool cool
16:19:41 <smooge> I have been using it for EpSCO
16:19:49 <smooge> and anything else epel related
16:20:10 <smooge> ok anything else on this?
16:22:01 <maxamillion> smooge: https://fedorahosted.org/epel/ticket/23
16:22:11 <smooge> thanks
16:22:14 <maxamillion> certainly
16:22:24 <smooge> #topic Old Business
16:22:36 <smooge> #topic ticket 2 How to handle systemd service activation defaults in EPEL7
16:22:48 <nirik> I'd like to get dgilmore-bne's opinion on this.
16:22:57 <smooge> OK we don't have 100% quorum so I am going to say we need to wait.
16:22:59 <nirik> I'm now leaning toward just adding it to epel-release
16:23:07 <nirik> as long as it's not often we have to tweak it.
16:23:20 <bstinson> +1 for waiting
16:23:24 <smooge> I would like that people putting their info in the ticket on how they are leaning so we can just up/down if possible
16:23:52 <smooge> motion to table ticket til later, EpSCO members to comment in ticket if possible.
16:23:53 * nirik can do so
16:24:21 <smooge> +1 motion from me
16:24:23 <Evolution> +1 here
16:25:04 <bstinson> +1
16:25:32 <nirik> +1, added comment
16:25:57 <smooge> #agreed table ticket 2 til next meeting. EpSCO members to comment in ticket if possible.
16:26:09 <smooge> #topic ticket 4 Decide on criteria to unretire packages.
16:26:52 <smooge> I am guessing this needs dgilmore's input also...
16:27:27 <nirik> I still think reviews are kinda nice... but yeah, if it was already in and nothing has changed...
16:27:55 <nirik> I don't think anyone has filed a xerces-c review still.
16:29:28 <Evolution> what is considered a 'retired' package in this case?
16:29:32 <Evolution> one that was orphaned?
16:29:38 <smooge> well what I am trying to find out is if there is a way we can make an expedited review
16:30:02 <smooge> I have reviewed 2 packages in my life.. and both of them had to be reviewed by someone else
16:30:04 <bstinson> that might be something targeted toward the wranglers
16:30:42 <smooge> Evolution, a retired package is one which has gone past orphan but has been listed as RETIRED in the git repository and removed from epel downloads
16:30:46 <nirik> Evolution: they are seperate state.
16:30:53 <smooge> or what nirik said
16:31:18 <nirik> orphan -> no point of contact, any packager can take it on. retired -> no one can take it, it's gone to the great beyond.
16:31:33 <Evolution> fair enough. want to be sure I understand the level of stagnation/resurrection we're discussing
16:31:56 <nirik> this xerces-c thing was kind of a weird one (and the ones with it)
16:32:14 <nirik> it had actually been retired long ago, but we didn't start properly blocking all retired packages until recently.
16:32:27 <nirik> so someone didn't finish the process on it or something.
16:32:48 <nirik> I'm happpy to re-review it, but I don't have any desire to maintain it.
16:33:21 <maxamillion> +1
16:33:52 <smooge> ok I will put in a ticket to review xerces-c if it isn't already. then someone can walk me through reviewing agfain so I don';t screw it up
16:34:07 <nirik> well, there's not a review yet.
16:34:15 <nirik> someone will have to submit it before we can review it. ;)
16:34:17 <maxamillion> also, there's a *lot* of epel packages written in perl that need some love, are there any wranglers with perl chops? I have almost zero perl background :(
16:34:36 <smooge> mine is perl-4
16:34:37 <maxamillion> (kind of off-topic, but tangentially related)
16:36:20 <smooge> perl is like ruby is like python... fixing one thing creates a cascade of package changes
16:38:41 <smooge> so I think the answer to your question is none here. I think stahnma has them
16:39:03 <smooge> but that is a fleeting memory from long ago
16:40:34 <smooge> ok so I think we can table this til later. put anything we need to put in the notes like "We would prefer to do reviews the old fashioned way" and get dgilmore's opinion
16:40:50 <smooge> Evolution, nirik bstinson ?
16:41:10 <nirik> sure, and ask whoever actually cares about xerces-c to submit a review.
16:41:10 <Evolution> no, I think that's all reasonably sane so far.
16:41:22 <bstinson> +1
16:42:12 <bstinson> i can pick up some reviews if it comes up
16:42:38 <smooge> #agreed table til next meeting
16:42:43 <smooge> #topic Current Business
16:43:24 <smooge> These are a bunch of tickets. I am going to just go through them quick and ask that EpSCO people comment on the ticket and we close/review next meeting
16:43:42 <smooge> #topic ticket 06 Fix EPEL subject line in mailman
16:43:45 <avij> thanks to smooge for investigating the subject line issue. it was EPEL that got stripped out, not epel. looks like the subject lines work better now with the [EPEL-devel] mailing list identifier.
16:44:21 <smooge> I think I fixed this yesterday but haven't gotten any emails on list so don't know if I broke it.
16:44:27 <smooge> have others gotten epel mail?
16:44:35 <smooge> if so I will close ticket after meeting
16:44:55 <nirik> I saw a test email from you smooge.
16:45:09 <avij> the ticket email from 20min ago contained EPEL in the subject line just fine
16:45:17 <smooge> ok will close after meeting :)
16:45:22 <smooge> #topic  ticket 07 Policy and technical means for removing orphaned packages in EPEL
16:46:04 <smooge> ok this is more about formalizing how we are going to deal with orphaned packages in EPEL. I think FESCO has a policy for Fedora releases and rawhide nirik?
16:46:22 <nirik> yeah, and it recently changed.
16:46:32 <nirik> it used to be once per fedora cycle orphans would get retired.
16:47:00 <nirik> I am not sure if we have formally changed it yet, but it was going to move to a 'x weeks orphaned -> retired'
16:47:26 <nirik> I'd be fine with epel doing that, as long as we have clear reports/notices about it before it happens.
16:47:39 <nirik> so people aren't surprised by packages disappearing that they wanted to keep
16:48:24 <smooge> nirik, I agree. I expect we will need to use scripting to say something like
16:48:54 <smooge> "These packages will be retired on XXXX-XX-XX. Please find someone to take if you want to keep it."
16:48:56 <nirik> yeah, I think tyll was fine doing the scripting work, so it all sounds +1 to me.
16:48:59 <nirik> yep
16:49:17 <smooge> ok to table to make sure we have dgilmore-bne releng side of things?
16:49:41 <nirik> sure. we need time to get scripting going anyhow
16:49:48 <smooge> bstinson, Evolution ?
16:49:54 <smooge> +1 from me to table
16:50:02 <bstinson> +1 for tabling
16:50:03 <Evolution> we're tabling all the things today
16:50:44 <smooge> basically
16:50:50 <bstinson> i am in favor of retiring after a set number of weeks
16:51:00 <bstinson> the reports are plenty of notice (and quite nice)
16:51:09 <smooge> if people can put their input in the tickets we can make next week.. approve/reject all the things
16:52:01 <tyll> the scripting is only lacking a check for how long packages are currently orphaned btw
16:52:04 * stahnma is very late
16:52:34 <tyll> and the retirement off course, which I guess will be manual initially
16:52:40 <nirik> I think 6 weeks is fine.
16:53:00 * nirik is fine approving today and dgilmore-bne can yell if he doesn't like it and we can revisit it.
16:53:16 <smooge> ok in that case. I am +1 for 6 weeks til retirement with weekly notice
16:53:37 <bstinson> +1
16:54:01 <Evolution> sure. I'll go with peer pressure
16:54:02 <Evolution> +1
16:54:36 <Evolution> stahnma: that's fine. we assigned you all the perl/ruby stuff to fix in epel while you were out
16:54:40 <Evolution> :-P
16:54:50 <stahnma> sweet jeebus
16:55:00 <stahnma> the ruby stuff I probably own about 50% of the issues anyway
16:55:00 <smooge> next time bring doughnuts
16:55:01 <stahnma> :(
16:55:20 <stahnma> perl, I probably have the skills to help, but not the time :(
16:55:22 <smooge> #agreed Packages which are orphaned for 6 weeks are retired.
16:55:48 <stahnma> for my clarification, is orphaned just without a primary POC or no POC and no co-maintainers?
16:56:06 <nirik> orphaned is just no point of contact. There might be co-maintainers.
16:56:19 <nirik> if there are, they are asleep since they didn't notice that there's no point of contact. ;)
16:56:59 <smooge> and they can wake up and take it over.. or find out its gone
16:58:55 <stahnma> ok
16:59:05 <stahnma> just wanted to make sure I understood the workflow these days
16:59:21 <smooge> #topic  ticket 08 EPEL-latest link rpm
17:00:03 <nirik> this has been talked about in the past...
17:00:21 <smooge> so this is one of the big problems we reports about.. people want a solid link for the epel-release and when we updated R numbers it breaks lots of scripts
17:00:53 <nirik> if it's a cron job I'm ok with it. If it's manual I am against it. ;)
17:01:04 <smooge> I would like to write a cron job which basically checks to see if epel-release-latest-7.rpm is pointing to the current epel-release-7-n and fixing it
17:01:23 <smooge> so breaks are maybe 4-24 hours depending on how many times we run it?
17:02:06 <smooge> the script would be in fedora infrastructure and checked out to make sure it doesn't do anything funky
17:02:38 <smooge> beyond that it was mostly a "if I do the work, would it be something we should do.. " which from nirik I say is yes
17:02:45 <nirik> sure.
17:02:58 <bstinson> +1 from me
17:03:04 <nirik> I just do not want any kind of manual process, because then we will forget and people will complain
17:03:11 <smooge> yep. I agree
17:03:12 <Evolution> yeah.
17:03:14 <nirik> if it's automated, I'm +1
17:03:25 <smooge> +1 from me.
17:03:48 <Evolution> the only potential drawback is using epel-latest for future stuffs (the rolling repo we all dream of) could be confusing.
17:03:58 <Evolution> so we're simply murdering a name early
17:04:01 <Evolution> I'm okay with that
17:04:17 <smooge> you come up with a name and I will use that to link
17:04:35 <smooge> Even if it is epel-smooge-stinks
17:04:44 <smooge> well maybe not
17:05:07 <smooge> but anyway I don't care what colour the bikeshed is if others can agree :)
17:05:26 <smooge> ok we are 5 minutes over our 1 hour slot.
17:06:11 <smooge> I put a lot on the agenda.. so I would like to table the lot with the request that people put info in the tickets so we can deal with them next time
17:06:19 <Evolution> no, I'm 100% fine with epel-release-latest-7 or epel-release-7-latest or whatever
17:07:19 <smooge> bstinson, nirik Evolution ok to table with input so we can close any items needing votes next meeting?
17:07:28 <nirik> sure thing
17:07:29 <bstinson> +1
17:07:47 <Evolution> lets table the voting on voting.
17:07:56 <Evolution> sorry, couldn't resist.
17:08:00 <Evolution> yeah, I'm fine with it.
17:08:05 <smooge> #agreed all other topics will be tabled. EpSCO and EPEL people to read comment in tickets so we can finish them next meeting
17:08:18 <smooge> #topic Open Flood
17:08:27 <smooge> ok anything for open flood?
17:09:28 * nirik has nothing off hand
17:09:42 <smooge> ok closing in 1 minute
17:10:11 <bstinson> thanks smooge
17:10:16 <smooge> #endmeeting