18:03:07 <kohsuke> #startmeeting
18:03:07 <robobutler> Let the Jenkins meeting commence!
18:03:27 <kohsuke> #info https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda
18:03:36 <kohsuke> #topic Recap of actions
18:03:45 <danielbeck> Those were essentially all mine
18:04:16 <danielbeck> Writing a draft on the travel program: topic https://wiki.jenkins-ci.org/display/JENKINS/Travel+Grant+Program
18:04:28 * kohsuke reads
18:05:32 <danielbeck> While you're reading; KK had an action to op me here so I can set up logging from botbot.me -- I got op but so far have not heard back regarding logging. I'll stay on the ball here.
18:05:39 <kohsuke> This looks good to me, but I'd suggest we add one thing to the application
18:06:00 <kohsuke> a pitch of why we should sponsor your trip
18:06:29 <danielbeck> right... that is basically implied by the rest of the doc but let's make it explicit
18:07:04 <kohsuke> Any other thoughts? I'm ready to just bless it
18:07:08 <danielbeck> no need to decide on this today, I deliberately haven't made it a topic. I suggest you review this and provide improvement suggestions.
18:07:19 <kohsuke> OK
18:07:20 <danielbeck> Too late for this year anyway AFAICT
18:07:23 <oleg-nenashev> Does it make sense to specify travel grant limits?
18:07:33 <kohsuke> oleg-nenashev: $500 is set as a cap
18:07:40 <oleg-nenashev> Oh, I see
18:07:41 <danielbeck> we have 2k funds, so that's 4
18:08:00 <kohsuke> orrc preferred that cap so that we can support more short leg trips
18:08:02 <danielbeck> Right, I forgot one person is only eligible once per year. At least I think that makes sense.
18:08:05 <hare_brain> What does this statement mean: "While you're free to attend in case there are any questions, please refrain from more active participation while your application is discussed."
18:08:26 <kohsuke> #chair hare_brain
18:08:26 <robobutler> Current chairs: hare_brain kohsuke
18:08:36 <danielbeck> hare_brain This meeting is public. I think you should shut up unless asked while we're discussing your application
18:08:47 <hare_brain> LOL
18:09:19 <hare_brain> I thought it could mean, "don't try to appear more active after you've submitted your application."
18:09:30 <KostyaSha> +1
18:09:39 <kohsuke> Come to think of it, in fact I'd welcome to have the person come and hang around
18:09:39 <danielbeck> oh, right, participation in the meeting
18:10:08 <danielbeck> Right, but participating in the discussion of exactly how deserving they are? That's what the application is for.
18:10:36 <hare_brain> That's fair. I was just asking for clarification of the intent of that sentence.
18:10:48 <danielbeck> Specifically meeting participation
18:11:15 <hare_brain> And the same person can apply for a travel grant every year?
18:11:20 <danielbeck> I'll change the document and we'll review next time.
18:11:26 <kohsuke> OK, do we want to move on?
18:11:44 <kohsuke> #topic LTS status check
18:11:48 <KostyaSha> hare_brain, it will be weird
18:11:49 <danielbeck> hare_brain Right now, every event, but I think once a year is good enough. Of course we should take previous grants into account
18:12:01 <kohsuke> oh sorry
18:12:10 <kohsuke> #topic Recap of actions
18:12:20 <KostyaSha> ogondza, highlight
18:12:25 <danielbeck> kohsuke I also have one more recap
18:12:46 <danielbeck> Let's discuss the details of the travel grant next time. It's not urgent I think, and we have a full plate today
18:13:02 <hare_brain> OK
18:13:03 <kohsuke> I suspect if we end up sponsoring the same guy every single time we'd move to shut down the program
18:13:25 <kohsuke> danielbeck: what's the other recap?
18:13:32 <KostyaSha> kohsuke, you will win every time :D
18:13:41 <kohsuke> Oh, can I apply?
18:13:47 * kohsuke jumps in joy
18:13:53 <hare_brain> No. :)
18:14:20 <danielbeck> And the last action was a blog post about the travel grant featuring our first recipient: I haven't been able to reach him since, but apparently his company is getting bought right now so he's busy. So I decided to wait a bit, especially given that we don't have the rules doc done either.
18:14:41 <danielbeck> so I'm still on this one
18:14:56 <danielbeck> that's it for the actions of the last meeting
18:15:00 <kohsuke> I guess we'll all meet him in JUC SF
18:15:04 <KostyaSha> danielbeck, i think it in his interests to reply, so just wait
18:15:34 <kohsuke> #topic LTS status check
18:15:38 <ogondza> I suggest to move next LTS picking to the next time as we have to postpone 1.609.3
18:15:48 <danielbeck> I cut in line with this one, but thought it was important to get to
18:15:50 <ogondza> as RC was not published
18:16:07 <kohsuke> My apologies
18:16:13 <danielbeck> Right. Assuming RC today, will make release and new LTS selection in two weeks. I think this is a good idea.
18:16:28 <ogondza> right
18:16:29 <ogondza> What about JENKINS-29936?
18:16:31 <jenkins-admin> JENKINS-29936:deadlock between OldDataMonitor and AuthorizationStrategy. (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-29936
18:16:40 <danielbeck> You merged it, right?
18:16:41 <kohsuke> #action kohsuke to kick RC script today and actually verify that bits are published
18:17:06 <danielbeck> ogondza at least you set the label
18:17:15 <kohsuke> Unless you tell me not to include it, it'll be a part of RC
18:17:30 <kohsuke> oh wait, 29936
18:17:35 <ogondza> kohsuke: please wait until agree what comes in
18:17:46 <danielbeck> I added it to the agenda when I saw teilo request inclusion
18:17:48 <kohsuke> OK, so it's not in stable-1.609 yet
18:18:03 <ogondza> sorry, JENKINS-29568 is in already
18:18:08 <jenkins-admin> JENKINS-29568:When NodeProvisioner processes planned nodes, it must always call spent() (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-29568
18:18:10 <danielbeck> sorry, jglick suggested it
18:18:22 <ogondza> the other one was labeled prematurely
18:18:38 <ogondza> any +1s for JENKINS-29936?
18:18:40 <jenkins-admin> JENKINS-29936:deadlock between OldDataMonitor and AuthorizationStrategy. (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-29936
18:19:01 <KostyaSha> JENKINS-29936 sounds bad, +1 to have fix in lts....
18:19:02 <danielbeck> https://github.com/jenkinsci/jenkins/commit/c1b60f18b548852428b835ecba72a3467d726ba0?w=1
18:19:21 <danielbeck> looks safe enough really
18:19:29 <ogondza> agree
18:19:40 <danielbeck> so +1 for inclusion despite age
18:19:47 <ogondza> let's push it in an cut the RC
18:19:59 <kohsuke> OK
18:20:09 <danielbeck> #agreed JENKINS-29936 will be in 1.609.3 RC
18:20:09 <kohsuke> #agreed JENKINS-29936 is expedited into 1.609.3 RC
18:20:11 <jenkins-admin> JENKINS-29936:deadlock between OldDataMonitor and AuthorizationStrategy. (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-29936
18:20:15 <danielbeck> :-)
18:20:35 <ogondza> looks I really have to backport it ...
18:20:48 <kohsuke> Shall we move on?
18:20:51 <ogondza> sure
18:20:52 <danielbeck> Yes
18:21:01 <kohsuke> #topic revisiting bundled plugins
18:21:49 <kohsuke> If people who are arguing against it is here perhaps we could have spent some time here to discuss that, but I don't think they are
18:22:48 <kohsuke> So I think I'm going to leave this proposal dead
18:23:22 <kohsuke> It's really unfortunate that we can't make this simple improvement
18:23:46 <kohsuke> I just don't understand why the pinning behavior different is such a big deal
18:23:47 <kohsuke> oh well
18:23:49 <kohsuke> next topic...
18:24:20 <kohsuke> #topic Allow file browsing in artifactory for ability view javadocs, add link in confluence macros live link, send request to jfrog support to get newer artifactory version.
18:24:30 <KostyaSha> yeah, mine
18:24:49 <KostyaSha> so first idea is to enable javadocs browsing at artifactory
18:25:09 <kohsuke> You mean repo.jenkins-ci.org ?
18:25:11 <KostyaSha> yes
18:25:21 <KostyaSha> this checkbox is disabled by default
18:25:26 <danielbeck> http://www.jfrog.com/confluence/display/RTF/Local+Repositories#LocalRepositories-AdvancedSettings "If set, allows you to view file contents (e.g., Javadoc browsing, HTML files) directly from Artifactory. When content browsing is allowed we recommend strict content moderation to ensure that any uploaded content does not compromise security (for example, cross-site scripting attacks) "
18:25:52 <KostyaSha> it may look like http://repo.jfrog.org/artifactory/libs-releases-local/org/artifactory/artifactory-papi/%5BRELEASE%5D/artifactory-papi-%5BRELEASE%5D-javadoc.jar!/index.html?overview-summary.html
18:26:10 <oleg-nenashev> Do we have a "strict content moderation"? I'd guess the answer is no
18:26:11 <KostyaSha> (@jbaruch from jfrog showed me this trick)
18:26:23 <KostyaSha> oleg-nenashev, do we have any security in jenkins infra at all?
18:26:46 <kohsuke> danielbeck: OTOH people can upload html as artifact already anyway
18:27:13 <KostyaSha> we can try at least :(
18:27:15 <kohsuke> .., though maybe they don't serve that with html content-type
18:27:29 <danielbeck> kohsuke exactly, right now you only get download
18:27:43 <KostyaSha> either you will need additional sites and in this variant you hava javadocs out of the box
18:27:53 <oleg-nenashev> If I understand correctly, it will increase the load on the VMs, because artifactory will need to unpack the content
18:28:04 <KostyaSha> danielbeck, somebody can insert XSS into plugin that you install
18:28:17 <KostyaSha> oleg-nenashev, artifactory hosted by jfrog
18:28:25 <danielbeck> true. I still don't see that as argument for making other parts unsafe.
18:28:27 <KostyaSha> oleg-nenashev, is it your pain?
18:28:40 <danielbeck> oleg-nenashev It's hosted by JFrog
18:29:02 <oleg-nenashev> If it's being hosted on JFrog, I'm ok from the performance perspective
18:29:46 <kohsuke> if javadoc browsing is a popular feature, maybe we can write an app ourselves? I'm sure it's a nice POTD for an intercontinental air trip
18:30:40 <KostyaSha> what app?
18:30:46 <danielbeck> kohsuke Please no more infra we'll have to maintain.
18:30:54 <kohsuke> Okay
18:31:06 <KostyaSha> danielbeck,  :D
18:31:39 <danielbeck> is there a way to generate a static site from many javadocs? maybe even merge them?
18:31:42 <kohsuke> KostyaSha: I think the proposal is rejected, sorry
18:32:01 <kohsuke> I think I'm seeing the proposal is rejected, that is
18:32:05 <kohsuke> Next topic?
18:32:11 <danielbeck> sure
18:32:18 <kohsuke> #topic Provide public list of JIRA/confluence/artifactory admins in wiki
18:32:39 <danielbeck> I could provide wiki and Jira, but don't have artifactory access
18:32:46 <danielbeck> of course the question is why this is needed
18:32:58 <danielbeck> if something needs fixing, we have #jenkins-infra and the infra list
18:33:13 <kohsuke> the intent was to use the LDAP 'administrators' group as a single point of control for all access, but I guess the reality turned out to be different
18:33:16 <KostyaSha> small story, when i worked in Gentoo Project i saw all responsible persons, in jenkins it's dark
18:33:24 <kohsuke> danielbeck: I think it's a fair request for transparency
18:33:39 <KostyaSha> sometimes some unknown people appears with admin permissions in wiki for example
18:33:55 <danielbeck> kohsuke True.
18:34:23 <dash562> Im having an issue where I have two different nodes building two different projects. However even assigned nodes to those projects are building on the other nodes. When setting usage on the node to Only build jobs with label restrictions matching the nodes. Builds will go into queue and not build on the assigned node.
18:34:24 <oleg-nenashev> +1 for "infra component owners" and "admin listings"
18:34:34 <kohsuke> I just thought it'd have been nicer if we don't have to produce this list manually for each app
18:34:40 <kohsuke> hence the comment about 'administrators' group
18:34:40 <danielbeck> I'm +1 as I had this question in the past. If it gets abused regularly (so much easier to ping people than write to the mailing list) we'll need to reevaluate
18:35:08 <kohsuke> Oh I see, you are worried about people pestering admins
18:36:20 <danielbeck> it's possible. Not a major concern though
18:36:27 <danielbeck> And if it happens we can always go 'dark' again
18:36:44 <kohsuke> Looks like repo.jenkins-ci.org is correctly referring to the admin group in LDAP
18:37:02 <kohsuke> But JIRA & Confluence I suspect we added some additional users in the system
18:37:14 <kohsuke> ... in the respective system
18:37:23 <danielbeck> users are from the directory, but groups and membership are local I think
18:37:58 <kohsuke> Would it be too much hassle if we use the opportunity to fix them to honor the LDAP group?
18:38:16 <kohsuke> Or do we actually want to give different admin access to different system separately?
18:38:43 <danielbeck> An inventory of current admins would be useful there I think
18:38:49 <danielbeck> to answer that
18:39:08 <kohsuke> OK, so we'll just produce a list manually once and see if further automation/consolidation is in order
18:39:17 <kohsuke> sounds good
18:39:21 <oleg-nenashev> +1
18:39:24 <danielbeck> +1
18:39:47 <kohsuke> #action danielbeck to produce a list of JIRA/Confluence/Artifactory admins once
18:40:06 <danielbeck> #action kohsuke to give danielbeck admin access to Artifactory
18:40:19 <KostyaSha> example: https://wiki.gentoo.org/wiki/Project:Infrastructure
18:40:25 <KostyaSha> Lead, members
18:40:26 <kohsuke> danielbeck: you should already have one
18:40:32 <kohsuke> I thought you are a member of the admin group
18:40:34 <kohsuke> but I'll check
18:40:43 <danielbeck> nope
18:40:55 <danielbeck> I'm only wiki and Jira admin and got those separately
18:41:05 <danielbeck> never needed repo so far
18:41:19 <kohsuke> Filed https://issues.jenkins-ci.org/browse/INFRA-350
18:41:21 <jenkins-admin> INFRA-350:Make danielbeck belong to 'admins' LDAP group (Open) https://issues.jenkins-ci.org/browse/INFRA-350
18:41:34 <kohsuke> Shall we move on?
18:41:38 <danielbeck> yes
18:41:54 <kohsuke> #topic HTMLUnit update
18:42:15 <danielbeck> tfennelly/Gus had some concerns about updating HTMLUnit
18:42:23 <danielbeck> We're currently on a patched older release
18:42:28 <danielbeck> Work to fix that is done in https://github.com/jenkinsci/jenkins/pull/1774
18:42:32 <danielbeck> *being done
18:42:45 <danielbeck> And the concern is that it'll break tests in plugins
18:43:08 <danielbeck> This will be relevant when devs update their parent pom version to a newer release that includes new HTMLUnit
18:43:14 <kohsuke> Breaking tests is not as bad as breaking plugins, so I can live with that
18:43:25 <danielbeck> I don't think this is a problem, but wanted to bring this up anyway to get some opinions
18:43:41 <kohsuke> But some of the patches to htmlunit does serve useful purposes
18:43:49 <kohsuke> so we are going to lose them
18:44:01 <KostyaSha> kohsuke, why they wasn't firstly submitted to upstream?
18:44:15 <kohsuke> Many of them are, I believe.
18:44:15 <danielbeck> kohsuke If tfennelly gets core tests to pass it seems to me that plugins should be able to adapt in a similar way
18:44:38 <kohsuke> There's one I remember, for example, which is a pretty big one
18:45:05 <kohsuke> In real JavaScript, everything executes in one thread, including callbacks from XHR.
18:45:06 <tfennelly> and ... worse case scenario they will always be able to work their dependencies to remove the new HtmlUnit and use the jenkins HtmlUnit instead
18:45:07 <danielbeck> Related dev list discussion: https://groups.google.com/d/msg/jenkinsci-dev/woLn-ubRGkY/GpMNiDL3BKYJ
18:45:27 <kohsuke> HtmlUnit doesn't do that. It calls the callback in another thread, running JavaScript concurrently in multiple threads
18:46:22 <kohsuke> But I realize I am minority in my high tolerance level of local patches, so I don't want to block it
18:46:43 <tfennelly> right, I am hitting issues (will be back working on this tomorrow morning I hope) and this could be one that I hit
18:46:58 <kohsuke> IIUC, this htmlunit upgrade was an attempt done in the hope that newer htmlunit will be able to correctly run config-ui-changes branch, which it didn't
18:47:07 <tfennelly> but I think we should get the fixes for these pushed back upstream and stay with the herd
18:47:34 <tfennelly> kohsuke: that is correct
18:48:04 <KostyaSha> jglick, javadocs browsing in artifactory rejected
18:48:13 <tfennelly> that jenkins pages with jquery etc will work
18:48:23 <jglick> KostyaSha: “rejected”?
18:48:27 <danielbeck> If it doesn't work it doesn't work. If we need to patch newer HTMLUnit as well, so be it. But still, the question is, do we care that it'll break tests in plugins when devs update their parent?
18:48:37 <tfennelly> I have verified that the latest HtmlUnit can load the javascript bundles we are trying to load there
18:48:48 <teilo> Update it.  it's currently broken for some plugins anyway (bad JS support).
18:49:07 <teilo> core updates have history of breaking breaking plugin builds anyway
18:49:12 <kohsuke> danielbeck: it's OK for test dependencies to change
18:49:19 <danielbeck> alright so
18:49:21 <KostyaSha> jglick, they think about security in project that has no security and granting write/upload permissions everyone
18:49:47 <jglick> danielbeck: so long as it is possible for a developer to select the newer versions *without* updating the parent, so that they can get ahead of the curve and we can address problems `plugin-compat-tester` finds.
18:51:14 <kohsuke> BTW, patched htmlunit 2.17 https://github.com/jenkinsci/htmlunit/tree/master-2.17
18:51:27 <kohsuke> I did that while working with gusreiber and tfennelly
18:51:55 <kohsuke> Like I said, I'm happy to go back to the prestine 2.17 but if we need those fixes we've got that
18:52:21 <danielbeck> So can we agree that there's no problem here and changes to HTMLUnit can be done as necessary?
18:52:25 <tfennelly> kohsuke: thanks ... I will use that as a ref
18:53:07 <kohsuke> danielbeck: I think that's what we are hearing. No objection raised from anyone
18:53:29 <danielbeck> that's the full extend of what I wanted to discuss here, so that's good
18:53:34 <danielbeck> #agreed changes to HTMLUnit can be done as necessary
18:53:45 <kohsuke> #topic next meeting
18:53:54 <danielbeck> During JUC US West?
18:54:03 <hare_brain> That hasn't gone well in the past.
18:54:10 <kohsuke> I remember the first year we did the project meeting live from JUC
18:54:17 <danielbeck> So the LTS schedule gets delayed by 4 weeks :-/
18:54:37 <kohsuke> hare_brain: can we do it from "meet the community" / "ask the experts" room?
18:54:48 <kohsuke> We did fail to engage audience but if it's just us...
18:55:17 <hare_brain> Right. If it's just us, sure. I meant, the experiment to engage the audience was a failure, and wouldn't want to try that again.
18:55:37 <danielbeck> Tuesday Sep 1 same time maybe?
18:55:48 <hare_brain> What's the agenda at the conference for that time?
18:55:57 <hare_brain> Make sure there are no conflicts with speakers.
18:56:08 <kohsuke> Let me see
18:56:24 <danielbeck> 11:30 AM—12:15 PM Jesse on Workflow
18:56:30 <danielbeck> 10:30 AM—11:15 AM other talks
18:56:42 <kohsuke> #info https://www.cloudbees.com/jenkins/juc-2015/us-west
18:56:42 <hare_brain> Who needs jglick? ;)
18:56:48 <danielbeck> And this meeting is 11-12
18:56:53 <KostyaSha> hare_brain, who needs workflow ;)
18:56:59 <kailoAtWork> After a number of changes by another individual, our jenkins setup is no longer propagating jobs to the slaves correctly.  It was last seen working with the slaves only running build jobs with labels matching this node.   Now, it only seems to work if I open up the slaves to run all jobs (which is not viable)
18:57:21 <danielbeck> kailoAtWork Meeting right now, please wait a bit
18:57:39 <KostyaSha> yes, struggle, because they can't create #jenkins-meeting channel
18:57:52 <danielbeck> KostyaSha The channel exists, I just need to bit robobutler
18:57:55 <danielbeck> *fix
18:58:01 <kailoAtWork> What could be causing this issue?  The starting task always kicks off on the slave, but the actual multi-configuration task sits in a build queue indefinitely
18:58:19 <danielbeck> kohsuke Postpone by 30 minutes so it's during the talk?
18:58:44 <danielbeck> Basically 11:30-12:15 Track 4: Governance Meeting :-)
18:58:54 <kohsuke> I was going to suggest pull up by 30minutes so it's during the other talk
18:59:27 <kohsuke> But I'm fine either way
18:59:31 <danielbeck> later is safer when you forget
18:59:35 <kohsuke> true
18:59:46 <hare_brain> I will be there to remind him. ;)
19:00:04 <danielbeck> Maybe not 'you' the JUC attendees, more in general
19:00:06 <kohsuke> #agreed next meeting is live from JUC but will start 30mins late
19:00:26 <kohsuke> #agreed Sept 2nd 11:30 PT
19:00:31 <kohsuke> OK, I think that's it
19:00:35 <hare_brain> Wait...
19:00:38 <kohsuke> oh
19:00:54 <hare_brain> How does moving it to 11:30 help? That would completely confict with jglick's talk.
19:01:25 <ogondza> so 1.609.3 will be 2 weeks late, not 4?
19:01:31 <kohsuke> I think danielbeck is suspecting jglick is happy to skip ;-)
19:01:43 <danielbeck> ogondza That's what we're trying to set up now by scheduling during JUC
19:01:55 <danielbeck> hare_brain Better that than have all JUC attendees busy at the expert booth
19:02:08 <kohsuke> Shall we do 30mins earlier instead?
19:02:11 <danielbeck> So now the question is just which talk to miss
19:02:37 <danielbeck> And I think 30 min later is better than 30 min earlier for those who forget the different starting time and just show up at 11
19:03:23 <teilo> what's the issue with missing one - IIRC we have slack in the LTS schedule so that it is not presicly every N weeks to account for holidays etc
19:03:47 <danielbeck> teilo We already used all the slack this year I think
19:03:53 <teilo> danielbeck: :-P
19:03:57 * kohsuke hides
19:04:16 <kohsuke> and it's a nice fun addition to the conference I think
19:04:37 <danielbeck> I mean it's not a strict schedule so we could do 4 weeks as well... still, seems unnecessary
19:04:46 <hare_brain> This is my fault for not paying enough attention to the JUC, but is the expert booth being manned full time this year? Is that the concern?
19:04:53 <danielbeck> if everyone here who attends is at the experts booth anyway
19:05:10 * teilo won't be there
19:05:17 <hare_brain> It seems simpler to just keep it at 11, and close the booth for an hour if necessary.
19:05:51 <jglick> ogondza: thanks for JENKINS-29936 backport BTW
19:05:53 <jenkins-admin> JENKINS-29936:deadlock between OldDataMonitor and AuthorizationStrategy. (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-29936
19:06:03 <kohsuke> OK, let's do it. Maybe the agenda gets light and we can wrap up quickly
19:06:12 <kohsuke> danielbeck: is that OK with you?
19:06:16 <danielbeck> sure
19:06:26 <kohsuke> #agreed scratch that, we'll keep the meeting at the same time as usual
19:06:36 <kohsuke> OK, that's it
19:06:42 <hare_brain> Sorry for the confusion.
19:06:57 <kohsuke> #info looking forward to seeing you in JUC!
19:06:59 <kohsuke> #endmeeting