18:00:06 #startmeeting 18:00:06 Let the Jenkins meeting commence! 18:00:10 #chairs danielbeck hare_brain kohsuke rtyler 18:00:19 every time 18:00:23 #chair danielbeck hare_brain kohsuke rtyler 18:00:23 Current chairs: danielbeck hare_brain kohsuke rtyler 18:00:24 Yay 18:00:48 #info agenda https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda#GovernanceMeetingAgenda-June22meeting 18:00:53 #topic last meeting actions 18:01:01 I'm in the middle of a production firedrill so not really paying attention here today. 18:01:05 rgr 18:01:12 good luck! 18:01:26 ogondza likely isn't going to be here either, but he mentioned on the mailing list that the RC for the next LTS should be ready to go 18:01:31 see the dev list for more info there 18:01:46 danielbeck has prepared the new patron messages for approval, we'll get to that later 18:02:10 and batmat and I did discuss some usage statistics/census concerns that danielbeck had last meeting, which we'll also revisit later 18:02:16 that's it for our outstanding action items though 18:02:29 #topic LTS status check 18:02:39 I guess we just did that 18:02:49 I was going to add some things 18:03:05 #info JENKINS-35641 and JENKINS-34923 were not backported according to oliver, he wishes for them to have more soak-time 18:03:27 #info at ogondza's next available time, he intends to cut the first new LTS RC 18:03:33 The LTS backports LGTM 18:03:37 any questions or other discussion items we have here? 18:04:17 nope 18:04:22 * rtyler waits patiently 18:04:33 #topic GSoC status check 18:04:36 oleg-nenashev: all yours 18:04:58 #info Tomorrow we have mid-term presentations by students: https://jenkins.io/blog/2016/06/21/gsoc-midterm-presentations-ann/ 18:05:24 #info: 4 projects will be presented. We have 2 meetings on June 23 and June 24 18:05:52 No other major updates right now 18:06:06 Is it fair to say you are looking for people there to send more love to students? 18:06:35 what does that even mean 18:06:43 #info Mid-term evaluation deadline is June 27. And yes, we are looking for more participants from the developer community 18:06:46 encouragement, praise, appreciation, etc 18:07:24 oleg-nenashev: anything else? 18:07:31 no from my side 18:07:37 alrighty 18:07:39 Are there any other updates? 18:08:31 3 18:08:32 2 18:08:34 1 18:08:36 0 18:08:41 #topic Security officer update 18:09:00 danielbeck: isn't really here to give much of an update, but I asked him earlier, outside of the security advisory from earlier this week there's nothing to report 18:09:15 #topic Events officer update 18:09:19 alyssat: you're up 18:09:38 1) Jenkins World planning is in full swing. Agenda has been posted 18:09:48 #info Jenkins World Agenda: https://www.cloudbees.com/juc/agenda 18:10:04 2) There are currently 135 registrations. 18:10:18 3) We are also planning a Contributor Hackathon for Sept 16 & 17 18:10:34 4) At the conference there will be Ask the Experts booth – I have about 14 folks to man this booth. Not all will be at the booth at the same time, of course. But if anyone wants to connect w/ the attendees and provide Jenkins support to attendees, pls let me know. 18:10:35 nice 18:11:01 Will we have more space at the booth this time? 18:11:05 5) a contributor/JAM leader appreciation evening is also being planned for Sept 13 18:11:22 JUC London was really crowded on breaks 18:11:41 JUC Israel is currently sold out 18:12:09 * kohsuke tests lag 18:12:19 JAM activities is going well. JAM Paris was created this morning 18:12:44 I think those are the high lights 18:12:54 JAM Belarus has been created yesterday 18:13:06 sweet 18:13:11 alyssat: see oleg-nenashev's question? 18:13:30 Outside the common org. Maybe alyssat wants to negotiate with KostyaSha on it 18:13:47 ah! yes! we'll have a much bigger space this time 18:13:52 yey 18:14:48 oleg-nenashev: what did you want me to negotiate w/ KostyaSha about? was it JAM Belarus? 18:14:57 yep 18:15:00 #info There will be a Contributor Summit at Jenkins World on tuesday the 13th 18:15:18 that will follow a similar pattern to the previous Contributor Summits we have had at FOSDEM, etc 18:15:27 oleg-nenashev: we can chat more off line 18:15:40 any other events things to discuss/update? 18:15:41 agreed 18:15:50 I have another minor update. Jenkins community has been in http://2016.secr.ru/lang/en/ - one of the biggest software conferences in Russia. 18:16:04 neet 18:16:11 #action: oleg-nenashev to follow-up on SECR in the mailing list 18:16:28 * has been invited to participate 18:16:34 Sorry for confusion 18:17:07 alyssat: that it? 18:17:17 we should get the meetup page for the Contributor Summit up shortly 18:17:26 cool 18:17:27 * rtyler nods 18:17:28 this it 18:17:32 And for hackaton? 18:17:52 that one is not ready yet 18:17:56 I think we'll need to manage that outside of meetup.com to be honest 18:18:04 okay, makes sense 18:18:07 the hackathon is for those who attended the fosdem summit 18:18:18 since CloudBees was going to fund some lodging and foodstuffs, the inaccurate RSVP counts for meetup can be a problem 18:18:29 but still much to be decided there 18:18:48 moving on 18:18:51 #topic Release officer update 18:18:59 ogondza is not here, so no updates here 18:19:02 #topic Infra status update 18:19:15 * rtyler pulls out his spiral notebook 18:19:24 #infra JIRA has been upgraded to JIRA 7 18:19:25 er 18:19:31 #info JIRA has been upgraded to JIRA7 18:19:45 this makes all our softwares more agile, or something :) 18:19:52 much fall out from that 18:20:01 an unintended side-effect of this was that the SOAP API was nuked in JIRA7 18:20:02 Requires some fixes 18:20:11 and I wasn't previously aware of how much relied on that SOAP API 18:20:18 which had been deprecated in JIRA 5 iirc 18:20:20 * rtyler sighs 18:20:33 * oleg-nenashev is working on IRC bot fixes 18:20:41 \o/ 18:20:51 I've updated lib-jira-api so hopefully it'd be useful 18:21:11 It took me a while to assemble the right dependencies. Atlassian's own documentation is outdated. 18:21:18 I'm not sure what's depending on that, but from what Ican tell the services that interact with JIRA are: 18:21:21 accounts app 18:21:21 ircbot 18:21:23 abayer also fixed some stuff on this front 18:21:26 some release process 18:21:30 I thnk that might be it 18:21:34 #info https://github.com/jenkinsci/lib-jira-api 18:21:43 OH, the SCM linker bot thing, which runs on a kohsuke machine somewhere 18:21:48 #info https://github.com/jenkins-infra/ircbot/pull/29 18:21:49 is the account app fixed? The account sync thing? 18:21:52 there's an old SPoF ticket somewhere in the backlog associated with that 18:21:55 danielbeck: yes 18:22:13 We have a problem with JIRA Scraper 18:22:20 OK, thanks for that heads up rtyler 18:22:24 I'll fix that one 18:22:27 It also uses some old Atlassian libs 18:22:33 What's JIRA scraper? 18:22:49 #info https://github.com/jenkinsci/lib-jira-scraper 18:22:58 ah 18:23:02 REST Client for particular JIRA commands 18:23:28 The libs beneath are not compatible with modern atlassian libs. Reworking it in IRCBot 18:23:31 suffice it to say, there's still some legacy messiness which the JIRA7 upgrade uncovered, which is still being fixed 18:23:38 * rtyler continues with his update 18:23:49 #info we have Azure 18:23:56 \o/ 18:24:01 (with all that said, congrats to update of JIRA) 18:24:12 since the last meeting the actual credentials/API tokens for the Jenkins project have been 'delivered' which means we can start spinning up infrastructure on azure 18:24:23 \o/ 18:24:27 my working document for migration is here: https://wiki.jenkins-ci.org/display/infra/Azure+Migration+Project+Plan 18:24:40 I haven't had the time to work on it for the past week or two unfortunately 18:24:43 #info https://wiki.jenkins-ci.org/display/JENKINS/Azure+Migration+Project+Plan 18:24:48 (infra wiki is restricted) 18:24:49 er, whoops 18:24:54 that page was moved anyways 18:25:00 stupid autocomplete in my browser :) 18:25:23 Do we have an EPIC for this plan? 18:25:32 maybe too early 18:25:34 no 18:25:38 I think it's probably too early really 18:25:52 * oleg-nenashev agrees 18:25:52 I have some basics of /what/ needs to be done, not quite scoped out enough on /how/ 18:26:15 the first 'thing' that azure is likely going to resolve thouhg, is this ticket about windows agents for ci.jenkins.io https://issues.jenkins-ci.org/browse/INFRA-606 18:26:29 No wonder 18:26:43 because hey why not :) 18:26:47 Good start with this document in any case. thumbs up 18:27:11 if there are any volunteers who want to start researching terraform (https://terraform.io) and azure integration with me, I would appreciate any help 18:27:23 that's about it for my update, any questions before we move on? 18:27:46 * batmat is pondering that 18:27:59 terraform is bit painful to be used by a team due to lack of state sharing 18:28:19 ... unless we also use their state sharing service (atlas?) 18:28:37 define state sharing 18:28:48 I can take this off-meeting with you 18:28:49 also, are you volunteering to help research the viability here 18:28:59 or just throwing opinions out there?: P 18:29:11 I'm sharing my experience of using it 18:29:50 the high level requirement is that resources (load balancers, machines, databases, etc) will need to be managed more explicitly then they are now if we're to be successful on Azure 18:30:07 terraform is one potential possibility there, as is "out of the box" Azure Resource Manager templates 18:30:40 (i'm sure there are other lolzy options too) 18:30:58 but anyways, plenty to be discussed in #jenkins-infra or the mailing lists on this front 18:31:08 * rtyler continues through the agenda 18:31:30 #topic Licensing and unrestricted access of Usage Statistics (aka "census data") 18:31:39 we discussed this last meeting, but unfortunately batmat wasn't here 18:32:01 and there were some additional questions by danielbeck which needed to be answered before we move forward 18:32:27 batmat: I hope you're awake now! :) 18:32:50 #info http://lists.jenkins-ci.org/pipermail/jenkins-infra/2016-June/000770.html and the thread preceding it 18:32:51 I was awake last time too! just not in front of the computer :) 18:33:05 heh 18:33:25 to sum up, all this originally comes from JENKINS-26466 18:33:34 https://issues.jenkins-ci.org/browse/JENKINS-26466 18:33:40 hence trying to extract things from the core, here node_monitors 18:33:47 I unforrunately haven't had a chance to respond to your email here batmat, i'm still believing that we have a semaphore here where only one side can go 18:34:27 cf. an older thread abt it, where jglick (among more people) both encouraged going forward with it, and advised abt that design 18:35:11 Extension point to allow arbitrary plugins to submit arbitrary data looks risky 18:35:11 well, I guess I'm not gonna revamp what's the in email above... Already explained I guess. Prolly simpler to answer possible questions here? 18:35:15 if there ar 18:35:18 *are 18:35:47 kohsuke: well, as I say, some plugin *already* do. Just outside that channel 18:35:57 frankly, any form of uncontrolled usage statistics reporting presents potential issues for infrastructure where that data is being reported 18:36:10 in addition to the data security questions 18:36:25 obviously 18:36:25 batmat: I'm less concerned with plugins reporting data to wherever they want outside of projcet infra 18:36:50 that doesn't have the potential to corrupt usage stats or explode our disk usage requirements 18:36:57 Well, I'm not that attached to JENKINS-32485 18:36:59 FWIW we're already well into "can browsers actually handle it?" URL length with existing usage stats 18:37:09 it was just a way to decouple things for 26466 18:37:09 heh 18:37:16 So we may need to look into a different submission mechanism sooner than later 18:37:33 so here's what I think can move us forward 18:37:38 (For reference, it's a GET request with a giant query string) 18:37:46 Because extension points are the standard to inverse control in Jenkins... 18:38:12 the original agenda item, as I had proposed it was to both license the data and remove access controls 18:38:48 it's clear to me that it's time to revisit the design and implementation of usage statistics reporting, but I'm not sure I want to tie these two things together 18:39:15 what about "only one side can go"? 18:39:21 I think batmat's changes are in the right direction there, but without the corresponding design changes on stats submission, and infra requirements, that work (IMHO) cannot be successfully merged 18:40:05 danielbeck: that's where I'm getting to ;) 18:40:14 k 18:41:17 my proposal is that we license census data under the Open Database license (http://opendatacommons.org/licenses/odbl/1.0/) and based on the census data being reported by Jenkins instances right now, remove access control for census data, subject to revisions on handling the newer goals/requirements for usage stats submission by batmat 18:41:49 (for example, we could just create a separate 'channel' for these "untrusted" usage stats, and restrict access there at a future date) 18:43:38 FTR I still think it's a bad idea to allow plugins to report arbitrary data to usage stats. We can't stop plugins from doing that through other means but we shouldn't endorse that. 18:43:56 The node_monitor split into plugin can be solved without opening it up to everyone 18:44:23 And I'm +1 on licensing census data & remove access control 18:44:28 that aspect of the discussion is why I'm trying to separate these two a bit 18:44:48 kohsuke At least by going that way we can encourage plugins to respect the usage stats opt-out. Which at least one currently doesnt'. 18:44:50 I wish to tackle the data we have, not the data we may have :p 18:45:22 My concern is that this will result in an insurmountable obstacle to implementing extensible usage stats and we then don't get it 18:46:10 I am already a fairly insurmountable obstacle to extensible usage stats submission :p 18:46:13 if we're open to, once other concerns there have been addressed, again revoke access to stats data to pave the way, that would be fine 18:46:31 Are there other use cases for "extensible usage stats"? 18:46:36 I'm open to restricting *other* data sets 18:46:49 danielbeck: my hope is that we can start thinking about this as layered datasets 18:46:53 instead of a single big bucket of data 18:47:10 kohsuke: WDYM? other use cases? 18:47:21 this perceived conflict is really only an issue if we cannot stratify our usage stats datasets 18:47:40 kohsuke: some plugins are already reporting stats outside that channel, so there are definitely use case for user stats 18:47:43 batmat: I understood yours well, which is a desire to split node monitors into a plugin 18:48:21 kohsuke: as danielbeck said too, this would also help respect the opt-in/opt-out choice, and streamline all 18:48:29 I've also come across one plugin in that past that uses Google analytics to track who's using it, and I thought that was problematic. That's what I think of when I think of "extensible usage stats" 18:49:10 Anyway, I think I'm getting off topic 18:49:30 kohsuke: maybe it's still the same one, but there's definitely at least one doing that now. Anyway, I'm not that much all for it 18:49:32 I think rtyler is trying to narrow this down to the current usage stats data set to make a progress 18:49:41 * rtyler nods 18:49:52 I live in the present ;) 18:49:54 I agree we need to think about the whole to accept different data on the collection side 18:50:40 batmat: so are you okay with my proposal on licensing and access control on our existing dataset, and the action item to evaluate new datasets differently as necessary? 18:52:01 anybody else care about this? :P 18:52:02 not sure I get what that means globally, but I think yeah. I think I'm gonna close that PR for now, since I've been working on it for too long and it's best to just forget about it until we decide we want to tackle that subject. And try maybe to attack JENKINS-26466 another way. 18:52:41 copy/pasta was one way... But we chose to try and avoid it :) 18:52:41 batmat: I would want to be involved in any future design discussions about usage stats that would be reported into project infra 18:52:51 danielbeck: your thoughts? 18:53:35 still not sure it's worth it to open up stats 18:53:52 well then let's turn this off 18:54:01 haven't seen one concrete use of it (besides Payal's project I suppose) 18:54:17 domi's original stats.jenkins-ci.org work was based on census data access 18:54:21 * batmat would then like to have opinions on how to decouple the current cycles in the code for JENKINS-26466 ;) 18:54:35 we cannot expect to see interesting hacks or visualizations on the data otherwise 18:54:36 vivekp's extension point & implementation analysis is another, right? 18:54:43 * rtyler nods 18:55:07 And if anything I thought the motivation was it's easier to open it up than lock it down & access control 18:55:08 haven't seen any results from that. It's not on stats.j.o 18:55:24 kohsuke: correct 18:55:34 also, closed stats is antithetical to what we should be doing imho 18:55:45 so to me the question is "is it worth closing down stats" 18:55:56 they're already closed. 18:56:20 somewhat half-heartedly 18:56:43 * rtyler looks at the time 18:56:51 is your concern that there might be undesirable data leak? 18:56:52 and since I haven't seen a single use of the stats from anyone who isn't a contributor to Jenkins and would have got personal access by asking us, I wonder what the point is 18:57:15 the easiest access control is no access control 18:57:51 which raises the bar for stats extensibility for no tangible benefit 18:58:05 well, I give up for today 18:58:07 so if I'm the only critical one, so be it 18:58:08 rtyler: I think we need to have further discussions on this 18:58:13 if we're going to shut down stats, then everybody can lose access 18:58:28 I don't think this needs to be unanimous, so you can probably go ahead. 18:58:32 or somebody can propose an actual non-stupid access control policy that isn't just a "gotta-know-somebody-to-get-it" 18:58:47 I just don't understand your objections 18:59:24 let's get to patron message approval and we can talk more about this outside the meeting 18:59:37 I don't think there's urgency on deciding this today 18:59:39 rtyler: maybe one way to go forward /a bit?/ abt it is to ask plugins devs? 18:59:53 #topic Approval of new Q3 patron messages 19:00:11 that would make it for today, and next time we might have some feedback abt devs expectations abt it 19:00:15 Q3 is upon us, and we have some minor message updates from the patrons 19:00:16 * batmat is done on that 19:00:18 #info https://github.com/jenkinsci/patron/pull/12#issuecomment-227803082 19:00:44 The first commit was already approved two weeks ago, now we have changes for the CloudBees and JFrog messages 19:00:54 the messages look fine to me 19:00:56 https://github.com/jenkinsci/patron/pull/12/commits/876d31c50f186082ad41210bee55e8ecdd45d8b1 and https://github.com/jenkinsci/patron/pull/12/commits/5ac2ffb196892dcac8c8d884c42df00e15e66fc1 19:01:11 The tester links are up to date with these changes, so you can click the links in the newest comment 19:01:46 in the last approval process for JFrog we had issues w/ "The Only..." this can be removed 19:02:01 LGTM 19:02:43 anyone concerned about one or both of these message updates? 19:02:53 "Free 30 day trial" does feel more advertisement-ish than other typical patron messages, but that's already approved in the previous meeting 19:03:10 * rtyler shrugs 19:03:32 * rtyler looks around for concerns 19:04:03 going going .. 19:04:17 gone! 19:04:23 #agreed Patron message changes are approved 19:04:25 HEH 19:04:29 er, nocaps 19:04:34 #topic next meeting 19:04:41 July 6th looks like our next scheduled meeting 19:04:49 any issues with that? 19:05:01 * batmat is OK 19:05:02 see you then! 19:05:05 works for me 19:05:09 #info July 6 next meeting 19:05:11 #endmeeting