18:00:07 #startmeeting 18:00:07 Let the Jenkins meeting commence! 18:00:10 o/ 18:00:16 #chair kohsuke rtyler 18:00:16 Current chairs: danielbeck kohsuke rtyler 18:00:25 agenda: https://wiki.jenkins.io/display/JENKINS/Governance+Meeting+Agenda?nocache 18:00:34 #topic Recap last meeting's actions 18:00:51 http://meetings.jenkins-ci.org/jenkins-meeting/2018/jenkins-meeting.2018-01-17-18.01.html 18:01:25 looks like oleg-nenashev rtyler alyssat_ markewaite had actions 18:01:41 (Did we skip the meeting two weeks ago?) 18:01:43 I updated the trademark page, I think 18:01:53 markewaite action item not required, FOSDEM shirts delivered as needed by atong 18:01:53 * rtyler checks 18:01:57 Oh, right, nobody was around two weeks ago 18:02:08 All my action items excepting JEP-200 post-mortem are done 18:02:16 yeah, I got the trademark thing done 18:02:21 https://wiki.jenkins.io/display/JENKINS/Approved+Trademark+Usage 18:02:38 This one is in my TODO list for the timeframe before RC 18:02:50 I've communicated w JFrog about the trademark guidelines 18:02:57 oleg-nenashev ok, thanks! 18:03:01 looking forward to it 18:03:10 great, looks like everything got done 18:03:17 \o/ 18:03:23 #topic LTS status check 18:03:26 Well, it's out 18:03:37 #info https://jenkins.io/security/advisory/2018-02-14/ 18:03:41 heh 18:03:45 You may want to update your Jenkinses 18:03:59 yeah, asap 18:04:18 I think that's it for 2.89.4, anything you'd like to add ogondza ? 18:04:37 nothing except we had 2 security releases during the line 18:04:43 quite exceptional 18:04:53 is that a good thing or a bad thing 18:05:17 bad that they're needed (and 2.89.2 was unplanned), good that we're getting them out 18:05:17 it sure is elaborate for the people, otherwise it is good I think 18:05:40 * ogondza looking forward next topic 18:05:52 :) 18:05:53 #topic LTS baseline selection 18:06:00 #info https://jenkins.io/changelog/ 18:06:21 JEP-200 has stabilized AFAICT 18:06:25 notably, no negative non-JEP-200 feedback recently 18:06:31 and JEP-200 was a month or so ago 18:06:32 IIUC by date criteria, 2.104 is the default candidate 18:06:56 recent releases look good, just downvote vandalism without real problems behind them 18:06:57 security release issued today. Daniel, do you prefer to have it there by default (iow, is backporting it a problem)? 18:07:14 We have one open JEP-200 issue: JENKINS-49543, likely specific to Tomcat only. Not sure what is the scope 18:07:30 ogondza backporting should be trivial: https://github.com/jenkinsci/jenkins/commit/09e1f8cd0ca173f3526f016e9ff18410fb422807 18:07:38 if we decide to go with an older release 18:07:56 you mean, older than 2.107 18:07:58 jglick strictly speaking, soaking only applies for backporting 18:08:00 * rtyler doesn't have a strong opinion on a future baseline 18:08:01 #info for JEP-200 we fixed around 50 plugins: https://wiki.jenkins.io/display/JENKINS/Plugins+affected+by+fix+for+JEP-200 18:08:05 danielbeck: ah 18:08:14 wow 18:08:25 CLAPz for oleg-nenashev and team 18:08:34 Amen 18:08:35 #info JEP-200 is generally good, the biggest open issue is Artifactory plugin which is not compatible 18:08:46 FWIW for 2.89 we went with the then current weekly 18:09:01 jFrog support is notified, they are working on that 18:09:14 So if the soak period only applies to backports, and we have started issuing security patches in all LTS micro releases, then our default policy should be for LTS baselines to be the most recent weekly no? 18:09:29 “Default”, i.e., unless we see something particularly scary that just landed. 18:09:39 2.104 or even 2.105 looks good to me 18:10:02 My only reservation about 2.105 would be JENKINS-48463 18:10:07 I would just use 1.107 unless we have negative ratings by tomorrow 18:10:13 ogondza If you like 2.105 I see no reason why we shouldn't go with 2.107 18:10:33 Well, we have some changes in SSHD 18:10:42 the docs might not be clear about soaking criteria though there are still some reasons not to pick latest 18:10:45 also JENKINS-47793 has a known regression but the fix is already filed and probably a trivial backport 18:10:48 Which are pretty major && not battle-tested well (in 2.106) 18:10:52 in general I mean 18:11:06 2.106 has an SSHD upgrade which is more significant. 18:11:21 #info SSHD changes in 2.106: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341097&styleName=Text&projectId=12310849&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED%7C47f5fd1e799680219ff14477b5b2c29ce7aaf6fd%7Clin 18:11:29 ah, okay -- wasn't sure how notable, especially since it was first on-holded but then merged anyway 18:11:57 notably, jglick posted https://github.com/jenkinsci/jenkins/pull/3278#pullrequestreview-95274673 :P 18:12:22 OTOH I would be really happy to pull in jglick's patches for Remoting Request/Response stats, maybe kinda helpful for JEP-200 18:12:32 2.106 also 18:12:38 2.106 also has my Remoting logging stuff. Probably safe enough, though it does touch on a heavily used code path. 18:13:01 To be clear, I have no objection to using 2.107, just trying to list the major risks. 18:13:13 so, given remoting and sshd changes, who's concerned about 2.106? Seems we're deciding between 2.105+security and 2.107. 18:13:23 yup 18:13:51 kohsuke ndeloof: Is https://github.com/jenkinsci/jenkins/pull/3279 important for Configuration-as-Code stories (JEP-201)? 18:14:16 shouldn't be a reason to choose one over the other tbh, still too early 18:14:25 maybe 18:14:31 Strictly speaking we have two weeks to change plans if we learn sshd or remoting are bad 18:14:38 yeah the C-as-C stuff is going to need all kinds of patches, there is no way we would expect *this* LTS to be usable for it 18:14:53 danielbeck: or, again, https://github.com/jenkinsci/jenkins/pull/3185/files which affects every XML file save 18:15:03 (in 2.105) 18:15:18 so I suggest we go with 2.107 for now and keep watching for problems, we have two weeks to change direction if something major comes up 18:15:22 I think we have to live with it 18:15:31 don't get me started on that change -.- 18:15:42 JEP-200 upgrade guide includes "Do a backup" anyway 18:15:48 heh 18:16:05 So XML 1.1 does not make it much worse 18:16:16 FWIW the problems reported against it were problems downgrading, so we can just add it to the upgrade guide. Nothing beyond needing a sed -i 18:16:27 So what would be the process if we *do* decide to backdate the LTS in the next two weeks? Throw away the `stable-2.107` branch and start a new one I suppose? 18:16:41 jglick that would be my suggestion if it comes to that 18:16:48 OK with me. 18:16:49 jglick, IIRC we have done that once 18:17:04 right now we've identified three potentially bad changes, the question is whether they result in older baseline picked up 18:17:23 personally I don't think we should plan for that quite yet. 18:17:24 depends on our ability to hotfix 18:17:35 Frankly, compared to JEP-200, I suspect none of them are serious risks. 18:17:45 ogondza and if we can't, go with older base within 2 weeks 18:17:56 yes 18:18:18 If we decide to go with latest and we have some concerns, I would like to have some deadline to make the call 18:18:39 ... if we have decided to reconsider or we can do the backports 18:18:40 Feb 21? 18:18:49 that was my suggestion 18:18:52 if we go with 2.107 there's not a lot of backporting that qualifies, so 2 weeks from today should be fine. 18:19:11 So: plan on 2.107, watch for reported regressions, try to hotfix anything we can (possibly making exemptions to backport soaking policy for these), and if it seems unwieldy after two weeks, switch to an older baseline? +1 from me if so. 18:19:30 +1 18:19:39 my concerns is we would have 2 weeks for backports and testing 18:19:48 we could even spin 2.107.1-rc-1 even now if it helps 18:20:27 ogondza not a lot of changes will qualify for 2.107.1 in the next two weeks, so if we drop it, we can go with 2.105 + security. 18:20:38 that should be done in a day, no? 18:20:38 assuming JEP-200, having extra 2 weeks for RC would not hurt 18:20:44 I expect we will need to evaluate our soak policies in the near future in light of JEP-301. 18:21:10 is there a reason we _want_ 107 over 104/105+security, or it is just "why not latest"? 18:21:12 FWIW backporting the 2.107-2.106 security fixes would be very simple. 18:22:07 ogondza no strong reason to, but also not not to 18:22:31 ogondza so you'd consider 2.105 much safer, with some security fix backports? 18:22:54 I do not mind to improvise if we have a reason to make exception but we do not seem to in this case .... 18:23:40 well, I'm just saying 107 seems fine and if it turns out it's not, we can easily handle it. 18:23:49 no improvisation as of today, just a backup plan 18:24:07 Again if anyone is arguing for a conservative baseline, 2.104 would make more sense than 2.105. 18:24:44 jglick because of xml 1.1? 18:24:46 danielbeck, right, that depends on how confident we are we would not need the backup plan. Which we seem to be pretty confident 18:24:50 danielbeck: yes 18:25:14 JENKINS-47793 has some unresolved UI regressions, so picking 2.104 would solve that. Anyway, it's not a big deal 18:25:48 yeah I mentioned that earlier, but it is pretty minor 18:26:40 I do not object giving 107 a try and see if something pops up 18:26:54 * rtyler shrugs 18:27:01 if ogondza's okay, I'm okay 18:27:04 As JEP-200 maintainer, I would rather like to see 2.107 as RC and spinning rc-1 earlier to give people more time to test their stuff 18:27:13 So I am also ok 18:27:21 oleg-nenashev, but that would be just weekly, no? 18:27:29 oleg-nenashev: what would 2.107-rc-1 be besides 2.107?? 18:27:39 nothing, that's the point 18:27:43 uh 18:27:44 well, then test that 18:27:50 exactly 18:27:58 we may need rc-2 with extra whitelists & Co 18:28:14 we can determine that by testing 2.107 18:28:14 But rc-1 would explicitly say that it's ready for testing 18:28:42 In an ideal world, there are Jenkins users who pick RC and test it on their instances 18:28:44 naming it rc-1 would cause me to start testing it (as an example) 18:28:53 I think it would be more confusing to create another release version that is identical to one we already have. Better to just broadcast more widely the proposed baseline and ask people to test weeklies. 18:28:55 It is trivial to push it it just feels odd 18:29:04 ogondza sends emails, that's how LTS testing info is distributed. If the email says, 2.107 is expected to be 2.107.1, should be fine 18:29:27 I do RC tests, and I could just do test for weekly instead 18:29:46 I can switch to weekly 2.107 for my RC tests as well 18:29:46 right, just use 2.107 for those 18:29:47 So he should just instruct anyone like Mark who does testing to start testing against the weekly baseline. I mean, that is good advice for *any* LTS line. 18:29:58 FWIW I consider the security fixes to be pretty safe this time around :-) 18:30:10 famous last words 18:30:13 (unlike last time) 18:30:15 heh 18:30:24 * rtyler prints out that statement 18:30:26 * rtyler hangs it on the wall 18:30:31 but yeah, should be safe 18:30:38 * rtyler prints that out too 18:30:46 yeah unless you have `src/main/webapp/I-dare-you-to-..-try-to-use-\\\-this-URL.html` 18:30:53 rtyler has a printer 18:31:05 heh 18:31:12 jglick I grepped sources, so low risk and trivial to address in plugins 18:31:19 yes, jk 18:31:38 OK, so we vote for 107 + extra announcement in advance? 18:31:49 +1 18:31:52 107 +1 18:31:57 +1 18:31:58 (i.e. +107) 18:32:02 +1 18:32:14 anyone opposed? 18:32:24 +1 18:33:03 alright 18:33:16 #agreed 2.107 will be the LTS baseline unless we find major problems, no currently planned backports, testing can commence with the weekly, and ogondza will announce it as such 18:33:24 yey 18:33:53 #agree 2.107 will be the LTS baseline unless we find major problems, no currently planned backports, testing can commence with the weekly, and ogondza will announce it as such 18:33:58 in case I got the command wrong 18:34:09 #topic Quick GSoC update 18:34:13 oleg-nenashev this is yours 18:34:34 #info: TL;DR: We have been accepted to GSoC 2018. https://jenkins.io/projects/gsoc/ 18:34:37 yey 18:35:03 I will get the thing announced in the blogpost tomorrow + update the docs 18:35:05 \o/ 18:35:10 \o/ 18:35:29 congrats Oleg 18:35:46 #info So far we have 8 finalized project ideas and 11 mentors. We will be accepting new project ideas till March 05 18:35:49 thanks! 18:35:56 #info https://developers.google.com/open-source/gsoc/timeline 18:36:14 #info Org admins this year: oleg_nenashev martinda14 schristou 18:36:41 Generally, if you have any idea, you are more than welcome to join the party 18:37:14 Developer mailing list already got some GSoC threads, be ready to more topics there 18:37:16 you need more mentors don't you? 18:37:21 always 18:38:01 #info Mentors are welcome, with or without project ideas 18:38:14 hmm, https://jenkins.io/blog/2018/01/05/gsoc2018-call-for-mentors returns 404 18:38:33 #info https://jenkins.io/blog/2018/01/06/gsoc2018-call-for-mentors/ 18:38:41 ok, time to fix it 18:39:11 Question to the meeting, do we want to have a GSoC Jumbotron? 18:39:28 The current Blue Ocean one is kinda outdated anyway 18:39:42 Judging by FOSDEM booth conversations, people still don't know 18:40:02 I wonder how useful pointing random visitors to GSOC is, what would be the goal of that? 18:40:11 I assume students get here from GSOC? 18:40:20 yes, mostly 18:40:31 though not all students are aware about GSoC 18:40:42 so we could get some extra traffix 18:40:45 *c 18:40:58 But it is a cool thing that the Jenkins project is participating in. 18:41:01 if you expect it'll get more people to participate, go for it 18:41:31 I would +1 for a limited-time Jumbotron, e.g. 1 week 18:41:50 I think you can just submit the PR, no need to vote here ;) 18:41:51 and we need to poke people to create a new one, e.g. for Declarative Pipeline 18:42:09 I wanted to get the feedback first to save time 18:42:35 Jumbotron creation UX sucks, would like to rework it eventually 18:43:06 I mean an ultra-long HTML description in a single line, for example 18:43:23 OK then, Is anyone here opposed to using the jumbotron for GSOC? 18:44:06 #action oleg_nenashev to create a GSoC blog post for students/mentors 18:44:08 oleg-nenashev nobody speaking up is probably the best you can get… 18:44:17 oleg-nenashev anything else you want to share about GSOC? 18:44:38 #action oleg_nenashev to create a Jumbotron patch in a SEPARATE pull request 18:44:43 nope, nothing else 18:45:09 #topic next meeting 18:45:20 that would be February 28, same time same place 18:45:51 possibly with an LTS baseline decision revisited 18:46:06 #endmeeting