18:07:53 <ogondza> #startmeeting
18:07:53 <robobutler> Let the Jenkins meeting commence!
18:07:57 * oleg-nenashev has to drop-off within 5 minutes :(
18:08:03 <orrc> #info https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda
18:08:22 <orrc> #topic LTS RC status check
18:08:35 <jenkins-builds> Yippie, build fixed!
18:08:36 <jenkins-builds> Project jenkins_main_trunk build #4132: FIXED in 59 min: http://ci.jenkins-ci.org/job/jenkins_main_trunk/4132/
18:08:36 <jenkins-builds> devld: [FIXED JENKINS-28227] Switch to Enblish locale in RunTest#getDurationString to test messages.
18:08:39 <jenkins-admin> JENKINS-28227:RunTest#getDurationString fails on non-english environments. (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-28227
18:08:39 <orrc> (I wonder if that works)
18:08:47 <orrc> ogondza: LTS RC? :)
18:08:57 <ogondza> jglick: I understand JENKINS-26781 in not blocked anymore
18:09:00 <jenkins-admin> JENKINS-26781:regression resolving Descriptor using "$class" vs "kind" (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-26781
18:09:35 <ogondza> I have seen that an hour ago and backporting seems not-trivial.
18:10:01 <ogondza> as kohsuke is likely not going to fire the release right away I can give it a try tomorrow
18:10:23 <jglick> ogondza: would you like help getting a list of commits to backport? Or an aggregate patch?
18:10:54 <jglick> ogondza: or a PR against the stable-1.609 branch?
18:11:05 <ogondza> it takes about 8 hours to run the test pipeline ...
18:11:46 <ogondza> jglick: that would help, there ware some conflicts relying on commits not linked to any issue
18:12:09 <jglick> ogondza: I will try to prepare it as a PR, I think that is the easiest thing to review
18:12:35 <ogondza> jglick: thanks
18:12:36 <jglick> Can work on that today. I also *just* managed to reproduce JENKINS-26582 and if it is a core bug I would propose it as lts-candidate too.
18:12:38 <jenkins-admin> JENKINS-26582:ISE from RunMap.put after reloading config (In Progress) https://issues.jenkins-ci.org/browse/JENKINS-26582
18:12:52 <jglick> (Certainly looks like a bug in matrix-project but I have not yet analyzed it.)
18:13:21 <jglick> Also plan to look into JENKINS-26575 and JENKINS-26743 but these could wait.
18:13:23 <jenkins-admin> JENKINS-26575:Running the reverse migrator after upgrading to 1.597 throws NoClassDefFoundError: javax/servlet/http/HttpServletRequest (Open) https://issues.jenkins-ci.org/browse/JENKINS-26575
18:13:25 <jenkins-admin> JENKINS-26743:Build record migration prints warnings for permalinks (Open) https://issues.jenkins-ci.org/browse/JENKINS-26743
18:13:44 <orrc> out of interest, when's the RC due? they don't seem to be on the calendar any more
18:13:59 <ogondza> orrc: ~today
18:14:07 <orrc> ah ha
18:14:16 <ogondza> or tomorrow with that one backport
18:14:34 <ogondza> jglick: I presume the rest does not go in .1
18:15:01 <jglick> ogondza: well JENKINS-26582 is serious, so I do not know
18:15:03 <jenkins-admin> JENKINS-26582:ISE from RunMap.put after reloading config (In Progress) https://issues.jenkins-ci.org/browse/JENKINS-26582
18:15:17 <jglick> Depends on what the issue turns out to be (core or plugin), and if core then how tricky the fix is.
18:16:10 <jglick> If it is a simple core fix I might propose bending the rules given the circumstances.
18:16:32 <danielbeck> sorry I'm late
18:16:50 <ogondza> jglick: I do not object
18:17:06 <jglick> OK, TBD.
18:17:15 <ogondza> we are fine to move on
18:17:25 <orrc> great. let's try...
18:17:28 <orrc> #topic #jenkins-meeting
18:17:50 <danielbeck> remove the second # ?
18:18:22 <orrc> no idea. ogondza managed to start the meeting, but aside from that robobutler has remained silent
18:18:31 <ogondza> #topic #jenkins-meeting
18:18:41 <danielbeck> you need to be chair to change topic
18:18:51 <ogondza> it seems I have to run the whole thing
18:18:58 <orrc> that's what I thought, but didn't realise ogondza was a chair :)
18:19:08 <danielbeck> well, the proposal is fairly straightforward: Let's establish a channel for meetings only
18:19:14 <ogondza> orrc: me neither
18:19:19 <danielbeck> no more "sorry meeting right now" etc.
18:19:21 <ogondza> +1 on new channel
18:19:35 <danielbeck> meetings get robologs anyway, so no need for echelog if it would be difficult
18:19:42 <orrc> ogondza: you can set chairs with #chair
18:20:00 <ogondza> I do not expect anyone to disagree
18:20:04 <orrc> hmm, I'm not sure, as it feels like it would reduce the number of people participating
18:20:19 <orrc> though agreed that "we're in a meeting" or "build started" is annoying
18:20:34 <danielbeck> IIRC credit for this idea goes to KostyaSha who mentioned this to me a while back
18:21:12 <danielbeck> and given the frequent interruptions I thought this is a good idea
18:21:20 <danielbeck> anyone opposed?
18:21:42 <danielbeck> orrc We could try to announce on #jenkins when a meeting starts
18:22:21 <orrc> indeed. ok, so I guess we need INFRA tickets
18:22:26 <ogondza> can someone file an INFRA issue to set that up? connect necessary bots or whatever else needs to be done
18:22:28 <orrc> assuming there are +1s
18:23:18 <danielbeck> ogondza I can file INFRA but don't have the super bot powers to implement unfortunately
18:23:33 <danielbeck> I hope this is just a config change in the robobutler to go to a different channel
18:23:42 <danielbeck> plus some bot from Freenode to be op
18:23:50 <ogondza> thanks
18:23:57 <ogondza> #action danielbeck file INFRA issue for #jenkins-meeting
18:24:01 <orrc> yeah, we need to register with chanserv most likely. rtyler should be the expert there
18:24:06 <ericmeds> can I have two different jenkins jobs update a single git PR with status? ( like so http://f.devicefreak.com/jenkins.png )
18:24:13 <orrc> hehe
18:24:13 <ogondza> shall we move on?
18:24:23 <danielbeck> ericmeds Sorry meeting right now, please ask later
18:24:29 <orrc> ogondza: do it
18:24:41 <ericmeds> ok
18:24:47 <ogondza> #topic Should we only include plugins in the Update Centre if they have a wiki page?
18:25:03 <orrc> #info https://groups.google.com/forum/#!msg/jenkinsci-dev/oEHEjKo08yA/S_uQ_C_7NMQJ
18:25:14 <batmat> +1 about this.
18:25:28 <danielbeck> Yes. The question is for me only whether to grandfather in releases created before the decision.
18:25:29 * ericmeds btw just a note - you guys could lock the channel down to just Ops and those who are voiced
18:25:46 <danielbeck> ericmeds Meetings are public, no precondition.
18:25:50 <orrc> so some of the info is there on the meeting page wiki, more details are in that jenkinsci-dev thread, and it seems like a popular idea
18:25:51 <ericmeds> oh ok
18:26:28 <jglick> danielbeck: I think you need to grandfather in releases prior to the decision as they may be honest mistakes.
18:26:53 <orrc> jglick: that's what this is about: https://github.com/jenkinsci/backend-update-center2/pull/14
18:27:25 <danielbeck> jglick For a grace period at least I think
18:27:32 <batmat> jglick: Not sure this is possible in the long term.
18:27:34 <danielbeck> Then review in 3-6 months
18:27:37 <batmat> danielbeck: exactly.
18:27:47 <orrc> agreed
18:28:15 <batmat> because if this can stay as-is indefinitely, it makes absolutely no sense to even discuss this IMO
18:28:38 <batmat> users will still "suffer" from badly defined plugins visible in the list inside Jenkins, and so on.
18:29:30 <orrc> so, I have the update centre code on my laptop, and a list of plugins which are questionable which need a bit more investigation
18:30:01 <orrc> but otherwise, I think we're set.  main issues are making sure ruby-runtime has a wiki page, and that popular plugins get a temporary wiki override
18:30:21 <danielbeck> Pinging KostyaSha as he was opposed on the list?
18:31:25 <danielbeck> FWIW if there's something that legitimately prevents plugins from implementing this, we could add these to a list of exceptions. It's just the default should be to require a link.
18:31:32 <orrc> if he's here, that would be good. but it just seemed to be a misunderstanding about multi-module poms or something
18:31:49 <orrc> danielbeck: yeah, the wiki-override would work fine for that
18:31:54 <danielbeck> (and Jenkins should rewrite hudson-ci.org to jenkins-ci.org in the /pluginManager :-) )
18:32:04 <batmat> IMO, he opposed to things that were actually not required from plugins. We're talking (almost) only here about having 1) a wiki page and 2) a correct <url> inside the pom
18:32:20 <orrc> ah right, yeah. that's a separate discussion :)
18:32:23 <danielbeck> batmat The rest is a separate topic later
18:33:02 <danielbeck> do we have any disagreement here?
18:33:10 <orrc> danielbeck: my UC changes rewrite all URLs to the canonical https://wiki.jenkins-ci.org/display/JENKINS form :)
18:33:17 <danielbeck> orrc Great!
18:33:29 <orrc> plus I fixed a bug where certain other URLs (e.g. ones with IDs in) do not work
18:33:36 <orrc> like the "Anything Goes" Formatter
18:33:38 <orrc> anyway, +1
18:34:32 <ogondza> alright, what are the actions here?
18:34:51 <ogondza> before we move on ...
18:34:58 <danielbeck> I propose we change UC to exclude plugins released from June 1st that have no <url> to a valid Jenkins (/Hudson) Wiki, and to review in the fall whether we can enforce this for all plugins. Technical reasons will get manual exceptions in the UC code.
18:35:16 <orrc> +1 from me
18:35:32 <ogondza> I am afraid users will be confused
18:35:39 <danielbeck> Actions are to modify the UC accordingly, send announcements to the dev list, and maybe email authors of plugins that are affected directly
18:35:47 <orrc> ogondza: by what?
18:36:00 <batmat> +1
18:36:07 <ogondza> there is a lot of questions, 'why is my plugin not listen in UC'?
18:36:08 <danielbeck> + add to the wiki documentation ("Help, my plugin doesn't show up")
18:36:26 <ogondza> if it can be skipped because of missing/broken url it will only get worse
18:36:49 <orrc> if devs can't follow simple instructions, I'm not sure what we can do
18:37:10 <orrc> documenting this stuff on the plugin-related wiki pages will be part of it
18:37:10 <batmat> Yes, and that has always been required: https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-AddingaWikipage just not enforced.
18:37:25 <batmat> this is not new.
18:37:25 <ogondza> batmat: fair enough
18:37:50 <danielbeck> would a report generated from the UC that clearly spelled out reasons for exclusion help? They'd have to find that first as well, and we have documentation on UC troubleshooting already...
18:38:20 <orrc> I added a bit more output to the UC, e.g. "Excluding foo-bar as URL http://example.com is not a valid wiki URL"
18:38:29 <orrc> so we could point to the j-o-j job
18:38:40 <danielbeck> orrc Awesome!
18:38:48 <orrc> (like the "Help, my plugin is missing" steps point to just now)
18:38:49 <ogondza> +1 from me
18:38:55 <batmat> Maybe there could even be something inside the Jenkins UI itself in the pluginManager, some notice about this ?
18:39:12 <batmat> Like the temporary things for the 1.600 and the likeS.
18:39:16 <orrc> #action orrc to publish a pull request to be merged June 1st which excludes bad plugins from the UC
18:39:20 <danielbeck> batmat That would be publishing. But maybe generated a 'rejected-plugins.lst' on updates.jenkins-ci.org?
18:39:35 <ogondza> #action orrc to publish a pull request to be merged June 1st which excludes bad plugins from the UC
18:40:27 <orrc> #action orrc to try and make plugin-related wiki pages even more clear about requiring a wiki URL
18:40:35 <orrc> I think non-chairs can write actions(?)
18:40:38 <danielbeck> What about announcement on dev list? Or even email to the affected plugin devs?
18:40:49 <orrc> yeah, that's another action
18:41:07 <batmat> danielbeck: not listing the excluded plugins, just a notice that "starting june first, some plugins might have been excluded, ..."
18:41:07 <orrc> I can do that
18:41:24 <ogondza> danielbeck: I guess committing the urls where missing is fine
18:41:26 <orrc> i.e. get my UC pull request up and running, then run the code and generate a list of bad plugins
18:42:08 <orrc> ogondza: that seems reasonable; we can mention that in the dev-list mail
18:42:36 <ogondza> #action add/fix wiki links where there is no doubt
18:42:36 <danielbeck> commits are evil, PRs would be better
18:43:16 <ogondza> danielbeck: why? I do not feel strongly, though it is more work
18:43:23 <orrc> we can write on the dev list that maintainers should do it ASAP, and give notice that we may do it ourselves after June 1st?
18:43:38 <danielbeck> do we also want to release? A possibly broken plugin state?
18:43:47 <danielbeck> If not, there's no point to committing directly.
18:44:06 <danielbeck> plus, some plugin authors may object to the invasion of their sandbox
18:44:21 <orrc> ok, that's fair
18:44:43 <orrc> maybe I'll take a look at automating the creation of pull requests
18:45:02 <orrc> so I think we're generally in agreement. I need to clean some stuff up and get a list of bad plugins
18:45:14 <orrc> we can see where we are at the next meeting, just before June 1st?
18:45:37 <danielbeck> sounds great. Make sure we have everything set up before pulling the trigger
18:45:39 <ogondza> orrc: that would be great, we will send the notice before that anyway
18:46:09 <orrc> ok, I guess we should skip to danielbeck's topic at the end of the agenda, as rtyler isn't around
18:46:20 <ogondza> ok, moving on
18:46:30 <danielbeck> What about the CDN? Also an rtyler topic?
18:46:44 <orrc> yeah, I would like to talk about that
18:46:56 <orrc> but it's kind of in his hands; he's the one who was talking to the CDN
18:46:57 <danielbeck> rtyler didn't update the issue where he wrote he contacted Fastly
18:47:03 <ogondza> #action Using a CDN with HTTPS / removing need for mirrorbrain?
18:47:13 <orrc> btw, mirrorbrain broke down again this morning
18:47:14 <danielbeck> do you mean #topic?
18:47:17 <orrc> hehe
18:47:25 <ogondza> #topic Using a CDN with HTTPS / removing need for mirrorbrain?
18:47:25 <rtyler> oh, my bad
18:47:46 <danielbeck> right on time!
18:47:52 <rtyler> I was summonned
18:47:58 <rtyler> let me dig that email up
18:48:00 <orrc> yeah, so rtyler said that Fastly replied and said they would be willing to front all the traffic for Jenkins updates (like they do for Python), AFAIK
18:48:05 <orrc> ah, even better :)
18:48:08 <rtyler> I basically owe them some details about our mirroring requirements
18:48:27 <rtyler> I also need to create some accounts and whatnot through their self-service portal
18:48:53 <orrc> will that become another INFRA #spof? :)
18:49:12 <rtyler> which, the fastly account?
18:49:14 <ogondza> #chair rtyler orrc danielbeck
18:49:14 <robobutler> Current chairs: danielbeck ogondza orrc rtyler
18:49:35 <orrc> yeah. which I guess relates to the previous infra topic we skipped
18:49:59 <rtyler> there's still a number of accounts died directly to me, but we have the facilities now to put shared passwords into an encrypted spot
18:50:14 <orrc> ah, nice
18:50:22 <rtyler> in some cases though accounts are tied directly to me as a person
18:50:26 <rtyler> like with a credit card
18:50:32 <rtyler> SPI don't give us credit cards :P
18:50:51 <orrc> shame
18:51:05 <rtyler> anyways, I'm finally free this weekend, I'll make it a priority to get the initial prototype of fastly up and running
18:51:33 <orrc> sounds great
18:51:43 <orrc> #action rtyler to look at an initial fastly prototype
18:52:34 <orrc> should we talk about more general infra when more infra admins are around?
18:53:42 <rtyler> what in particular do you have in mind?
18:54:13 <orrc> rtyler: there was an agenda item to discuss the infra training/expansion that was brought up a while back
18:54:27 <rtyler> yeah, so I'll briefly update that
18:54:55 <rtyler> aheritier asked for and was granted access, there's not a particular limit to contributing to the puppet infra though
18:55:07 <rtyler> the *management* and operation of the infra ia different trust story unfortunately
18:55:18 <rtyler> so I do not have guidelines or any documentation to report on that
18:56:04 <orrc> ok. what would be the requirement for someone who feels they're capable enough and in a well-placed timezone to get access?
18:56:07 <rtyler> aheritier did make a point about incorporating someobyd in the Asia/Pacific region to give us better operational support coverage, but as it stands now I don't have anybody that's come forward on that
18:56:45 <orrc> ok. we have two in EU, right? danielbeck, you have access?
18:57:01 <rtyler> well, demonstration of knowledge whether through activity in INFRA JIRA or by submitting PRs/reviews on jenkins-infra
18:57:13 <danielbeck> orrc I have access to... a lot
18:57:19 <rtyler> heh
18:57:38 <rtyler> to me earning trust is difficult to quantify
18:57:42 <danielbeck> Some docs would be nice though, I'm just an empty head right now :-)
18:57:51 <orrc> sure
18:58:30 <rtyler> I think an action here would be..
18:58:47 <rtyler> #action rtyler to audit the Infra subsection of the wiki for sensitive material so it can be opened up more broadly
18:59:05 <orrc> it's tough as it's not really possible to give granular server access; I'd like to be able to restart apache/confluence/jira in the early European hours
18:59:12 <rtyler> that's feasible
18:59:21 <rtyler> just not as easy as what aheritier got
18:59:51 <rtyler> orrc: file a JIRA for "atlassian admins" to be created as  a group and then we can add more people with perms only do admin those on the machines themselves
19:00:21 <rtyler> then I nominate you as the first sucker^Wmember
19:00:35 <orrc> sounds like effort; I'll take sudo access as well ;)
19:00:37 <orrc> sure
19:00:56 <rtyler> we can get better coverage faster with the more granular, so let's do that
19:01:02 <rtyler> and by "let's" I mean "I'll"
19:01:08 <rtyler> unless you want to write some puppet!
19:01:30 <orrc> I did try to get some jenkins-infra up and running a few weeks back, but failed without access to the secrets, I believe
19:02:00 <rtyler> ah, let's discuss that after this meeting
19:02:08 <orrc> like getting a web server role up and running. anyway, I can check again and report back
19:02:16 <rtyler> #action orrc and rtyler to create "atlassian admins" to help get coverage on jira/wiki
19:02:53 <orrc> wunderbar. danielbeck: you want to move to your topic?
19:03:07 <danielbeck> sure, let's have some real discussion here :-)
19:03:11 <rtyler> heh
19:03:18 * rtyler puts on his flame retardant suit
19:03:27 <orrc> #topic Further requirements for plugins published in the community update center
19:04:35 <danielbeck> We're publishing anything in the repo right now
19:05:02 <danielbeck> And anyone who has an account can upload a version of every plugin
19:05:20 <danielbeck> (account? commit access to one plugin? Not sure right now, but shouldn't matter)
19:05:55 <danielbeck> So, what prevents anyone from releasing, say, mailer 1.20, a bundled plugin?
19:06:32 <danielbeck> We do have a responsibility to our users who don't expect to get malware when installing a popular plugin, or updating a bundled one
19:06:38 <danielbeck> but right now, this is what they could get
19:06:51 <rtyler> I generally agree
19:07:04 <rtyler> I think some of the proposals you through into the meeting agenda would be good to go through
19:07:07 * rtyler looks at the time
19:07:24 <danielbeck> just pasting from the Agenda:
19:07:33 <jenkins-builds> Starting build #4133 for job jenkins_main_trunk (previous build: FIXED)
19:07:34 <danielbeck> Require a valid SCM URL for new plugin releases inside @jenkinsci/svn.jenkins-ci.org (that must exist) – needs to handle plugins not bundled with Gradle
19:07:40 <danielbeck> Require that the uploader of the binary is the same user who created the tag (we have the data in LDAP, see jenkins-ci.org/account)
19:07:44 <danielbeck> Remove the commit permissions from 'everyone', it's reckless
19:08:16 <danielbeck> Besides that last one, these should be fairly low impact, at least for plugins that are good "citizens"
19:08:35 <danielbeck> going through them one by one:
19:09:35 <danielbeck> Valid SCM URL... should be obvious. Like the wiki link, show us the source code. No file:/// URLs! Must be in svn.jenkins-ci.org / jenkinsci Github org. Allow exceptions for existing releases.
19:09:52 <ogondza> +1
19:10:12 <danielbeck> Also, requires plugins we distribute to be OSS. I think this is reasonable.
19:11:09 <danielbeck> Matching uploader and tagging committer: Requires a tag in the Jenkins community repo (besides just having a potentially unused/dead fork), also reasonable to allow others to review and inspect what would be installed.
19:11:38 <danielbeck> Users can specify their Github user ID in the jenkins-ci.org/account app, so we have the data, we just need to make use of it.
19:12:03 <StuartWhelan> Any CB support around? On Enterprise and want to have a quick chat about an urgent ticket I think is falling through the cracks.
19:12:37 <orrc> StuartWhelan: wrong time and place, I'm afraid. we're in a meeting (and I think there are no CB support people here)
19:12:53 <danielbeck> And the third one... I'm really troubled by the 'access by default' rule we have. We need to change this, otherwise the other two changes are useless.
19:13:04 <StuartWhelan> orrc: Rgr, ta
19:13:28 <danielbeck> It doesn't mean we would start removing access from users who have a good reason. It's easy enough to give per-repo access
19:13:38 <orrc> danielbeck: yeah, the recent junk plugins really made that problem clear
19:13:40 <rtyler> I think thie valid SCM thing is a great idea, I think we should definitely require OSS plugins for distrubition
19:14:19 <danielbeck> IMO there's nothing wrong with requiring the vast majority of users to have per-repo group memberships.
19:14:32 <danielbeck> Would have saved us from the repo force push issue a year or two ago as well, FWIW
19:14:56 <rtyler> agreed
19:15:16 <danielbeck> of course the transition period would be busy, plus users wondering wtf is going on, but we can smooth some of that by adding users to the repos they recently contributed to by default
19:15:21 <orrc> yeah, I'd quite like to clean up the GitHub organisation
19:15:50 <orrc> there's also been a couple of times in the past two weeks where people have hit "Create repo" directly from GitHub, which makes a mess
19:16:54 <danielbeck> Maybe I'm being too pessimistic about the problem. I don't know. But I fear that the reputation of the entire Jenkins project is at risk right now if someone exploited our _extremely_ permissive policies.
19:17:42 * rtyler nods
19:17:43 <deebo> when using on demand slaves (docker), how can i make the master node realize i'm mounting $JENKINS_HOME/workspace on the slaves?
19:17:54 <danielbeck> deebo Meeting right now, please wait a bit
19:17:55 <rtyler> deebo: give us a bit to wrap up this project meeting
19:17:57 <rtyler> heh
19:18:05 <deebo> ok
19:18:06 <rtyler> danielbeck: so what are some things we can do right now?
19:18:27 <rtyler> requiring a valid SCM URL, can just be git:// validation, but should the UC also be requiring that we can access it too?
19:18:41 <jmartinstw> hi, I have problems with EC2_Plugin: failed to launch com.amazonaws.AmazonClientException: Security groups must all be VPC security groups to work in a VPC context  at hudson.plugins.ec2.SlaveTemplate.getEc2SecurityGroups(SlaveTemplate.java:757)
19:18:48 <danielbeck> jmartinstw Please wait a bit, meeting right now
19:19:16 <danielbeck> rtyler I think we need the full package of valid SCM with tag for the version.
19:19:39 <danielbeck> Otherwise it's pointless from both traceability and safety POV
19:19:43 * rtyler nods
19:19:43 <danielbeck> + user matching
19:19:54 <danielbeck> because anyone can upload an HPI with a bad POM
19:20:05 <rtyler> so let's wrap this meeting up, what are some action items that we can take away from this?
19:20:23 <danielbeck> orrc WDYT? I think from those present you know UC best right now
19:20:40 <danielbeck> How much effort is it to extend UC to do this?
19:21:05 <orrc> the UC already examines the <scm> tag, so that shouldn't be too hard to validate
19:21:20 <danielbeck> orrc Remember the LDAP access to match Github user and jenkins-ci user
19:21:29 <danielbeck> there are two components here, adding requirements to the UC, and making them meaningful by cleaning up the Github org
19:21:57 <orrc> yeah, that's the part I'm not sure about, and would make this harder to develop/test
19:22:15 <danielbeck> rtyler How accessible is the account app info (LDAP I assume)?
19:22:19 <rtyler> could one of you take the org cleanup and the other UC work? or sohuld we try to find additional help?
19:22:29 <rtyler> as accessible as LDAP can be more or less
19:23:17 <orrc> I started working part time, so I've been making Mondays Jenkins monkey work time to some extent. maybe I can take a look at both
19:23:27 <danielbeck> Could we get some opinions first on how much agreement there is?
19:23:42 <rtyler> ogondza said +1, everobyd else is silent :P
19:23:50 <abayer> +sure? =)
19:23:55 <orrc> my main question is how tightly linked the jenkins-ci.org and LDAP accounts are
19:24:07 <rtyler> tightly linked to what?
19:24:07 <danielbeck> everyone is too busy writing mailer 1.20 :-(
19:24:16 <orrc> I asked kohsuke to ban the junk plugin guy from Maven, but it wasn't possible to just cut off Maven access
19:24:25 <orrc> so he just reset his password or something
19:24:37 <orrc> we need (I think?) a jenkins-admin: give maven access to foo
19:25:02 <rtyler> hm, we'll have to look at what group JFrog is binding to for LDAP authentication
19:25:14 <rtyler> and we can just start making more use of the rich wonderful world of pain LDAP supports :)
19:25:30 <orrc> INFRA-287 fwiw
19:25:32 <jenkins-admin> INFRA-287:Remove maven access for user anitha (Resolved) https://issues.jenkins-ci.org/browse/INFRA-287
19:26:11 <danielbeck> orrc If we manage permissions to the plugin repos, and only distribute on the UC what was created by authorized committers, that should be fine IMO
19:27:08 <danielbeck> Artifactory permissions based on paths (e.g. group) are a huge PITA so I don't think we want that
19:27:45 <danielbeck> Maybe add a flag/group membership required for committing so we can remove users generally, but not to do per-plugin upload permissions
19:27:53 * rtyler looks at the clock
19:27:55 <orrc> sure
19:28:13 <orrc> ok, I'll maybe take a look as well at grabbing the committer ID from Maven for a given release
19:28:30 <danielbeck> orrc Could you take a look at necessary UC changes? I'm busy next week but will be able to assist the week after
19:28:32 <orrc> I've seen it listed in Artifactory, so the info is there
19:28:32 <danielbeck> great
19:28:36 <orrc> yup
19:28:53 <orrc> #action orrc to look at the UC changes mentioned to validate <scm> and user info
19:29:04 <danielbeck> any Github admins around for taking inventory of needed changes there?
19:29:20 <orrc> heh, I was about to ask for admin access. so I can quit bugging abayer ;)
19:29:22 * rtyler is not currently a github admin
19:29:35 <danielbeck> drulli?
19:29:55 <orrc> oh yeah
19:30:15 <orrc> uh, this account has admin access? https://github.com/hudsonadmin
19:30:29 <orrc> mysterious, with a bad URL?
19:30:47 <rtyler> that's probably some bot thing that kohsuke set up
19:31:20 <rtyler> time for me to get back to work
19:31:31 <orrc> thanks for the input
19:31:34 <danielbeck> right, so someone needs Github org admin access or assistance by one of the admins. Then we need to get some data what needs to be done. I could try that
19:32:23 <orrc> ndeloof is an admin as well? he's on my bad plugin list of shame! :)
19:32:34 <orrc> danielbeck: you can #action yourself :)
19:32:34 <danielbeck> orrc didn't he fix it?
19:32:50 <danielbeck> #action orrc to investigate UC changes so it requires proper SCM, tag, and uploader
19:33:00 <batmat> I think ndeloof answered he tried to create the wiki page, but there was an issue at the time
19:33:08 <orrc> danielbeck: he has a bunch of plugins on the bad wiki list
19:33:14 <danielbeck> #action danielbeck to get data on necessary Github permission changes
19:33:33 <orrc> ok, all done
19:33:44 <orrc> #topic next meeting
19:33:56 <orrc> Looks like the 27th May at the usual time
19:33:58 <danielbeck> May 27, same time, same place
19:34:08 <orrc> depending on your INFRA task
19:34:10 <danielbeck> (unless we manage #jenkins-meeting) :-)
19:34:20 <orrc> #endmeeting