18:00:06 #startmeeting 18:00:06 Let the Jenkins meeting commence! 18:00:20 #chair kohsuke rtyler 18:00:20 Current chairs: danielbeck kohsuke rtyler 18:00:26 hi everyone! 18:00:35 hey 18:00:35 today's agenda: https://wiki.jenkins.io/display/JENKINS/Governance+Meeting+Agenda 18:00:45 we're selecting an LTS baseline today \o/ 18:00:52 #topic Recap last meeting's actions 18:00:58 #info meetings.jenkins-ci.org/jenkins-meeting/2018/jenkins-meeting.2018-04-25-18.00.html 18:01:16 well, LTS RC has been out for a while, so that's done 18:01:21 yep 18:01:39 moving on… 18:01:46 #topic LTS status check 18:02:01 this will be quick 18:02:06 LTS is out. It's a security update, so you should update :) 18:02:10 2.107.3 and 2.121 18:02:49 #info https://jenkins.io/security/advisory/2018-05-09/ 18:03:20 present FWIW 18:03:32 ogondza FYI, apparently (based on a report in #jenkins) we messed up packaging 18:03:41 uh 18:03:46 IOW, our previous mess has been undone 18:03:58 2.107.1 and .2 were released with stable-2.60 packaging 18:04:11 you mean it was messed before .3 and now it is fine? 18:04:13 and it looks like 2.107.3 got a different branch despite ogondza and me agreeing to keep it 18:04:32 huh, any undesirable impact? 18:04:34 sort of, but it's a change from .2, so we now seem to have the unexpected change we wanted to prevent 18:04:39 not sure yet 18:04:49 just a heads up, learned it a few minutes ago 18:04:53 TLDR: Packaging is weird 18:05:21 I suspect kk's automation just picked the latest matching branch - we tried to be sure nothing gets updated to pick it 18:05:21 uh, trunk is messed up I think 18:05:31 jglick trunk of…? 18:05:48 `jenkinsci/jenkins/master` is `2.121-SNAPSHOT` 18:06:13 Should be `2.122-SNAPSHOT` now, no? 18:06:21 it should 18:06:40 probably https://github.com/jenkinsci/jenkins/commit/91e1cf2d3e0fa1c4766c62f2db54cd3a28cd9d32 wrong merge, since it's so new 18:06:44 maybe the changes didn't get pushed or the released happened from a branch. Checking 18:07:03 I do not see the `jenkins-2.121` tag in `master`. 18:07:38 It says it's in master: https://github.com/jenkinsci/jenkins/commit/9bc3aa68b196fbf9c676541793f4b59f663c4af8 18:08:00 just 2 days ago. Has KK staged the release or what? 18:08:09 yes 18:08:11 mm, yes, so something else went wrong here 18:08:18 we're staging security updates on Mondays 18:08:27 probably just off by one in the merge commit 18:08:29 anyway, can be sorted out elsewhere, we can move on I suppose 18:08:31 likely kohsuke just needs to push the code 18:08:39 oleg-nenashev he did 18:08:49 oh right 18:08:58 anyway, +1 for moving on 18:09:01 is this cause by messed packaging or it is unrelated? 18:09:01 ok, we'll figure this out elsewhere 18:09:05 unrelated 18:09:15 our security process is, uh, intricate 18:09:16 ok, thanks 18:09:28 So we may need 2.107.4 if the packaging is really bad, right? 18:09:53 it was wrong before, but seems correct now. That however introduced changes from .2 18:10:07 but going with .4 to go back to wrong packaging seems counterproductive 18:10:26 +1 18:10:28 lets not do this until we hear about regression important enough 18:10:34 +1 18:10:40 alright, moving on 18:10:43 # topic LTS next baseline selection 18:10:49 #topic LTS next baseline selection 18:11:05 #info https://jenkins.io/changelog/ 18:11:29 lets get this started. 2.119? 18:11:51 2.118 looks good if we're scared. Otherwise 2.121 looks good, too. All the problems in 2.120 were just transitory or related to a new admin monitor and addressed in 2.120 18:11:52 has some bad ratings, but the issues got fixed in 2.120 18:12:03 sorry, problems in 2.119 18:12:11 2.118 has extremely good community ratings, yes 18:12:44 and the problems in 2.119 were project infra related, or addressed in 2.120 18:12:48 We have untriaged regression in JENKINS-51136 on Solaris 10, which is supposedly related to the Jetty upgrade 18:13:02 JENKINS-51136 is 2.117+ 18:13:24 I do not consider it as a blocker . Only a single report 18:13:26 > Solaris 18:13:52 3 watchers but 2 of them are team, so really just one report 18:14:07 IMO we have free choice of versions 18:14:37 I would be 1000% confident if I knew that this is the only affected platform. But, since there is no triage so far, I am totally fine with picking 2.118 or above 18:15:24 Would be great to know wadeck's opinion about 2.119+ if he is around 18:15:31 any reason we shouldn't just plan for 2.121 and see what happens over the next week or so? 18:15:57 oleg-nenashev: You mean regarding the root url stuff? 18:16:04 yes, JENKINS-51064 18:16:14 we ware this adventurous last time. twice in a row? 18:16:19 There is a pending PR to address the rest of the problems 18:17:09 Yes, but imo if there are any other regression we would just back out the validation entirely 18:17:35 at least in LTS 18:17:42 Yes, shipping last weekly becomes a habit. We generally reduce our response time to newly discovered regressions. But the issue queue is triaged well now, so I am fine with that 18:18:04 ogondza last time we had cause for concern, like XML 1.1. this time I'm looking at the changelog and nothing really stands out in the last two weeks 18:18:22 the install state storage perhaps, but that's jglick quality 18:18:24 :) 18:18:47 I do not object, though it caused some extra coordination 18:18:55 process killing veto (JENKINS-9104) basically cannot make it worse than it was before 18:19:07 I would prefer to avoid Root URL validator in LTS since it didn't get soaked enough IMO && already caused issues in weeklys 18:19:12 and then there are the options for builds and workspace directories 18:19:21 other than that all looks fairly straightforward 18:19:41 oleg-nenashev rip out the admin monitor from LTS, and done? 18:19:54 "builds and workspace directories" would require upgrade guide for sure, but I would rather bite the bullet 18:19:55 shell we go this way, I would like us to agree on a decision date so there is enough time to rebackport in base we reconsider 18:20:10 oleg-nenashev you mean the whole root url monitor or just the validation? 18:20:25 whole root URL monitor 18:20:33 oleg-nenashev upgrade guide is no reason to delay, we need it either this time or next. risk OTOH would be. 18:21:00 oleg-nenashev rip out monitor, keep setup change? 18:21:26 works for me 18:21:30 or just 2.118 18:22:05 the latter option would require backporting JEP-200 whitelists twice, but it's not a problem IIUC 18:22:10 ogondza: ^ 18:22:17 plus security fixes 18:23:18 java.util.EnumMap and org.jruby.RubyNil ware fairly trivial. Deferring to Daniel 18:23:52 IMO 2.121 is a reasonable choice, and the only thing that's brought up so far is the admin monitor, which can either be dropped or mentioned in the upgrade guide 18:24:12 feedback looks reasonable 18:24:32 any compat concerns? 18:24:40 regarding? builds dir? 18:24:59 Do wadeck's changes include new non-Restricted APIs? IIRC no 18:25:06 no 18:25:21 not the admin monitor 18:25:36 then it's fine with me though it's not a common practice to remove changes from LTS 18:26:06 oleg-nenashev TBH that's something I'd hold back for a week at least and wait for feedback 18:26:13 if that works for ogondza 18:27:04 it feels going with 2.119 tentatively for a week and reconsider sounds as a plan for all 3 of us 18:27:31 we can fallback to 2.118 or something based on the data we get in the mean time 18:27:32 ? 18:27:35 2.119 looks like the worst possible option since 2.117 18:27:46 yes 18:27:51 s/2.119/2.121/ 18:27:57 :facepalm: 18:27:59 ah 18:28:06 2.118 or 2.121 IMO. +1 from me for both 18:28:36 so, 2.121 and keep watch for negative reports? 18:28:49 yes 18:28:53 check back in a week to finalize or revise? 18:29:16 2.121 (at least provisionally) seems fine to me 18:29:53 sure, how will we sync? 18:30:04 dev list thread? 18:30:42 any dissenting opinions? 18:30:53 not sure 18:31:17 should we announce the temporary plan and whoever object will speak up in the thread? 18:31:29 how did we do it last time? 18:32:11 oleg-nenashev spoken up suggesting to change the temporary option, IIRC 18:32:46 last time? :) 18:33:14 Not sure I enjoyed the discussion afterwards 18:33:24 https://groups.google.com/forum/#!msg/jenkinsci-dev/7nR0_kI71xA/TNrMNVlmAAAJ 18:33:50 IMHO we need to reconsider our LTS process if we continue doing temporary options 18:34:23 agreed 18:35:11 Previously it was clear. LTS baseline is selected, done. All users were able to start testing immediately 18:35:54 Now every user just waits till it's finalized. If you manage Jenkins as internal service team in a big company, that's not fun 18:36:18 If you have a product which uses Jenkins inside, it's not good as well 18:36:51 I do favor clear baselines, too. 18:36:52 Then let's announce it as usual, and if we find a major problem, we'll revisit the choice. It's not temporary, but just acknowledging that we have a plan if critical regressions show up 18:37:04 how about me starting a thread next Tue and we will evaluate the responses by Wed? 18:37:35 if we somehow find a major regression introduced in 2.118 and cannot recover in time during LTS testing, would we proceed with 2.118.1? 18:37:36 dont feel strongly either way 18:38:06 danielbeck: works for me. RC is always a risk 18:38:08 for me the choice today is final, except in case of unexpected critical issues. But IMO that would be the footnote for any choice. 18:38:19 +1 18:38:26 agreed 18:38:54 so I will start a baseline remarking we may reevaluate 18:39:11 ... of 2.121 18:39:17 +1 18:39:21 +1 18:39:51 #ogondza I will start a baseline of 2.121 remarking we may reevaluate in case of critical regressions 18:39:57 TBH I wouldn't even remark. If testing reveals critical problems I expect that we'd discuss solutions no matter what the baseline ¯\_(ツ)_/¯ 18:39:59 #action ogondza I will start a baseline of 2.121 remarking we may reevaluate in case of critical regressions 18:40:49 shall we move on? 18:40:59 IMO we can 18:41:16 yep 18:41:29 #agreed 2.121 is the next LTS baseline 18:41:37 #topic GSoC status check 18:41:40 oleg-nenashev \o/ 18:41:44 okay 18:41:54 #info GSoC projects: https://jenkins.io/projects/gsoc/#projects 18:42:24 So, we have scheduled project-specific office hours & Co 18:42:47 #info GSoC Special Interest Group chat: https://gitter.im/jenkinsci/gsoc-sig 18:43:16 oh, that was implemented, nice 18:43:18 We also started a SIG chat according to the discussion, because all projects are in Gitter 18:43:29 Well, I went forward and implemented it 18:44:03 "sig" is just the only thing in the name which refers to the sig proposal, but IMHO this is fine. CC rtyler 18:44:13 And we have some updates... 18:45:22 #info Jeff Pearce (https://github.com/jeffpearce, Cobertura plugin maintainer) joins the Code Coverage API Plugin project as a mentor. Welcome aboard Jeff! 18:46:14 Another update is that we have one project at risk, and it will likely get cancelled. Will update at the next governance meeting. Other 3 projects are fine, design is in progress 18:46:57 that's all from me 18:47:02 thanks oleg-nenashev ! 18:47:18 how bad is having one project at risk? 18:47:26 #action oleg_nenashev to reach out to the board and alyssat_ regarding swag and conference logistics for GSoC 18:47:27 isn't it early for that? 18:47:36 it happens 18:48:18 It's not good, but we will be fine. More updates at the next governance 18:48:21 hm, ok 18:48:22 thanks 18:48:29 any questions for oleg? 18:48:30 any questions? 18:48:49 how did I get 3 underscores in the name? :( 18:49:01 At least nobody pings me in IRC 18:49:26 #topic next meeting 18:49:40 that would be May 23 18:49:53 same time same channel 18:49:57 thanks everyone! 18:50:02 #endmeeting