18:02:38 #startmeeting 18:02:38 Let the Jenkins meeting commence! 18:02:41 hi everyone! 18:02:44 o/ 18:02:45 #chair rtyler kohsuke 18:02:45 Current chairs: danielbeck kohsuke rtyler 18:03:00 apparently we don't have an agenda 18:03:02 I also added Hacktoberfest to the agenda, but I messed up the dates 18:03:08 ah, ok 18:03:09 + LTS check 18:03:14 let's go through the usual ones, and then that 18:03:18 sure 18:03:19 #topic last meeting's actions 18:03:38 #info http://meetings.jenkins-ci.org/jenkins-meeting/2018/jenkins-meeting.2018-09-12-18.00.html 18:03:40 the .1 got out. thanks KK 18:03:42 woop 18:03:44 yup 18:03:51 #topic LTS status check 18:03:53 yeah. so far so good 18:03:54 ogondza \o/ 18:04:10 the backports are out, have to recheck the results 18:04:19 there is a question though 18:04:29 #info https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.138.2-fixed 18:04:32 https://issues.jenkins-ci.org/browse/JENKINS-53768 adds public api 18:04:46 which is sort of the point of inclusion 18:05:02 I lean towards having it in but is sort of unusual 18:05:14 * rtyler nods 18:05:14 ehhm, unusual for sure 18:05:21 Should we restrict it at least? 18:05:50 that was my question, restrict or add unrestricted 18:05:56 or revert 18:06:02 for whatever my opinoin is worth, I'm in favor of it, helps us answer good questions for removing code, etc 18:06:11 having it in as an early backport seems safe to me given how standalone it is 18:06:20 easy to pull out in case of trouble 18:06:22 oleg-nenashev: well , that is an option...\ 18:06:32 I do not mind if we keep it 18:06:42 restricting would make it much less useful if we expect plugins to pick it up 18:06:42 assuming that APIs are restricted 18:06:52 Note that it also introduces new UIs 18:07:01 well, extends an existing one 18:07:11 the help on anon usage stats existed before 18:07:30 there is no problem of adding UI 18:07:42 for the basic extension point, plugins will need to be written against the earliest core that has this 18:08:04 the API worries me 18:08:31 because of the usual weekly incompatibility problem? or something else? 18:08:34 * batmat thinks about @Beta ? 18:08:48 Beta may be OK 18:08:54 oooh, beta might be good 18:08:55 though it's also unusual 18:09:13 Note that we had crappy errors with Beta extension points in JCasC 18:09:25 I would not do so without testing 18:09:26 Note that there wold be something wrong with the API but reverting/restricting in .3 would be pain 18:10:04 @Restricted(NoExternalUse) IMO 18:10:22 makes it much less useful though for plugins :| 18:10:37 but that will force plugin authors use newer core preventing it to be used in this LTS line, no? 18:10:38 For a while 18:10:46 ogondza yes. 18:10:55 That's how Jenkins always worked 18:11:28 yes, but I understood the wole point of this is the new API so I do not see much different between skippping and restricting 18:11:29 We could add more complex Version compatibility logic than just "greater than" to plugins, but it's way out of the scope right now 18:11:49 we might get by by going crazy reflection in core to collect data from there, rather than plugins 18:11:50 Restricted API still allows using it in the core 18:12:17 ogondza well, the core implementation is already useful 18:12:27 ogondza and having that propagated to LTS early is important already 18:13:07 For quick adoption in plugins generally you need something better than Core API 18:13:10 oh,there is one, right 18:13:24 we're at several k data submissions already :) 18:13:25 Depending on latest LTS is not an option for many plugin maintainers 18:14:18 oleg-nenashev: suggesting unrestricted backport? 18:14:38 I am -1 for non-restricted/Beta API, and +0.5 for Restricted 18:14:40 Un 18:15:07 unrestricted backport will blow up in our face 18:15:32 with the core impl, I am in favor of restricted backport 18:15:36 I think we can get by with having it restricted. Would be great not to, but I understand the concerns. 18:16:03 Would like to understand the problem with beta though 18:16:21 * oleg-nenashev writing 18:17:03 So the problem with Beta is that you will still permit the plugin to be installed e.g. on 2.139 which has no extension points 18:17:54 the API is such that Extension(optional = true) is all you need for it to not blow up 18:18:11 Then, mvn hpi:run does not run well for pre-2.121.x. Should not be a problem for 1.238, but have not tested 18:18:11 it's not a new method on existing types or whatever 18:18:46 Maybe 18:19:09 well, new LTS line is just 10 weeks away 18:19:14 I have never tried optional Extensions for core things. Sounds a bit strange, but it likely works 18:19:15 Seems both ogondza and oleg-nenashev are in favor of restricting, so that works for me. Any further opinions? 18:19:26 +1 18:19:41 +0.5 18:19:51 which is the parent pom I need to ignore @Restricted again? :-P 18:20:04 #agreed restrict backported telemetry extension point 18:20:07 #agree restrict backported telemetry extension point 18:20:10 (just in case) 18:20:27 I think that was it for the LTS? 18:20:37 it was, thanks 18:20:44 \o/ 18:20:47 #topic Participating in Hacktoberfest 18:20:48 will to my homework tommoworw morning 18:20:57 oleg-nenashev you're up :) 18:21:08 #info: https://groups.google.com/forum/#!topic/jenkinsci-dev/YYG1CyvcbgE 18:21:23 Soo... do we want to participate this year? 18:21:51 #info Last year we had ~20 unique contributors, ~15 of them were newcomers in Jenkins 18:22:00 Not that many 18:22:17 what's the effort to result ratio? Do we consider it worth it? 18:22:25 But this year we have an opportunity to promote it at Jenkins meetups & Co 18:22:46 danielbeck: Hacktoberfest costs almost nothing excepting review capacity 18:22:50 Most I remember is the mess around the 'new view' PRs to core, but I'm told that's only a really minor part of it 18:23:02 Yes, that was unfortunate 18:23:24 I believe it should not have been marked as newbie friendly 18:23:32 oleg-nenashev do you expect to be able to properly handle reviews? How was contributors' experience with unmaintained plugins? 18:23:56 how many committed reviewers do you expect to need before we can properly support this? 18:24:04 there's an event at GitHub in SF next Monday which I'm hoping to get to, it's a Hacktoberfest kickoff 18:24:04 I remove newbie-friendly labels in non-maintained plugins 18:24:26 So, somebody may still take it 18:24:29 if all we need is newbie-friendly labeled task, then I can go through the Evergreen stuff, I know olblak already covered INFRA 18:24:48 I can do some additions in JENKINS 18:24:49 rtyler ideally some followthrough that PRs aren't stuck in limbo forever 18:25:04 we have some tasks after Google Code-In preps 18:25:24 But yes, some review capacity will be really helpful 18:25:26 well, Evergreen and Infra PRs are moving expediently through :) 18:25:39 Last year it was mostly me and Mark IIRC 18:25:39 don't know what to say about the rest of y'all slackers :P 18:26:02 I believe it worth trying 18:26:06 can we get JCasC or Jenkins X to sign up for this? might be useful to have some interesting projects involved? 18:26:07 agreed 18:26:14 We can limit the list of components 18:26:25 Consider JCasC as signed up, I am on it 18:26:29 oleg-nenashev: I wasn't aware from your email of much work? 18:26:45 I mean, nothing organizationally super special we /need/ to do in order to participate 18:26:54 we don't 18:27:10 We have everything more-or-less set up from 2017 18:27:17 FWIW my concern is mostly around making sure it's not a shitty experience for participants 18:27:28 danielbeck: that should be your concern 24/7 :) 18:27:43 reminds me of bitwiseman's ignite talk at the contributor summit :) 18:27:44 @jenkinsci/hacktoberfet mentions are the problem, but we fallback to Gitter channel this time 18:27:52 Jenkinci/hacktoberfest 18:27:59 so that People can ping there 18:28:08 the jenkinsci/jenkins gitter channel is good enough for me tbh 18:28:17 maybe 18:28:30 It just has some traffic so we may miss pings 18:29:02 But whatever, the infra overhead is just a blogpost (mostly copy-paster) + some guidelines 18:29:12 channels are easy to make on Gitter. 18:29:18 yes 18:29:27 Maybe some swag for Top contributors 18:29:48 I'm experiencing channel fatigue, so please keep that in mind for others like me who are in elveenty billion channels already 18:29:55 rtyler Sure, but If we get people to show up it will be an unusual influx of newbies to potentially have to guide through getting their contribution in shape. 1 or 2 at a time is easer than 10-20. 18:30:21 so I'd like to make sure experienced contributors are ready to handle this. 18:30:39 based on my experience with hacktoberfest, it's less total newbies like code-in or GSoC per se 18:31:17 I do not mind if we get newbie buzz in jenkinsci/jenkins 18:31:32 * rtyler has participated in hacktoberfest in the past :) 18:32:17 #info 2017 announcement: https://jenkins.io/blog/2017/10/06/hacktoberfest/ 18:32:20 anyways, oleg-nenashev was there anything specific you were looking to accomplish here? 18:32:28 or just get th e idea more thoroughly socialized? 18:32:42 Socialization + ensuring there is no -1 votes 18:33:09 I understand that it may cause some extra load on maintainers, so checking it just in case 18:33:23 If nobody is against, I am ready to proceed 18:33:32 IMO a great idea, so preemptive +1 18:33:34 danielbeck: WDYT after the discussion? 18:33:42 go for it, was never the question 18:33:43 race condition 18:34:00 Also, anybody is around in Nice on Oct 22? 18:34:19 haven't booked yet 18:34:22 If yes, I can try to organize a mini-hackfest there 18:34:56 I won't be there, iI'll be there in spirit though 18:34:57 probably best planned elsewhere 18:35:01 as a spooky ghost 18:35:08 yes, elsewhere 18:35:27 so I think you're good to go on Hacktoberfest 18:35:28 Sonoma County Hackhergarten would do the job as well ;) 18:35:30 anything else? 18:35:50 not from me 18:35:59 I believe it's +1 18:36:04 * rtyler claps 18:36:20 #topic next meeting 18:36:25 #action: oleg_nenashevto stage the Hacktoberfest announcement so that we run it when Hacktoberfest is announced 18:36:47 oleg-nenashev: I'll ping you if I'm able to go to the event next Monday 18:36:59 in which case, I would want to help get that blog published the morning of the 1st 18:37:08 thanks! 18:37:27 #topic next meeting 18:37:29 for real now :) 18:37:33 next meeting would be October 10 18:37:46 now we're well into DST change I think 18:37:57 We are in UTC now 18:38:05 so it should be better 18:38:05 \o/ 18:38:12 well, yes, which means it's no longer 8pm but 7pm or whatever 18:38:30 so make sure you know what local time corresponds to 6pm UTC 18:38:41 #endmeeting