18:01:16 #startmeeting 18:01:16 Let the Jenkins meeting commence! 18:01:27 https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda 18:01:39 #topic Q4 patron ads on Jenkins Wiki 18:01:55 woah 18:02:23 FofG: rpetti: sorry to interrupt your conversations 18:02:45 So the first one is the patron message change proposal 18:02:50 ... and the diff is in https://github.com/jenkinsci/patron/pull/1/files 18:03:14 for the context, we have this "patron of Jenkins" program going for while: https://wiki.jenkins-ci.org/display/JENKINS/Patron+of+Jenkins+program 18:03:26 ... where large donors get to put messages in our Wiki 18:04:01 And when the message changes, we want to pre-approve the messages so that it won't get too flashy or advertisement-ish 18:04:06 Looks OK to me. +1 18:04:33 Any other +1s? concerns? 18:05:02 seems fine 18:05:43 #agreed the proposed message change looks OK to us 18:05:51 #topic Plugins not getting forked into jenkinsci, or not getting released from there 18:06:34 danielbeck: are we seeing a lot of those now? 18:06:41 subjectively this has come up a few times in the past, organizations that don't fork into the jenkinsci org, or actually use their own, or don't use the Jenkins JIRA 18:06:53 What problems does this cause? 18:06:55 no specific numbers but I've seen a few in the past few weeks 18:07:16 It's more difficult to find the repo and issue tracker 18:07:35 the community cannot contribute outside jenkinsci 18:07:35 hare_brain: part of it is that when the original author goes inactive, it increases the hurdle for others to take over 18:08:39 for instance, there is a security issue in sonar-plugin: https://github.com/SonarSource/jenkins-sonar-plugin/pull/9 18:08:54 not sure there is a way for us to take the lead 18:09:27 I still think overall sufficient number of plugins are getting hosted in the jenkinsci org 18:09:45 I think our governance document talks about that and generally encourages people to do it that way 18:10:32 Is there a commonality to plugins that are not hosted on jenkins-ci.org? i.e., are they from individuals? Companies? 18:10:47 if we think the people doing it outside our org is doing so because they don't know we want thier plugins co-hosted, perhaps a bit of outreach would be worthwhile 18:10:54 haven't systematically checked it, but seems to be mostly companies 18:11:22 IIRC the DotCi devs specifically mentioned wanting a popular looking GitHub org with stars 18:11:37 But OTOH if someone like sonarsource people really wants to control it by themselves, not sure how far we can push 18:11:42 Yeah 18:12:30 Do we think additional carrots/sticks would be needed to encourage people to move into the community? 18:12:35 #idea Plugins that are not hosted in jenkinsci GitHub org do not get wiki pages on jenkinsci.org, nor do they show up as an available plugin from default update center 18:12:48 In other words, discovery of these plugins gets harder. 18:13:09 Like some Linux distros with separate "non-free" repos maybe? 18:13:24 check an option and you still get them, but off by default 18:13:41 Something like that. 18:13:44 hare_brain: I agree. That's the intention of our UC anyway, but just haven't enforced them 18:14:47 AFAICT right now almost anyone can upload anything and it'll show up in the UC 18:15:11 Yes, which is also bit of a security nightmare 18:15:50 #idea Add UI to plugin manager for “report a bug”. Plugin authors can add a link to their issue tracker to the plugin metadata. 18:17:27 There was also a recent plugin, vnc recorder plugin, which went straight into Subversion, instead of a github repo... which I found odd, and have been meaning to ask why its source code is in subversion, and not github 18:17:35 I really want to encourage every plugin to be in this massive melting pot / salad bowl 18:18:20 And so I'm not really keen on helping people who want to do them otherwise 18:18:35 Yes, authors should be encouraged to integrate with project infra (wiki, Jira, github org) 18:18:52 anything besides those three? 18:19:41 What makes it difficult for me is that I think we benefited from not actively rejecting those companies/projects who do feel strongly about hosting plugins elsewhere 18:19:57 Many of them do produce rather interesting plugins 18:20:34 Right, and for those plugins, that separation makes it hard for a Jenkins user to be able to report problems, or find documentation. 18:21:25 They still may have a wiki page but it's still weird, especially if as an experienced user you start looking on github.com/jenkinsci, or in Jira 18:21:52 But not all users are experienced. 18:22:26 we should probably find out how many and which are actually affected (no Jira component, no jenkinsci repo, no releases in jenkinsci, no wiki page) 18:22:38 Data would be good. :) 18:23:13 wanted to bring this up now primarily to find out whether I'm the only one who doesn't like it if authors do this 18:23:48 I don’t think we should explicitly disallow this, but we can do things to encourage people to use our infrastructure. 18:23:52 FWIW the wiki plugin element also cannot handle it sometimes 18:23:56 I don't like it either. But I think it's an OK compromise 18:24:08 (Like discoverability, etc.) 18:24:12 right, disallowing would be bad. 18:24:38 as I mentioned, an off-by-default 'include plugins not hosted on jenkinsci infra' option to UC 18:24:43 or something similar 18:24:59 (off for new installs only probably) 18:25:13 Call out plugins on https://wiki.jenkins-ci.org/display/JENKINS/Plugins that are hosted externally. Or remove their references entirely 18:25:44 #action kohsuke to improve UC generation so that we can track plugins that do not follow the encouraged hosting guideline 18:26:08 There is something that Atlassian started to do recently with their "marketplace" where they have "Verified" badges that plugins get, among some other badges... not sure how (or if) we could do something similar... 18:27:06 I think we are starting from a better position than theirs because in our case I think the most of the plugin does follow the guideline 18:27:27 I don't know what Atlassian Verified does, but presumably that's a sign of quality (which is different from the topic at hand but still good to do) 18:27:35 I thought about a badge too, but I don’t know what it would actually mean to a user that a plugin is hosted by the community infrastructure. 18:28:58 I think getting data about how many plugins this is true for, and then not including them in the UC metadata are good first steps. 18:29:26 hare_brain: You mean completely remove them? 18:29:44 hare_brain: I took the action to keep track of that, and I wouldn't quite go so far as to remove them from UC, at least not yet 18:29:46 Remove, or not on by default. 18:30:12 But yes, that’s step two. 18:30:16 I want to see which ones would be impacted 18:30:19 Agreed 18:30:48 All right, shall we move on? 18:30:51 yes 18:31:01 #topic GitHub private repositories for security work 18:31:10 I sent the proposal to the dev list 18:31:32 #info the idea is to pay $300/yr to get 10 or so private repositories on GitHub, primarily to be used for Jenkins CERT work 18:31:41 ... which requires developing fixes in private 18:31:42 +1 18:31:50 looks reasonable 18:32:07 Maybe GitHub will even give us special dispensation. 18:32:26 abayer tried that a few years ago but that didn't work 18:32:30 Haha. OK 18:32:40 But anyone knows anybody there, please give it a try 18:32:44 Yeaaaaah. 18:32:57 If we can pull it off, that'd be great, but it just kinda withered on the vine. 18:33:28 And they do already provide us free hosting, so there's that. 18:33:56 $300/year is totally reasonable. 18:34:03 #agreed paying for GitHub private repos is approved 18:34:11 especially when compared to $2k for stickers... 18:34:19 Hahaha 18:34:27 Marketing is important! 18:34:40 I think I misremembered that figure 18:34:49 It's more like 2000 stickers/yr, for $600 or so 18:35:01 But anyway, overall picture remains the same 18:35:03 Yes, I remember that’s more accurate. 18:35:33 Does anyone have any preference on separate org vs same org? 18:35:46 I was going to put this in a separate org 18:35:55 So if you disagree let me know soon 18:36:08 #topic New LTS base line 18:36:09 Probably better to separate, so permissions can be managed independently. 18:36:31 hare_brain: yes, one of the factors is that I'm concerned about bot doing some unexpected things with them 18:37:06 I'm running into problems installing the warnings plug-in using puppet-jenkins v1.2: The package gets downloaded and extracted into /var/lib/jenkins/plugins/ but it does not show up on the web GUI. 18:37:07 #info I'm releaseing 1.565.3 today, which means it's time to pick the new base line 18:37:28 http://jenkins-ci.org/changelog 18:37:35 mark0n: Please wait a few minutes, project meeting right now 18:38:01 I also noted that the most recent version of the plug-in is 4.28 on http://updates.jenkins-ci.org/download/plugins/warnings/ and 4.42 on https://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugin - why is that? 18:38:01 FYI 1.577+ would allow us to bring workflow to LTS users 18:38:22 danielbeck: ok 18:38:31 1.581 issues are completely bogus, just ignore the 3 votes 18:38:57 all recent versions look pretty good IMO 18:39:11 Yes, certainly looks that way 18:39:17 there may be problems with the user name migration, but that's in since 1.568 or so 18:40:09 ogondza: are you there? 18:40:23 jglick told me JavaOne network blocks him from accessing IRC 18:40:31 1.577+ works for me 18:40:46 * ogondza scanning change log 18:40:52 1.580? 18:41:07 final choice now, or do we still have some time to look over issues? 18:41:12 It is the oldest in the recent stability streak 18:41:33 danielbeck: we want to decide now to have room for backporting window 18:41:43 1.581 would shut the X-Frame-Options users up 18:41:57 OTOH we get the background color regression I messed up 18:42:23 but that's an easy fix 18:42:33 I see no reason to go with anything older than 1.580, so ack from me 18:42:46 danielbeck: I think you can just backport fc78fdee 18:43:23 Like ogondza would allow that :-) 18:43:58 :) 18:44:01 danielbeck: is 1.580 OK? Or do you really want 1.581? 18:44:24 1.580 is fine 18:44:29 #agreed 1.580 18:44:43 #topic next meeting 18:45:20 #info next meeting would be Oct 15th 18:45:43 Yep, I'll be here 18:45:50 #endmeeting