18:00:05 #startmeeting 18:00:05 Let the Jenkins meeting commence! 18:00:11 #chair danielbeck kohsuke hare_brain 18:00:11 Current chairs: danielbeck hare_brain kohsuke rtyler 18:00:36 #topic Recap last meeting's actiona 18:00:42 oops *shrug* 18:01:17 danielbeck: I can't speak for you, but I know I haven't had the time to see what amount of OSI-compliance enforcement we can do in Artifactory or elsewhere 18:01:27 me neither 18:01:28 wrt "whether we can ensure OSI-licensed code is being distributed "all the way down" for plugins to comply with governance document guidelines around proprietary code in plugins 18:01:44 I'm going to go ahead and file an INFRA ticket so this doesn't get lost 18:01:49 right 18:01:58 I also didn't tell the guy 18:02:29 heh 18:02:31 can you plz 18:02:47 I will 18:02:54 https://issues.jenkins-ci.org/browse/INFRA-1085 FWIW 18:03:14 ogondza: I'm assuming you pushed the 2.32.3 RC? 18:03:21 yes 18:03:28 yay 18:03:34 #topic LTS status check 18:04:08 The testing is done< have heard no complains 18:04:30 I have been running it for more than 1 week. LGTM 18:04:50 oleg-nenashev: dogfooding it? 18:04:54 yep 18:05:01 when would 2.32.3 be pushed then? 18:05:03 om nom 18:05:14 today 18:05:18 * oleg-nenashev finally has a reasonably big Jenkins instance for testing 18:05:26 #action kohsuke please push 2.32.3 18:05:29 so the release is good to go 18:05:59 anything else on this topic we should cover? 18:06:10 not from me 18:06:23 * ogondza excited about the next one 18:06:29 #topic Pick a new LTS baseline 18:06:32 I think we need a version older than 2.47 due to Groovy 2.4.8 18:06:33 https://jenkins.io/changelog/ 18:06:54 oleg-nenashev one of the storm votes is me, and I think the cloud vote is you? 18:07:07 yes, it's mine 18:07:18 what does "Do not use this version if you are running Pipeline builds unless you also update Pipeline: Groovy to 2.28 or higher." mean? 18:07:32 But we have a confirmed bug, and Pipeline plugins need to be updated 18:07:32 is it refering to that jenkins version or all previous versions? 18:07:38 ogondza https://issues.jenkins-ci.org/browse/JENKINS-42189 18:07:43 ogondza that version specifically 18:07:50 oleg-nenashev can be covered by upgrade guide 18:07:55 ogondza: the Groovy upgrade broke `workflow-cps` 18:08:05 Fix is released in `workflow-cps`. 18:08:26 So FWIW watchers on JENKINS-42189 are the reporter and "us" 18:08:33 danielbeck: But can be be sure this is the only introduced issue in Groovy? 18:08:53 oleg-nenashev no but JENKINS-42189 isn't a big enough deal to base anything on 18:08:54 The update was 10 days ago, maybe there are other regressions we have not seen 18:09:17 oleg-nenashev If we say "We are concerned more things could break", that's fine -- but what we've seen so far seems like no big deal 18:10:02 My opinion is not that strong 18:10:03 Well. I disagree it is not a big deal. But there is a released fix. So I do not consider that a blocker for using 2.47. 18:10:14 jglick … based on actual user feedback 18:10:20 imho 2.47 with appropriate backports would be good 18:10:45 why not 2.48 then? No major changes 18:10:52 What would “appropriate backports” be rtyler? 18:10:53 if we choose 2.47 we could as well go with 2.48 and pick up the new URLs. everything there was pretty minor 18:10:58 And it allows to pick the jenkins.io redirects 18:11:32 I think the big decision here is between 2.46 and 2.48, based on our confidence in the Groovy upgrade 18:11:32 jglick: wasn't there a core change around the groovy thing, or was that just the pipeline plugin updates? 18:12:03 The root cause was in the core 18:12:06 rtyler: 2.47 updated Groovy in core. `workflow-cps` needed an update to avoid regressing. 18:12:07 Isn't 2.48 too new? 18:12:34 a bit too new 18:12:39 jglick: and we would have no way of guarding against core upgrades without a plugin upgrade then right? 18:12:41 according to the previous practices, it's "too new" of course 18:12:46 https://github.com/jenkinsci/jenkins/compare/jenkins-2.47...jenkins-2.48 has nothing but URL changes 18:13:00 s/nothing/barely anything 18:13:01 danielbeck: that's not what the changelog says 18:13:03 heh 18:13:23 and FWIW most of the stuff would be lts-candidate anyway IMO 18:13:38 so if we'd choose 2.47 + backports we could as well do 2.48 18:13:42 Likely yes, including remoting 3.5 18:13:53 I would be more comfortable with 2.46 given the groovy bump does not address anything critical 18:13:56 danielbeck: `DownloadFromURLInstaller` change is nontrivial 18:14:18 we know it broke single plugin that is in the spotlight - god know what else got broken 18:14:35 As is the `ListView` change. 18:14:49 so… 2.46 then? 18:14:51 s/what else/how man other plugins/ 18:15:06 I would prefer 2.46 18:15:13 ogondza: FWIW I doubt the Groovy upgrade would have affected other plugins. Pipeline is just pretty special. 18:15:19 what would backport from 2.47 to 2.46 then? 18:15:29 the windows service restart thing looks kind of notable 18:15:41 and remoting 18:15:42 +/- 18:15:53 #info https://github.com/jenkinsci/jenkins/compare/jenkins-2.46...jenkins-2.47 18:16:04 Windows has some potentially dangerous changes inside 18:16:10 essentially the rest of .47 sounds safe from my pow 18:16:10 if I manage to bribe ogondza, the redirect URLs 8) 18:16:19 ogondza: from my perspective if you're comfortable with 2.46 and backporting from 2.47 the good bits, I'm +1 on 2.46 18:16:49 I think 2.46 is acceptable to everyone here? 18:16:55 +1 18:17:01 +1 18:17:04 so memory leak issue sounds serious. would that be a bckport candidate for .2 then? 18:17:09 for backports from newer releases we also still have two more weeks for soaking 18:17:12 (which seems more risky to me) 18:17:31 oleg-nenashev: was `remoting` 3.5 really in 2.47? 18:17:35 teilo probably not, it's a pretty big minor upgrade to groovy AFAICT 18:17:42 jglick: yes IIRC. Checking 18:17:50 oh, in root `pom.xml`, nvm 18:18:05 (at least until KK's core change lands then we can just patch in whatever we want into LTS…) 18:18:54 as far as I can tell everybody is agreeing on 2.46 as a starting point 18:19:00 yes, remoting upgrade will be the lts-candidate 18:19:01 the specific backports is an exercise for another time IMO 18:19:04 #agree 2.46 is the next LTS baseline 18:19:12 (or is it #agreed?) 18:19:18 seems so 18:19:21 I never remember 18:19:38 according to http://meetbot.debian.net/Manual.html#commands both work 18:19:46 #topic The future of the patron program 18:19:52 danielbeck: you're up buckaroo 18:20:06 #info: https://groups.google.com/forum/#!topic/jenkinsci-dev/-FwdQ-nw7Mc 18:20:21 thanks oleg-nenashev was looking for that 18:20:45 basically, we have the patron program in which substantial donations to the project let donors show messages on the wiki 18:21:11 alyssat_: didn't a number of patrons stop renewing recently? 18:21:23 yes 2 18:21:42 but that can change every quarter 18:21:42 how many active patrons do we currently have? 18:21:53 at the moment is 1 18:22:04 heh 18:22:12 however, recently we started moving content off the wiki -- quite a bit of user documentation and project documentation are already on jenkins.io, developer documentation will be soon, there's plugins.jenkins.io -- so the usefulness to everyone of the current implementation seems questionable 18:22:13 we're crushing it guise 18:22:25 in the current state patroning does not make sense of course 18:22:44 so I propose we either step it up, including issue tracker and/or site, or stop the program 18:22:48 alyssat_: who its the current patron? 18:22:58 JFrog 18:23:01 See https://github.com/jenkins-infra/patron/blob/master/messages.xml 18:23:11 yes JFrog. 18:23:29 CloudBees and XebiaLabs are the 2 on pause at the moment 18:23:36 danielbeck: is it true that the exposure has decreased? That's something measurable 18:24:12 kohsuke: it doesn't matter, we're proactively moving key content from the wiki elsewhere 18:24:25 kohsuke not what I'm saying -- I'm sure the wiki is doing fine. But as we move content out of it, seems weird to limit this to the wiki 18:24:46 FWIW I also expect the wiki to be visited a lot more since we started this 18:25:31 but I haven't checked -- I just noticed that the wiki is no longer where docs go by default, so having that be the one location for the patron program seems weird 18:26:16 Okay, then what's the motivation for us? The agenda says "It doesn't make sense in its current form with the wiki slowly getting replaced", which I took it as "we are no longer giving patrons what they think they are getting, so it cannot continue as-is" 18:26:32 But I guess that's not it? 18:26:34 patron* 18:26:35 :P 18:27:14 Is the point more like "we only have one patron now and maybe it's not worth the effort"? 18:27:17 I'm on the same wave-length as danielbeck here, I think we should shutter the patron program, or retool it to expose patron content across more properties 18:27:35 the latter option to me only makes sense if we were going to see more than one patron come back 18:27:39 kohsuke even if the absolute numbers are up from when we started this, I expect the relative numbers (all page views or however this is measured) to be lower, and keep getting lower, as documentation lives on jenkins.io, GitHub, etc. 18:28:10 I would rather vote for second if we can do it more or less easily (e.g. Documentation and Blog pages) 18:29:50 at this point, I would like to not-volunteer to do the design work necessary to make those ugly little boxes fit seamlessly into jenkins.io or JIRA :P 18:30:07 I guess I don't understand why the relative number matters, especially if we are not hearing from patrons themselves that this is a problem. 18:30:26 We seem to think the actual exposure is getting bigger because the total pie is getting bigger 18:30:40 kohsuke well, we're down to one right now… 18:30:56 kohsuke: how much of 2017 revenue can we expect from the patron program? 18:31:15 If the point is "the whole thing is not worth it if just for one patron" that's something I understand, and I asked that above 18:31:19 at minimum we could have 1 patron a quarter 18:31:50 this is another thing that invariably danielbeck, alyssat_, and I seem to end up maintaining, and if it's not putting money in the bank, I would rather have less of these superfluous things to do 18:32:49 So I don't have the exact tally but the donations from patron represents a large percentage of the total donations 18:33:06 OTOH it's not that we are in need of money ATM, and in the past when we did some fundraising drive, the community responded well 18:33:19 right, but according to rtyler we have costs of ~2k per year and have >20k in the bank 18:33:36 danielbeck: can we punt this perhaps until next time and collect better numbres and provide a clearer proposal on shuttering or retooling? 18:33:42 although I only have treasurer reports from SPI, so that's an incomplete picture 18:34:04 I'll provide the numbers for 2016 & 2015 18:34:20 alyssat_ any idea when patrons typically donate? Do we have 2 weeks before that? 18:34:25 #action kohsuke to provide treasury numbers for 2015 and 2016 18:34:36 It's not like we are getting donations in 100s 18:34:46 danielbeck: sometimes it right before the quarter 18:35:09 not necessarily 2 wks before 18:35:29 okay 18:35:46 perhaps we can manage to conclude this on the dev list anyway once we have more info 18:36:13 shall we move on? 18:36:18 #action danielbeck to drive the patron program discussion further on the dev list for now 18:36:36 #topic Obtain clearance on trademark usage "CloudBees Jenkins X" 18:36:57 Some context from way back when, from the first time we first discussed the trademark approvals for CloudBees 18:37:10 #info kohsuke's original trademark grant proposal https://gist.github.com/kohsuke/573cb5620fcc25c9e5c0 18:37:29 #info the meeting where we discussed it http://meetings.jenkins-ci.org/jenkins/2014/jenkins.2014-11-26-19.13.log.html#l-66 18:37:44 #info and of course the wiki page covering current usages https://wiki.jenkins-ci.org/display/JENKINS/Approved+Trademark+Usage 18:38:05 this wasn't really a proposal from me, it was my attempt to capture the consensus during the meeting so that we can put this motion to a vote, which passed 18:38:25 okie 18:39:04 the proposal that alyssat_ and I wanted to put forward was to grant CloudBees more leeway on renaming and switching their marketing around the use of "CloudBees Jenkins $Foo" 18:39:23 rtyler for non-empty $Foo ? 18:39:33 I would add, with much stronger enforcement of our trademark guidelines, which CloudBees Marketing has been doing better with since two meetings ago 18:39:42 danielbeck: good question! 18:39:58 It still may be "CloudBees Jenkins Open-Source Solution" or "CloudBees Jenkins Automation Server" 18:40:10 alyssat_: I think restricting the grant from a bare "CloudBees Jenkins" is a good restriction, what do you think 18:40:25 as in, it *must* always be CloudBees Jenkins Something 18:40:35 +1 18:41:07 -1 on such proposal if there is no blacklisted names defined by the community 18:41:24 #info the proposal is then to loosen the restriction on approved trademark usage for "CloudBees Jenkins $X" with no allowance for bare "CloudBees Jenkins" 18:41:28 oleg-nenashev: blacklisted names? 18:41:39 rtyler It still may be "CloudBees Jenkins Open-Source Solution" or "CloudBees Jenkins Automation Server" 18:41:39 rtyler: See the examples above 18:42:14 hm 18:42:59 "CloudBees Jenkins Open-Source Solution" there seems contradiction in this name :P 18:43:04 hebh 18:43:10 I think oleg-nenashev's point is valid 18:43:51 I would prefer "CloudBees Jenkins Enterprise .*" or whatever else. Just to have additional word 18:44:06 Or a blacklist from our side 18:44:36 As security officer, I don't think blacklists are great 18:44:49 so how about we say "no using phrase 'open source' and if verbiage may result in user confusion between Jenkins and CloudBees Jenkins X, CLoudBees has the responsibility to proactive discuss in a project meeting?" 18:44:54 danielbeck: heh 18:45:02 yeah CloudBees Jenkins Rules :) 18:45:14 does not make difference compared to the current approach 18:45:20 oleg-nenashev: sure it does 18:45:57 "CloudBees Jenkins Engineer" was what originally motivated this discussion between alyssat_ and I 18:46:10 CloudBees Jenkins Training is something else I can imagine 18:46:31 "CloudBees Jenkins Engineer" is a member of "CloudBees Jenkins Team", right? :D 18:46:41 heh 18:46:50 rtyler there is no meta-term for "all the things CloudBees sell" is there? So it could just be CloudBees Jenkins Metaterm Engineer? 18:46:52 Hmm the latter isnlt a violation if you use the apostophe "CLoudBees' Jenkins Training" 18:46:58 BTW those certification related name usages are discussed as a part of the certification discussion in this venue 18:47:02 and a small "t" 18:47:26 * rtyler facepalms 18:47:39 teilo: always nice to have you awake for these :P 18:48:47 So, what would be the proposal then? 18:48:53 I don't think we are going to resolve this in the remaining 12 minutes. I suggest we move on 18:49:10 I think the GSoC update is quick :-/ 18:49:10 #action rtyler to come up with a more concrete proposal based on this meeting's feedback 18:50:07 oleg-nenashev: I'll have to think of how to properly define updated guidance in a way that gives CloudBees some leeway while avoiding confusion and potentials for abuse of the Jenkins trademark 18:50:26 rtyler: thanks! 18:50:31 #topic GSoC 2017 update 18:50:42 #info Jenkins project has NOT been accepted to GSoC 2017. We are waiting for the feedback from Google about the decision reasons 18:50:58 Ouch, that's too bad 18:51:09 the responsibility rests on us here 18:51:15 I sent org admins some thoughts already 18:51:27 #info After dozens of emails and blog posts we got 3 project ideas 18:51:31 IMHO we didn't deserve GSoC, we had lackluster participation by potential mentors 18:51:46 agreed 18:52:11 I just want to thank oleg-nenashev for the effort he put into this year's submission 18:52:20 ditto 18:52:27 thanks! 18:52:27 we did put together a good proposal 18:52:36 though I'm still very dissapointed 18:52:47 ... and others who also helped that effort 18:52:48 HOWEVER, this should prevent us from making contribution easier 18:52:58 And I think it correlates well with the number of people at the Governance meeting 18:53:10 I think we should consider making a sprint before the summer to ease the learning curve for contribution 18:53:22 (see also danielbeck's developer docs effort) 18:53:30 rtyler kohsuke: I am working on several proposals for the onboarding process 18:53:31 "HOWEVER, this should prevent us from making contribution easier" huh? 18:53:42 danielbeck: the lack of students coming in 18:53:54 rtyler is there a "not" missing? 18:53:56 danielbeck: last year students forced us to write some documentation and revisit some developer on-boarding things 18:54:01 correct 18:54:06 i type god 18:54:07 We rather need commercial companies than students 18:54:09 :) 18:54:15 oleg-nenashev: when you say we got 3 project ideas, are those from students? 18:54:27 kohsuke: From potential mentors 18:54:35 IOW, assuming parties are interesting/willing, is there a way to do this outside GSoC? 18:54:41 OK, then scratch that 18:54:45 We have not reached the student application phase 18:55:03 kohsuke: I was against accepting project ideas without mentorship volunteers this year 18:55:18 last year we had a TON of ideas, and then when it came time to mentor students, lots of nothing :( 18:55:28 I even went panhandling in my company in order to find some mentors :( Also failed 18:55:52 heh 18:56:03 anything else we should cover here? 18:56:07 So yeah, we need to do something 18:56:25 GSoC troubles are a contribution canary-in-the-coal-mine IMO 18:56:32 would it help for us to have more Jenkins exposure in colleges? 18:56:39 #action oleg-nenashev to write the proposals 18:57:01 alyssat_: perhaps, any and all new blood in the project is good :) 18:57:15 exactly 18:57:29 But we failred on this year anyway 18:57:43 Shall we wrap up? 18:57:48 yep 18:57:54 #topic Next meeting 18:58:02 beware the ides of march 18:58:10 looks like March 15 will be next up 18:58:23 same time, same place, yada yada 18:58:25 #endmeeting