14:00:45 <Sparks> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings 14:00:45 <zodbot> Meeting started Thu Apr 16 14:00:45 2015 UTC. The chair is Sparks. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:48 <Sparks> #meetingname Fedora Security Team 14:00:48 <zodbot> The meeting name has been set to 'fedora_security_team' 14:00:56 <Sparks> #topic Roll Call 14:00:57 * Sparks 14:01:11 * d-caf 14:01:27 <bvincent> .fas bvincent 14:01:29 <zodbot> bvincent: bvincent 'Brandon Vincent' <Brandon.Vincent@asu.edu> 14:01:34 <pjp> .hellomynameis pjp 14:01:35 <zodbot> pjp: pjp 'None' <pj.pandit@yahoo.co.in> 14:01:43 <pjp> Hello all! :) 14:01:55 <d-caf> hello! 14:02:32 * Sparks is in another meeting so... 14:02:55 <Sparks> #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better" 14:03:13 <Sparks> #topic Follow up on last week's tasks 14:03:52 * Sparks isn't going to run through everything. 14:03:57 <Sparks> ...right now 14:04:05 <Sparks> Does anyone have anything? 14:05:00 <pjp> No response from Michael Stahnke after first reminder -> https://bugzilla.redhat.com/show_bug.cgi?id=1209124 14:05:03 <pjp> #link https://bugzilla.redhat.com/show_bug.cgi?id=1209124 14:05:31 <Sparks> pjp: Okay, I'm assuming you're keeping up on this. 14:05:36 <pjp> Yes, 14:05:45 <Sparks> Cool 14:06:10 <pjp> Last week I also pinged on older bugs via a script, 14:06:16 <Sparks> +1 14:06:26 <pjp> I'm yet to follow up on the maintainer responses, 14:06:36 <Sparks> #topic 90-Day Challenge 14:07:23 <pjp> Did jsmith follow up with the rubygems critical issue? 14:07:34 <Sparks> I haven't updated te numbers yet. Will send something out later today on thie list 14:07:51 <jsmith> I've got a scratch-build for the rubygem-activesupport issue that updates to a newer version 14:08:04 <jsmith> In order to get it to build, however, I had to disable the built-time checks 14:08:14 <jsmith> (as they haven't been ported to the newer version of the gem) 14:08:17 <jsmith> Thoughts? 14:08:41 <Sparks> #topic Outstanding BZ Tickets 14:09:08 <pjp> jsmith: what kind of built in checks? 14:09:17 <jsmith> pjp: Ruby "rake" tests 14:09:33 <pjp> I see, 14:09:35 <jsmith> pjp: In short, the Rakefile is completely out of date and no longer runs 14:10:04 <Sparks> fun 14:10:30 * pjp has no idea about ruby gem packaging, 14:11:36 * jsmith just barely knows enough to be dangerous 14:11:41 <d-caf> Sorry, ruby is one of my worst languages 14:11:43 <pjp> Came across this #link -> https://fedoraproject.org/wiki/Packaging:Ruby?rd=Packaging/Ruby 14:12:13 <pjp> jsmith: I'll try to find out someone who could help with it, let's see 14:12:14 <Sparks> jsmith: Are you getting help with this? 14:12:45 <jsmith> Sparks: gomix has agreed to help me with this, but unfortunately he's swamped with ${DAYJOB} and a very sick wife, so I've been mostly on my own :-( 14:13:07 <gomix> :[ 14:13:11 <Sparks> I wonder if he can suggest someone else to help 14:13:46 <gomix> mmorsi maybe 14:14:07 <gomix> try #fedora-ruby channel 14:14:10 <jsmith> He's the package maintainer, and obviously hasn't been responsive up to this point :-( 14:14:16 <gomix> ohhh... 14:14:18 <gomix> i see 14:14:20 <gomix> did not notice 14:15:11 <Sparks> #info Thursday's numbers: Critical 1, Important 39 (-2), Moderate 333 (-17), Low 159 (-4), Total 532, Trend -24 14:15:14 <Sparks> #info Current tickets owned: 141 (~26%) 14:15:17 <pjp> jsilhan: mmorsi did ping Miachel on the non-reponsive bug, I guess he is active 14:15:23 <Sparks> #info Tickets closed: 278 (+7) 14:15:34 <pjp> jsmith: ^^ 14:15:41 <pjp> jsilhan: sorry, ;) 14:16:11 <jsilhan> np 14:16:45 <Sparks> #topic Open floor discussion/questions/comments 14:16:48 <d-caf> Regarding tickets, looks like I have 6 Important tickets I'm going to have to file non-responsive maintainer bugs on. 14:17:28 <Sparks> d-caf: :( 14:17:56 <jsmith> Probably worth putting out a "call for help" on the -devel list too... 14:17:58 <d-caf> Yeah, I've tried, and nothing, got to get it going formally now so we can get them to someone else or out 14:18:11 <d-caf> jsmith: not on the devlist yet 14:18:17 <jsmith> OK... 14:18:40 <d-caf> I'll do that as part of the non-response ticket 14:19:09 <pjp> jsmith: Could you please attach the scratch-build SRPM to the bug with your comments? -> https://bugzilla.redhat.com/show_bug.cgi?id=905374 14:19:25 <pjp> jsmith: I'll check with mmorsi if he could help us with it. 14:19:40 <jsmith> #action jsmith to update the rubygem-activesupport bug with scratch build, etc. 14:19:51 <d-caf> What is the process for transferring package from one main contact/administrator to another? 14:20:52 <pjp> d-caf: Transferring ? 14:21:09 <d-caf> pjp: yes 14:21:20 <pjp> d-caf: In cases of non-responsive maintainers? 14:21:35 <d-caf> pjp: yes, I have a new maintainer willing and ready 14:22:27 <pjp> d-caf: Oh, 14:23:04 <d-caf> David who took over the EPEL builds of torque is willing to take the Fedora builds 14:23:33 <d-caf> The old maintainer appears to just be to busy now... 14:25:01 <Sparks> Okay, anyone have anything else? 14:26:39 * pjp looking for a ownership transfer process, 14:26:44 * jsmith has nothing left to add 14:27:14 <jsmith> pjp: Typically if the maintainer is non-responsive, the packages get orphaned. If someone claims them, great. If not, they get kicked out of the pool... 14:27:30 * d-caf tried to find ownership transfer process with out orphaning.. 14:28:09 <Sparks> Okay, I need to run 14:28:11 <jsmith> d-caf: Just add the new maintainer as a co-maintainer 14:28:14 <pjp> jsmith: d-caf I think asking existing maintainer to pass on the maintainer rights in the git should help, 14:28:23 <jsmith> Just add a co-maintainer in pkgdb 14:28:34 <pjp> Right, 14:28:47 <d-caf> pjp: maintainer doesn't respond 14:29:07 <Sparks> #chair pjp jsmith d-caf 14:29:07 <zodbot> Current chairs: Sparks d-caf jsmith pjp 14:29:10 <d-caf> I'll have to check if I have the perms in pkgdb, don't think I do, can only request 14:29:30 <jsmith> d-caf: Then as part of the non-responsive maintainer process, their packages can be re-assigned by infra 14:29:35 <Sparks> jsmith: Can you take the rest of the meeting fo rme? 14:29:43 <jsmith> Sparks: ACK 14:29:49 <Sparks> tnkx 14:30:37 <d-caf> yep, appears I can only request access for myself 14:31:09 <jsmith> Again, if it's a non-responsive maintainer, just state that you've found a willing maintainer as part of the notification process. 14:31:24 <d-caf> jsmith: ok 14:31:27 <pjp> d-caf: there is -> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers 14:31:46 <jsmith> pjp: That's great in theory, but doesn't often effect a lot of change :-( 14:32:00 <pjp> d-caf: so, retire and then un-retire the package 14:32:08 <pjp> jsmith: I see, 14:32:32 <d-caf> pjp: thanks, I'll go over that and chat with the new maintainer see if we can't get this sorted 14:32:47 <pjp> on #fedora-devel <rdieter> pjp: yes, pkgdb ui has a "give" button 14:32:54 <d-caf> was hoping for some quick button I had missed :-) 14:33:23 <jsmith> No, if the current maintainer is non-responsive, you have to follow the process... 14:33:41 <pjp> True 14:33:47 <jsmith> ... if the maintainer *is* responsive, then they can give control of their packages to someone else. 14:34:23 <d-caf> I had talked with the maintainer months ago, and he wanted to find someone new, and the new maintainer says he talked with him a few weeks ago and got the ok 14:34:35 <d-caf> but he fails to update tickets or responde to emails last few weeks 14:34:54 <jsmith> Have the old maintainer "give" his packages to the new maintainer. If that fails, follow the "non-responsive maintainer" process. 14:35:04 <d-caf> will do 14:35:17 <jsmith> Typically, initiating the process will be enough to kick the old maintainer into at least passing control of the packages. 14:35:28 <pjp> d-caf: non-responsive policy has details about transferring ownership -> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Outline 14:35:29 <jsmith> (Nothing like a little public shame, right?) 14:35:38 <pjp> d-caf: see #7 14:36:04 <d-caf> pjp: yep got that page (actually added a link to it of the security team page :-) 14:36:07 <pjp> <rdieter> step 7 is the change of ownership 14:36:18 <pjp> d-caf: Cool! 14:36:36 <jsmith> Awesome... anything else for the meeting? 14:36:44 <pjp> d-caf: is there a non-responsive bug against the maintainer ? 14:37:00 <d-caf> pjp: no not yet 14:37:29 <pjp> d-caf: I think let's start with that right away, 14:37:31 <d-caf> was trying to avoid public shaming, as he kinda resonded off and on 14:37:39 <pjp> I see, 14:39:35 <d-caf> I'm not a huge fan of public shaming of volunteers if it can be avoided 14:39:51 <d-caf> Anyways, nothing more really for this meeting, looks like I have a few routes to go down, thanks 14:41:53 <d-caf> End meeting? 14:41:53 <pjp> Cool! 14:42:10 <pjp> d-caf: Okay, if there is nothing else on agenda. 14:42:27 <jsmith> Will do 14:42:29 <jsmith> Thanks everyone! 14:42:31 <jsmith> #endmeeting