18:00:29 #startmeeting 18:00:29 Let the Jenkins meeting commence! 18:00:36 #chair rtyler hare_brain danielbeck 18:00:36 Current chairs: danielbeck hare_brain kohsuke rtyler 18:00:48 #info https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda 18:00:51 yay 18:01:05 I would argue it's more 8pm actually :) 18:01:08 #topic re-cap of actions 18:01:16 oops, my bad batmat 18:01:36 kohsuke: np, just joking 18:01:47 No progress regarding trademark usage by the jenkins hosting guys 18:02:00 There's actually a long list of actions here: http://meetings.jenkins-ci.org/jenkins-meeting/2015/jenkins-meeting.2015-09-30-18.00.html 18:02:12 But I did update the wiki page to list all trademark approvals so far (that I know of) 18:02:39 I just provided status of 1.-3. 18:02:43 LTS and board role we have upcoming topics for that 18:02:57 OK, let's move on? 18:03:06 #topic LTS status check 18:03:15 we are good to go 18:03:22 Aye aye sir 18:03:37 #agreed 1.625.1 is good to go 18:03:46 #action danielbeck to set up 1.625 update site once the build is up 18:03:51 #topic New Website JIRA project to organize website efforts under 18:03:59 zomg kohsuke you're killing me 18:04:03 refresh your agenda page :P 18:04:07 oh 18:04:11 we can do this topic first though 18:04:23 No, I'll go in the order 18:04:24 #topic Quick announcement of #jenkins-community 18:04:29 rtyler the idea is to add stuff to the end of the list 18:04:29 hah, okay 18:04:30 ;-) 18:04:56 #info #jenkins-community has been created on Freenode to help organize events, documentation and more "meta-conversations" around trhe jenkins project itself 18:05:14 I would like to invite folks interested in building up and expanding the community to join the discussion there 18:05:23 JAMs, blogging, etc 18:05:28 that's all, we can move on now :) 18:05:32 #action danielbeck to update IRC Channel wiki page 18:06:18 kohsuke: next? 18:06:21 Right, this will prevent those communtiy building conversations from getting drawned in the user/support/dev conversations 18:06:40 #topic New Website JIRA project to organize website efforts under 18:06:46 okay so this is also a topic of mine 18:07:02 there's a lot of interest in restructuring and improving the jenkins website 18:07:13 and I'd like to create a WEBSITE project in JIRA to keep all that work organized 18:07:21 comments/questions/objections? 18:07:36 +1 18:07:39 rtyler: probably it's just a part of INFRA 18:07:42 I supppose the idea is that the set of people working on the new website is different from the current infra stuff 18:07:45 looks reasonable, especially if the future site becomes bigger than it's now 18:07:55 right now it's the blog and five links to the downloads 18:07:56 stuff -> staff 18:08:07 rtyler: I'm ok with a new project as well 18:08:11 +1 18:08:12 +1 18:08:18 oleg-nenashev: the folks I expect to be interested in web changes are different from us bearded infra types :P 18:08:32 like, somebody who knows anything about graphic design 18:08:37 probably doesn't care about puppet :P 18:08:41 +0.5 18:08:43 hah 18:08:44 I need to grow some beard to blend in 18:08:56 kohsuke: add it to JIRA 18:08:57 xD 18:09:08 xD# rather 18:09:24 :) 18:09:27 #agreed JIRA will get new WEBSITE project to keep track of the new website project 18:09:31 #action rtyler to create WEBSITE project in JIRA 18:09:39 MOVING ON 18:09:44 #topic Approval of new Q4 patron messages by CloudBees 18:10:04 where's that PR again? 18:10:07 So last time I still thought we could run the same messages in Q4 as in Q3... turns out, not. 18:10:08 https://github.com/jenkinsci/patron/pull/5 18:10:08 * rtyler digs thorugh open tabs 18:10:23 Check out the linked PR, it links to the tester app where you can see the messages 18:10:56 "Templating Jenkins Environments with Docker" is a bit vague, but it's a business of CB marketing 18:11:00 CloudBees is asking us to run these messages in Q4. 18:11:18 * rtyler shrugs 18:11:25 agreed on the vagueness, but it's not a big deal to me 18:11:33 Shrugs as a Service 18:11:34 I think they are OK 18:12:02 They certainly fit the criteria we have, relevant and supportive. 18:12:06 From my PoV, the main thing I'm looking out for is for the message not to be overly advertising or against Jenkins 18:12:14 * rtyler nods 18:12:32 Too much Docker for a HW engineer like me. CB is eligible to do it according to the patroning policy, so +1 18:12:38 +1 on the messaging 18:12:39 Any objections to blessing this? 18:13:19 it'd be nice to get some votes from people outside the payroll of CB 18:13:28 I've not received a paycheck yet so.. :P 18:13:30 does that count? 18:13:50 Going ... 18:14:01 going ... 18:14:08 +1 18:14:09 c-c-c-c-combo breaker 18:14:14 +1 18:14:18 Thanks! 18:14:37 #agreed new Q4 patron messages by CloudBees (https://github.com/jenkinsci/patron/pull/5) are blessed 18:14:49 #topic Proposal - Project sub-teams 18:14:58 #info proposal here https://wiki.jenkins-ci.org/display/JENKINS/Proposal+-+Project+sub-teams 18:15:13 for anybody that hasn't yet seen the document, please take some time to read it 18:15:25 * rtyler thinks we should wait 5 minutes to make sure folks have read it 18:15:30 agreed 18:15:40 kohsuke: did you add your edits this morning yet? 18:15:44 I added LTS and Community teams 18:15:49 Yes, edited 18:15:56 thanks 18:16:14 I can imagine what LTS team does, but what does the community team do? 18:16:18 the high level goal here is to empower leaders within the community to drive their different areas forward 18:16:25 kohsuke: see the document :P 18:16:49 oh wow, this document is changing live 18:17:05 #info I am not proposing team leads at this point, only proposing the structure which will allow team leads 18:17:32 We need somebody to handle incoming requests. I and danielbeck do it right now, but there's no sync in these activities 18:17:38 Do we need LTS or should that be "core"? 18:17:43 the teams that are most important to me to identify are: Security, Website, Events and LTS 18:18:05 IMHO LTS team is a good idea because that gives people in the community a point of contact for the LTS activities 18:18:17 Aren't somehow events & community close? 18:18:35 batmat Very different fields though 18:18:46 I had originally scrapped a team I was calling "Plugins" wihch is what oleg-nenashev refers to as "Community" 18:18:54 They sound similar but the tasks are very different 18:19:00 but I think the "Community" team here, is enabling the developer community 18:19:05 The two tasks for the community team feel very different in nature 18:19:05 My POV is a bit different 18:19:08 whereas events is organizing around developer and user communities 18:19:17 yeah, plugin herding seems like a job of its own 18:19:22 heh 18:19:32 says the man who I would name chief shepherder :P 18:19:50 "Community" team may provide advices for hanging PRs 18:20:00 fine time for work internet to go down 18:20:27 so at this time I hope almost everybody has read through the proposal at least at a high level 18:21:08 I think the community should be empowered to propose new team leadership positions as we see necessary in future project meetings 18:21:17 I would like to see a team responsible for development, be it the one responsible for LTS or separate 18:21:33 ogondza +1 18:21:34 ogondza What would the specific job be? 18:21:46 We have technical tracks for Jenkins 2.0 18:22:03 But some kind of roadmaps would be useful 18:22:06 I think there's two separate parts to this proposal, the notion of sub-teams and then what the actual teams are 18:22:08 I think this is diverging from what I want to get done first in this topic: agreement on the structure and appointment process 18:22:25 True, we can always fine-tune later 18:22:26 I think rtyler is trying to get us bless the former before spending too much on the latter 18:22:27 danielbeck: from last meeting agenda "Time to move to Java 8 and servlet 3.1?" 18:22:35 does not seem to fit anywhere 18:22:54 yep, "roadmaps" 18:22:56 ogondza "Roadmap Team"? 18:22:57 pending PRs, urgent releases, reverts, etc 18:23:01 heh 18:23:07 They could be useful to focus the community efforts 18:23:20 Like that won't result in heads rolling 18:23:22 orrc: I'm curious on your opinion on this in particular, since I've seen you lead some different efforts over the year 18:23:25 years* 18:23:45 jenkinsci/core is supposed to handle PRs. It's not 100% true right now 18:23:53 to me an important aspect of my proposal is sending, basically an RFP, to the commnuity for leads 18:24:04 RFP? 18:24:09 request for participation 18:24:16 sorry, will de-acronym as much as possible 18:24:28 OK, trying to read the doc again now that internet is back. 18:25:36 I think the proposal makes sense 18:25:53 At least I like the problem description, about the fact it's certainly wasteful to ping the board abt subjects of little importance, sure. Do we examples of that btw? 18:26:02 Yep, also +1 from me 18:26:41 rtyler: ${WHATEVER} Officer 18:26:44 haha 18:26:50 or ${whatever} king :( 18:26:53 batmat: yeah, for example to contact SPI & ffis.de 18:26:57 (.*) person 18:27:05 +1. the recent dust-up over a potential security vuln is a good example of how this would be useful. 18:27:21 autojack: that was one of my primary motivators here :P 18:27:28 Right, getting CVE IDs assigned is another one 18:27:33 the concept is basically pilfered in its entirely from FreeBSD 18:27:33 kohsuke: yeah, wasteful and putting ppl on the critical path unnecessarily 18:27:34 :P 18:27:36 +1 for me 18:27:55 hare_brain: are you here? 18:27:56 rtyler: free-what now? is that some kind of open source thing? 18:27:57 ;) 18:28:02 my hope is that we can extend the "executive authority" to domain specific leaders who may be more qualified and more able to react such as Security in paritcular 18:28:09 autojack: I heard it was dead :P 18:28:15 lolz. 18:28:20 as it's my proposal, I'm obv. +1 on it :p 18:28:21 I think a board blessing this would be nie on this because this is delegating some of your power to others 18:28:28 another term for this type of group that I have heard used is Assembly of Experts. 18:28:31 nie -> nice 18:28:48 +1 on the structure of the proposal/ 18:28:50 although... that might be what they call it in the Iranian government? 18:28:53 +1 18:29:04 OK, my +1 as well 18:29:06 +1 18:29:07 okay, I think it's safe to say we're largely in agreement here 18:29:25 can we agree right now to the need for a Security post at least? 18:29:31 That leaves just figuring out which teams and responsibilities make sense :-) 18:29:34 "just" 18:29:35 autojack: dead for some at least https://twitter.com/randileeharper/status/651483473392234500 18:29:35 yes, +1 to security post especially. 18:29:41 I would like to get started on Security, Infra and Events ASAP 18:29:51 and +1 for community. I have tried to help out in that area over the years. 18:29:53 (infra is me though, :/) 18:29:54 #agreed the subteam structure is blessed as of versrsion 10 of https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=82674793 18:30:00 thakns kohsuke 18:30:10 +1 for security 18:30:38 #action rtyler to work with the rest of the board to create a request for participation for a Security team lead 18:31:29 As a board member I'd like to see the events team up & running toward FOSDEM & SCALE 18:31:30 I think we should flesh out responsibilities of Security team lead, and others in separate documents 18:31:49 kohsuke: I agree on that, so those don't crush me :P 18:32:02 Security, events and infra should be pretty straightforward wrt responsibilities. 18:32:04 Those things do require a lot of external coordinations where a clearly marked responsible person really helps 18:32:10 alyssa__: could I ask for your help to define the Events team lead responsibilities? 18:32:24 then we can go thorugh the team lead proposal process once that's defined? 18:32:28 rtyler: sure thing 18:32:48 I'll create a page nuder the governance document for team lead specifications 18:32:51 er 18:33:00 heh 18:33:02 #action rtlyer to create a page under the governance document outlining the team leadership responsibilities 18:33:05 GAK 18:33:08 I CAN SPELL MY NAME 18:33:12 no? 18:33:14 #action rtyler to do that thing up there 18:33:20 <>_< 18:33:37 LTS & infra are existing functionalities that I think we should be able to bless more formally with this new structure 18:33:49 if there's no objections, I'll put together the infra team lead responsibilities 18:34:14 kohsuke: who can define the LTS team leadership role? 18:34:14 If i'm not mistaken, I think we are all pretty clear what we do in those spaces because we've been doing it for so long 18:34:22 ogondza? 18:34:27 that works for me 18:34:32 yeah, sure 18:34:35 but kohsuke usually do decisions about lts? 18:34:39 +1 18:34:40 rtyler: as an aside, if you need help with infra support, I might be able to contribute. 18:34:45 #action ogondza to define the LTS team leadership role 18:34:53 autojack: are you in #jenkins-infra? 18:35:01 +1 for ogondza 18:35:32 bear in mind, we're just defining teams right now, the board will follow the process outlined in the proposal above 18:35:58 so we've got somebody to define Security, Infra, Events and LTS 18:36:04 I'm happy with that for now TBH 18:36:21 that's already plenty of work :P 18:36:31 I agree, is that OK oleg-nenashev ? 18:36:41 Can we come back to some of the other teams you proposed later? 18:36:57 +1 18:37:10 rtyler: no, but I can be. 18:37:21 orrc: would you mind pondering some of the plugin/community responsibilities in the meantime 18:37:39 Should we move on to the next topic? 18:37:46 I think you and oleg-nenashev could/should work together to collate responsibilities there 18:37:47 rtyler: orrc: I would be interested in talking about that too, pursuant to my comments in #jenkins earlier today. 18:37:53 * rtyler nods 18:38:00 kohsuke: yes, no need to handle everything now 18:38:08 kohsuke: I am fine moving on 18:38:12 thanks for the input folks 18:38:28 #info autojack orrc oleg-nenashev will get together to ponder plugin/community responsibilities 18:38:35 #topic Permission request - Admin access to jenkinsci org 18:38:43 what does this mean? :P 18:38:45 I assume you mean the github org, oleg-nenashev 18:38:46 this is mine 18:38:48 GitHub org 18:39:00 AH 18:39:01 Lost something in the meeting agenda 18:39:07 See the e-mail thread 18:39:13 oleg-nenashev: which thread? 18:39:19 what access is needed here/why? 18:39:29 https://groups.google.com/forum/#!topic/jenkinsci-dev/pFWSnJ3uHFU 18:40:25 +1 to this 18:40:39 Yeah, given his involvement to plugin onboarding work, let's unblock him 18:40:40 danielbeck: you had some questions last week about updating the github org ACLs and way we handle things right? 18:40:48 Already gave my +1 in the email thread, echoing here 18:40:54 rtyler Out of scope for today I think 18:40:57 And he has CLA in place, so there's that. 18:41:12 +1 for Oleg's request 18:41:14 definitely out of scope, but I'm thinking perhaps the two of you could work on a proposal for how to make this work go away or easier in the future 18:41:15 oleg-nenashev: thank for volunteering for this job 18:41:24 rtyler Will do 18:41:40 rtyler FWIW I added an agenda item that kind of already does 18:41:40 very happy to have people volunteering for work, but if we can make the work go away, even better :) 18:41:50 that's coming to the next topic 18:41:57 It's my responsibility to deal with that jenkins-admin, because I too lazy to fox it :) 18:42:01 +1 and thanks to oleg-nenashev 18:42:12 #agreed on granting oleg-nenashev github org admin access 18:42:15 kohsuke: next! 18:42:19 #agreed oleg-nenashev will step up to more github repo house-keeping work & get admin access to the org for that 18:42:30 #topic JIRA project for plugin hosting (and possibly similar) requests 18:42:45 Yes, another guy 18:42:49 So Oleg and I discussed recently the problems we have with plugin hosting requests 18:42:50 danielbeck: would this just be moving this out of the mailing list? 18:42:55 and IRC channel? 18:43:01 Kinda 18:43:09 + workflow improvement 18:43:17 For now. A big problem is that we miss some requests 18:43:27 especially when they're not immediately resolved 18:43:28 The idea is to use JIRA workflow to avoid missing requests 18:43:33 that should stop with the project 18:43:39 +1 18:43:42 yeah, that makes a lot of sense to me 18:43:42 +1 18:43:55 Moving requests into Jira would still not automate, but it would make it basically impossible to lose some 18:44:03 +1 18:44:06 and better to have an audit trail for the discussion I hope 18:44:11 Can someone create a custom project with custom field & all that? 18:44:11 BTW the automation is also possible 18:44:23 issue might be: how do discuss usefulness/possible duplicate as now? 18:44:33 IIRC danielbeck has already created the project 18:44:41 Or worse https://groups.google.com/forum/#!topic/jenkinsci-dev/bMXeWrOyEN4 18:44:56 batmat: we could notify jenkinsci-dev on new issue creation in that project 18:44:57 batmat We can email jenkinci-dev when an issue gets created and resolved 18:45:07 nothing in between, just those two 18:45:10 zomg ur so smart danielbeck 18:45:11 danielbeck: rtyler yeah right 18:45:22 -0.5 on the noise 18:45:28 ogondza Less than today 18:45:39 is the resolved mail necessary?' 18:45:43 I'd really like there to be visibility to the dev community 18:45:47 I doubt it's a "noice" 18:45:58 -1 for dev list email 18:45:59 But probably a separate mailing list is better 18:46:02 rtyler Possibly not. I'd consider this fine-tuning 18:46:12 Would also work, but reduce visibility 18:46:28 well, I think at a high level, we need some way to communicate requests to the dev community 18:46:31 danielbeck, you can create separate google group list like for issues 18:46:37 actually, one main with initial request (and possible rejection) sounds good to me 18:46:39 Probably it's also a topic for "Website 2.0" 18:46:45 KostyaSha Nobody ever subscribes to those extra lists 18:46:49 It could display such requests 18:46:56 danielbeck, that's mean that nobody needs this info 18:46:56 s/main/mail/ 18:47:08 can we try the "request created" email to the dev list and see at least if it's better or worse first? 18:47:19 danielbeck, + CloudBees forks plugins without any requests, so monitoring new plugins is impossible via dev list 18:47:22 rtyler looks good 18:47:23 Fine either way. I don't like existing devs turning new people away just because they don't think it's a good idea or there's an overlap. 18:47:31 every third mailing list thread is about new hosting anyways 18:48:02 KostyaSha: I think the right expectation to set here is that all such requests go through JIRA 18:48:06 And that's not inconsistent with us suggesting related plugins to consolidate or encourage communication between them 18:48:08 wihch would be better IMO 18:48:14 KostyaSha: It's a very orthogonal topic, because every jenkinsci/core member is eligible to do it. BTW it's reasonable complain in particular cases 18:48:17 rtyler, imho just don't flood mail list 18:48:31 * rtyler nods 18:48:39 KostyaSha Two emails per request is strictly less than today 18:48:44 does this mean we should restrict who can fork via jenkins-admin? 18:49:12 I thing that there shouold be at least one email on the dev list when the request gets done or created? 18:49:13 rtyler I think it should suffice to define a process. If we know we should not fork without request in Jira, we won't. 18:49:13 rtyler: my operating principle is that we should be free to create new plugins 18:49:14 if we were to create oleg-nenashev's community team, I would expect members of that team to be responsible for that forking 18:49:24 rtyler: kinda 18:49:45 rtyler: I doubt it should be too restricted, but who knows 18:49:49 kohsuke's principal = make bazaar from project 18:49:56 kohsuke: nobody's stopping you from making a plugin, but this does consolidate hosting inside of jenkinsci which is IMO reasonable 18:50:14 kohsuke: I see your point, but I tend to disagree some review/encouraging to merge efforts is not good. 18:50:25 rtyler, you can't also limit publishing into repo + UC, so limiting fork wouldn't make anything. 18:50:47 batmat: I'm all for *encouraging* consolidation, so long as that's not used as a reason to block somebody 18:50:50 and we started this discussion from danielbeck's idea to post JIRA issues about plugin requests 18:51:03 IMO, it's somehow not beneficial to users to have 3 or 4 plugins that generally only have parts of the picture, and IMO OSS is also about collaboration. So that's a pity 18:51:14 I think we're going off track here right now 18:51:14 +1 18:51:18 heh, true 18:51:26 batmat, i said the same about cloudbees-docker-* but kohsuke likes it 18:51:44 and it other topic 18:51:45 it seems this is something we'll need to discuss at a separate time, but it is out of scope today IMO 18:51:57 danielbeck oleg-nenashev AFAICT from this discussion you've got the green light 18:52:03 \o/ 18:52:13 but clearly lots of varying opinions about the plugin process :) 18:52:13 KostyaSha: could you create a topic for the next meeting? 18:52:14 +1 for the current subject, right. 18:52:37 OK, so "the current subject" is to create JIRA and redirect email plugin forking requst to there 18:52:39 right? 18:52:42 AYE 18:52:47 yes 18:52:55 oleg-nenashev, no 18:53:04 is there a name for that project in JIRA? 18:53:05 * rtyler looks at the time 18:53:15 oleg-nenashev: yes, I think this is indeed a discussion that would clarify things. IMO the projects needs to define *some* rules of thumbs. 18:53:38 #agreed we'll create a new JIRA project to receive plugin hosting request, and direct people to use it instead of sending emails to the dev list 18:53:45 #action danielbeck to set up Jira project for plugin hosting requests and update dev docs to point there 18:53:50 Sounds like the name is TBD 18:53:52 next topic! 18:54:03 next meeting :-) 18:54:05 That's it 18:54:09 #topic next meeting 18:54:14 batmat: Yes, probably we're too restrictive 18:54:16 #MYCUTEPLUGIN-* 18:54:21 10/28th looks fine to me 18:54:25 er, oct 28th 18:54:34 #info the next meeting is Oct 28th 18:54:43 When is the DST switch over in US & Europe? 18:54:53 Whenever that is, just be careful 18:54:58 #action danielbeck to put up warning in wiki about DST 18:55:01 24 / 25-10 in France 18:55:03 hheh 18:55:21 #endmeeting