18:00:00 <kohsuke> #startmeeting
18:00:00 <robobutler> Let the Jenkins meeting commence!
18:00:23 <kohsuke> #info https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda
18:00:41 <kohsuke> #topic security bounty
18:01:00 <KostyaSha> kohsuke, note, robobutler constantly disconnecting
18:01:27 <kohsuke> Can you please file it as an INFRA ticket?
18:01:36 <KostyaSha> again :( ok
18:02:00 <kohsuke> So the resolution from the meeting is on http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-04-01-18.02.html
18:03:33 * kohsuke reads
18:04:27 <kohsuke> OK, so the resolution makes sense, I guess someone just has to do it
18:05:11 <kohsuke> actually, we need to come up with the non-cash gift
18:05:28 <hare_brain> And it seems like the carryover question is around historical submitters?
18:05:28 <kohsuke> probably a cafepress gift
18:05:46 <kohsuke> Yes, because there's one guy who really seems to want something, which started the whole thing
18:06:13 <kohsuke> I'd say let's send him the gift but let's no go all the way back
18:06:39 <hare_brain> And it’s been approved and fixed?
18:06:43 <oleg-nenashev> I would propose just to publish list of such contributors with thanks
18:07:04 <kohsuke> We are already doing that. advisory contains the credit section
18:07:44 <oleg-nenashev> A special sticker could be great, but the delivery process is problematic
18:08:18 <KostyaSha> probably just mark somewhere that they can request sticker
18:08:25 <KostyaSha> probably just mark somewhere that they can request sticker  for free
18:08:38 * KostyaSha oops not a skype message editor
18:09:49 <ogondza> I am just wondering, are there any other non-profit projects that give away gifts for security reports?
18:11:21 <jenkins-builds> Project jenkins_main_trunk build #4115: FAILURE in 3 hr 0 min: http://ci.jenkins-ci.org/job/jenkins_main_trunk/4115/
18:11:21 <jenkins-builds> * Jesse Glick: newInstancesFromHeteroList should recover gracefully from the case that both kind and $class are missing.
18:11:22 <jenkins-builds> * Jesse Glick: [FIXED JENKINS-28093] Reverting getDownloadableId from #1563. Not compatible.
18:11:22 <jenkins-builds> * Jesse Glick: [FIXED JENKINS-28110] Always generate stapler-class, even when generating kind.
18:11:23 <jenkins-builds> * Jesse Glick: [JENKINS-28110] Reproduced problem in test.
18:11:23 <jenkins-builds> * Jesse Glick: @kohsuke requested some more comments in the code itself.
18:11:25 <jenkins-admin> JENKINS-28093:404 on jenkins.plugins.nodejs.tools.NodeJSInstaller.json.html (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-28093
18:11:27 <jenkins-admin> JENKINS-28110:1.610 ?Failed to instantiate? error (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-28110
18:11:27 <jenkins-builds> Starting build #4116 for job jenkins_main_trunk (previous build: FAILURE -- last SUCCESS #4114 16 hr ago)
18:11:37 <teilo> docker does.
18:11:53 <jenkins-builds> Project jenkins_main_trunk build #4116: STILL FAILING in 20 sec: http://ci.jenkins-ci.org/job/jenkins_main_trunk/4116/
18:11:54 <jenkins-builds> * alex: JENKINS-26604 Removes try-catch from GlobalSettingsProvider unhelpfully which swallows exceptions
18:11:54 <jenkins-builds> * MMLEGRA: JENKINS-23197: add datestamp to node-offline message
18:11:55 <jenkins-builds> * MMLEGRA: alternative and more general solution suggested by D. Beck
18:11:55 <jenkins-builds> * MMLEGRA: add missing edit to selfcheck
18:11:56 <jenkins-builds> * daniel-beck: [FIXED JENKINS-27067] Larger minimum popup menu height
18:11:56 <jenkins-admin> JENKINS-26604:Maven GlobalSettingsProvider swallows exceptions (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-26604
18:11:56 <jenkins-builds> * dhoover: Synchronize all appropriate methods in ConsistentHash.
18:11:57 <jenkins-builds> * dhoover: Clean up some generics in ConsistentHash and add tests for non-defaults.
18:11:57 <jenkins-builds> * Kohsuke Kawaguchi: [JENKINS-28120]
18:11:58 <jenkins-builds> * Kohsuke Kawaguchi: [JENKINS-28120]
18:11:58 <jenkins-admin> JENKINS-23197:When entering offline reason for a node, it should be prefixed with a date+time stamp (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-23197
18:11:58 <jenkins-builds> * Kohsuke Kawaguchi: Recording the previous change.
18:11:59 <jenkins-builds> * Kohsuke Kawaguchi: Follow up fix to JENKINS-28120.
18:11:59 <jenkins-builds> * Kohsuke Kawaguchi: Timestamp should be a property, and formatting should be done in the UI.
18:12:00 <jenkins-admin> JENKINS-27067:Dropdowns display limited and scrollable (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-27067
18:12:01 <kohsuke> looking but I'm not finding them
18:12:02 <jenkins-admin> JENKINS-28120:Jenkins core to require Java7 (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-28120
18:12:04 <teilo> oganandza ^^
18:12:17 <hare_brain> Need to get the build bot to be quite during meetings. :)
18:12:20 <kohsuke> oh mozilla does: https://www.mozilla.org/en-US/security/bug-bounty/
18:12:38 <kohsuke> ogondza: so I think it's not too common but not unheard of.
18:12:47 <kohsuke> are we trying to push back & revisit the decision?
18:12:49 <KostyaSha> hare_brain, normal projects doing meetings on separate channels ;)
18:13:02 <kohsuke> there's a separate topic about that later
18:13:23 <hare_brain> I don’t have a problem with the decision.
18:13:29 <hare_brain> We’re not going to do money.
18:14:06 <ogondza> I agree, docker seems to do the same thing
18:14:10 <teilo> +1 for a bounty (gift) -1 for retrospective awards, +1 to give the guy/gal a gift as a thankyou for the bounty suggestion
18:14:13 <kohsuke> T-shirt would be in $20-$30 range including shipping, so that should do, right?
18:14:37 <orrc> +1 to teilo
18:14:55 <kohsuke> +1
18:15:14 <hare_brain> +1
18:15:21 <teilo> T-Shirt sounds good. (easy to ship).  Will it be a special design?
18:15:24 <hare_brain> (Retroactive)
18:15:43 <kohsuke> #action kohsuke to update wiki about the token reward, and send the first thank you gift to the guy for the suggestion.
18:16:08 <hare_brain> Did he actually file a vulnerability that got fixed?
18:16:08 <kohsuke> teilo: I'll start with what we have, would love to have someone do another artwork but I will forget if I wait for that
18:16:12 <kohsuke> hare_brain: yes
18:16:15 <hare_brain> OK
18:16:32 <kohsuke> #agreed -1 for retrospective awards, +1 to give the guy/gal a gift as a thankyou for the bounty suggestion
18:16:39 <kohsuke> That's enough for this, I think. Shall we move on?
18:17:00 <kohsuke> #topic Trademark usage approval for "CloudBees Jenkins Platform"
18:17:01 <teilo> kohsuke: ok.
18:19:23 <kohsuke> #info https://groups.google.com/d/msg/jenkinsci-dev/mImqR4sUiys/TvDEdUHx-QQJ
18:19:54 <kohsuke> hare_brain: yes, so we wrote https://www.cloudbees.com/jenkins/about and I believe our materials/publications have been updated to refer to this.
18:20:06 <hare_brain> Right. So I’m +1 for this request.
18:20:33 <kohsuke> Thanks. And as usual I'm abstaining for conflict of interest
18:21:01 <kohsuke> And it'd be great if more people can vote.
18:21:26 <ogondza> does that mean products can use Jenkins in the name freely now? provided they show the attribution
18:21:41 * teilo abstains
18:21:48 <kohsuke> No, as written in https://gist.github.com/kohsuke/573cb5620fcc25c9e5c0/4adb656ca15cac5707ee8fa1e4dabb56855e31c3 it's not a blanket approval.
18:21:58 <kohsuke> So each one has to come back to here, like I'm doing now.
18:22:03 <ogondza> i see
18:22:30 <kohsuke> But it does set some expectation as to what's likely OK and what's not, which is good.
18:22:33 <hare_brain> ogandza: Not necessarily. I think it’s still preferable to have the requests come in. But with the attribution, we agonize less about the naming pattern, and whether it too closely associated Jenkins with a commercial entityt.
18:22:56 <teilo> ogondza: I would still think that there should be some approval and restrictions rather than an allow all so long as there is attribution (otherwise IANAL defeding the mark could become harder)
18:23:11 <hare_brain> We spent a *long* time going back and forth about the previous set of requests from CB before.
18:23:34 <kohsuke> I lost a lot of sleep on that one!
18:23:42 <hare_brain> teilo right. Having the audit trail shows that we are actively monitoring for uses of the trademark.
18:24:55 <kohsuke> ogondza: do you have +1 / -1 / etc?
18:25:00 <hare_brain> A bit of a tangent while we wait for more votes: what ever happened that that site Kohsuke you discovered that was using Jenkins without our approval?
18:25:08 <ogondza> +1 on your request
18:25:17 <kohsuke> ogondza: thanks
18:25:25 <kohsuke> hare_brain: yeah, I was thinking about that one as I wrote that email
18:25:35 <danielbeck> hare_brain http://jenkinshosting.com/ ?
18:26:01 <danielbeck> They added 'by Bubbleware Tech' but without approval otherwise IIRC
18:26:07 <oleg-nenashev> I also have a potential conflict of interest. No vote
18:26:09 <hare_brain> Yes that one.
18:26:27 <hare_brain> That site is getting fancy.
18:26:48 <danielbeck> let's discuss that one some other time
18:26:55 <hare_brain> OK
18:27:00 <kohsuke> If we don't feel like approving them I can go back to him
18:27:15 <KostyaSha> hmm... and this site https://jenkins.ci.cloudbees.com/ has cut "jenkins" mentioning in footer?
18:27:35 <KostyaSha> i can mistake of course
18:27:36 <kohsuke> Otherwise I offered to him that I'm happy to work as a liason to get "Jenkins Hosting by Bubbleware Tech" approved
18:28:19 <danielbeck> kohsuke They should at least ask
18:28:20 <kohsuke> KostyaSha: yeah, our fault. I'll ask something be added, like "Powered by Jenkins" or something
18:28:42 <hare_brain> We should ask for the attribution, and we can be done with that one too.
18:29:24 <kohsuke> #action kohsuke to go back about jenkinshosting.com thread, asking them to submit a request in email, and attribution
18:29:43 <kohsuke> danielbeck: you OK if they don't show up in IRC? Or do you want them to?
18:30:18 <danielbeck> IRC is where we'd vote on it, but I don't think they need to participate
18:30:20 <kohsuke> I suppose I can ask
18:30:36 <hare_brain> Someplace that publicly shows the conversation.
18:30:42 <kohsuke> All right, moving on...
18:30:43 <danielbeck> may look better and swing a vote their way :-)
18:30:44 <hare_brain> Could be the dev list as well for that purpose.
18:31:01 <kohsuke> #topic We only allow OSS plugins to be distributed via the update center, but what about closed source plugins which are documented on our wiki?
18:31:09 <kohsuke> who is the sponsor of this topic?
18:31:20 <KostyaSha> dunno but i have opinion
18:31:22 <oleg-nenashev> I just wonder what happens if we don't allow the usage w/o having them on the meeting...
18:31:23 <danielbeck> kohsuke What about your request for Platform? Was that decided?
18:31:29 <kohsuke> oh
18:31:36 <kohsuke> indeed
18:31:46 <kohsuke> #topic Trademark usage approval for "CloudBees Jenkins Platform"
18:32:07 <kohsuke> anyone else who want to vote? A few more +1s would be greatly appreciated
18:32:20 <danielbeck> abstain
18:32:26 <kohsuke> #action kohsuke needs to chase abayer to get his +1 recorded
18:32:30 * KostyaSha abstain
18:32:35 <oleg-nenashev> abstain
18:32:48 * teilo abstain
18:33:10 <kohsuke> I guess I have all the votes I can get here then
18:33:10 * jglick abstrains just to join the party
18:33:37 <kohsuke> I think this does qualify for agreement though.
18:33:41 <kohsuke> Just wished we had more votes
18:33:57 <kohsuke> #agreed CloudBees Jenkins Platform is OK, subject to the same condition as before: https://gist.github.com/kohsuke/573cb5620fcc25c9e5c0/4adb656ca15cac5707ee8fa1e4dabb56855e31c3
18:34:17 <kohsuke> Now I'm really going to move on...
18:34:22 <kohsuke> #topic We only allow OSS plugins to be distributed via the update center, but what about closed source plugins which are documented on our wiki?
18:34:35 <hare_brain> According to the page history, that was added by domi
18:34:36 <KostyaSha> Hm.. hosting request must have "by company" but platfrom not.. looks inconsistent
18:35:09 <kohsuke> I'm -1 on hosting closed source plugins from our update center
18:35:16 <KostyaSha> My proposal will be enhance UC usage and split like yum/debian repos do
18:35:32 <KostyaSha> then closed sources can go to other repository
18:35:52 <kohsuke> The community can't take over those plugins and UC is an important incentive to bring people to the community.
18:36:02 <oleg-nenashev> Discussion link: https://groups.google.com/forum/#!searchin/jenkinsci-dev/Chat$20Room/jenkinsci-dev/oEHEjKo08yA/oKZ-Ubb_CLsJ
18:36:06 <danielbeck> It's a bit related to what I asked about in October (and still didn't act on) wrt. plugins developped outside Jenkins infra, using different issue tracker, etc.
18:36:17 <KostyaSha> kohsuke, all linux distros already resolved such problems many years ago
18:36:24 <ogondza> KostyaSha: or the authors can host the other UC on their own
18:36:47 <orrc> I think that the UC is only for open source is clear. the question was more about closed source/commercial pages on the wiki?
18:36:51 <kohsuke> KostyaSha: right, by letting them create their own UCs, and people can do the same with Jenkins today
18:37:04 <KostyaSha> ogondza, +1 the same as linux mirrors of any repo, but jenkins can provide hosting or so called "home" projects and provide better user friendly UC handling
18:37:14 <kohsuke> orrc: oh you are right, I totally misread
18:37:51 <KostyaSha> about documentation i think no matter where and who wrote it
18:37:53 <kohsuke> https://wiki.jenkins-ci.org/display/JENKINS/CxSuite+Jenkins+Plugin is relevant to Jenkins, so I think this one is OK
18:38:04 <KostyaSha> wiki is just a trash can for pages :)
18:38:04 <kohsuke> I just wish it didn't read so much like marketing
18:38:07 <oleg-nenashev> I would +1 for such pages if they have a proper warning on the top of the page
18:38:40 <kohsuke> And link doens't even work :-(
18:38:51 <orrc> it seems redundant; people googling for that plugin will find their website
18:38:52 <KostyaSha> btw nowadays gh-pages also good, so wiki can be used as just a place for pages (not matter for what plugins), but +1 for warning about closed source/etc
18:38:55 <hare_brain> I clicked on this one at random thinking it was OSS, but it’s not: https://wiki.jenkins-ci.org/display/JENKINS/Config+Rotator+Plugin
18:39:15 <hare_brain> I like this approach, where they’ve got the company logo off on the side, but otherwise, it’s the standard plugin page.
18:39:51 <kohsuke> Right, +1 to what Praqma is doing
18:39:55 <danielbeck> https://wiki.jenkins-ci.org/display/JENKINS/Praqma ?
18:40:04 <kohsuke> And that one is open-source plugin
18:40:06 <KostyaSha> there are 2 places with praqma
18:40:22 <hare_brain> Perforce has a slightly different layout, but similar on concept: https://wiki.jenkins-ci.org/display/JENKINS/P4+Plugin
18:40:42 <hare_brain> Although these are still open sourced, just maintained by a commercial company.
18:40:55 <oleg-nenashev> I suppose Praqma does the things well in the case of OSS plugins on the main jenkins repo
18:41:33 <orrc> I think non-OSS plugins should not have wiki pages (so no CxSuite Plugin)
18:41:39 <orrc> the https://wiki.jenkins-ci.org/display/JENKINS/Commercial+Support page can mention the companies and have an external link, but there should not be a further page like the standalone Praqma page
18:41:47 <hare_brain> Yeah, I think I agree with orrc.
18:42:13 <KostyaSha> first of all i think that all jenkinsci plugins must have wiki page
18:42:30 <kohsuke> OK, so maybe we'll move a bit of this in https://wiki.jenkins-ci.org/display/JENKINS/Commercial+Support and delete the page itself?
18:42:50 <oleg-nenashev> I see no problem in such company page if it's organized properly and moved to a dedicated folder.
18:42:59 <kohsuke> I should probably notify the author as well if we are to do that
18:43:22 <KostyaSha> kohsuke,  there is no clear strategy about confluence at all, this discussion becomes randoom, plugins, companies
18:43:46 <KostyaSha> praqma has 2 spaces: 1) mentioned on this page 2) separate page
18:43:48 <hare_brain> Commercial Support seems a little bit different than commercial/closed source plugins.
18:44:20 <orrc> so is the original question is answered? maybe the tangential topics can go to the dev list / another meeting?
18:44:21 <danielbeck> If the concern is that the community should be able to step in if maintainers lose interest, it's pretty clear that plugins must be completely integrated in Jenkins infra. That means code hosted primarily in (and released from) @jenkinsci/our SVN; use of Jira, having a wiki page and linking that from the POM. Only then does distribution via our UC make sense.
18:44:50 <danielbeck> And use of the Jenkins infra must in turn require being an OSS plugin.
18:44:55 <hare_brain> danielbeck I don’t see how we can do that for a commercial/closed source plugin
18:45:10 <teilo> +1 for what danielbeck said
18:45:28 <danielbeck> hare_brain Well, we don't. You're free to write whatever you want, but you don't get any of the project infra for it.
18:45:43 <danielbeck> That means no UC distribution, no wiki pages, and no issue tracker.
18:46:06 <teilo> should we should perhaps allow a commecial plugin to be distributed if the compnay makes a donation?
18:46:18 <danielbeck> teilo -1
18:46:22 <hare_brain> Ugh. Would rather not get into *that* conversation. :)
18:46:23 <KostyaSha> there is no guarantee for plugins that random persons wouldn't commit to it directly
18:46:30 <oleg-nenashev> -<all votes I have>
18:46:43 <kohsuke> orrc: I think the emerging consensus seems to be that proprietary Jenkins plugins aren't welcome on our Wiki
18:46:54 <danielbeck> kohsuke ... and UC
18:46:57 <kohsuke> (trying to bring the conversation back to the original question)
18:47:02 <KostyaSha> teilo, i think better create infra that will allow working with additional UCs
18:47:14 <kohsuke> danielbeck: Yes, and I was wrong in assuming that domi was asking for that, which he wasn't.
18:47:20 <oleg-nenashev> We cannot easily distinguish commercial and non-commercial plugins
18:47:28 <KostyaSha> even 'personal update centers' like it done in linux distros
18:47:45 <oleg-nenashev> KostaSha: There's a support of multiple UCs
18:47:48 <orrc> this is off-topic, but there are legit reasons to host OSS plugins outside of jenkinsci, e.g. a company has their own github organisation, wants to manage users there, use gitter IM and other tools that require admin access.  if the plugin does end up abandoned and the community wants to take over maintainership, the plugin can be forked into jenkinsci
18:48:11 <KostyaSha> oleg-nenashev, there is no good integration and etc. If it not user friendly then nobody will use it
18:48:29 <danielbeck> KostyaSha Is this really essential to this discussion?
18:48:44 <orrc> kohsuke: ok, consensus is good. can we move on? :)
18:48:49 <hare_brain> So no wiki page for something like CxSuite. But do we offer some place for them to have a link?
18:48:57 <KostyaSha> danielbeck, imho all this questions related, just deprecated closed source plugins is not a solution
18:49:16 <kohsuke> hare_brain: Yes, I'd hope so, as this is quite related to Jenkins
18:49:28 <danielbeck> orrc You're free to host your own, but prepare to explain to users how to set up UpdateSites Manager Plugin
18:49:33 <kohsuke> this isn't like some Indonesian trying to sell some drug
18:49:33 <KostyaSha> danielbeck, provide good platform that will work for all cases and then enforce rules
18:49:53 <hare_brain> Maybe just carve off a “Commercial Plugins” section on the plugins that points them off to their site?
18:50:03 <orrc> nobody comes to the wiki searching for plugins. you hit the wiki from google. so somebody searching for "jenkins cxsuite" will hit that company's documentation for the plugin
18:50:21 <orrc> there's no need for a separate section or link on the wiki, imo
18:50:26 <KostyaSha> orrc, this is because current wiki organisation... has no...
18:50:57 <ogondza> orrc: +1
18:51:09 <oleg-nenashev> We could add new macros. It's easy, the only question is to find enough time
18:51:50 <kohsuke> It just seems like having links to Jenkins related stuff is useful, the same reason we link books and commercial support pages
18:52:11 <hare_brain> Googling for jenkins cxsuite returns the existing wiki page as the first hit.
18:53:52 <oleg-nenashev> it depends on the history of your searches
18:53:55 <kohsuke> I'll contact them if they are just willing to open-source their plugin
18:54:15 <kohsuke> I see no reason why they want to keep it to themselves.
18:54:20 <KostyaSha> in comparison to linux distros things that you are discussing was created 5 years ago, i'm abstain on this topic item now
18:56:11 <danielbeck> Maybe we should have something similar for commercial/closed-source plugins
18:56:17 <kohsuke> Is that OK enough for now, or do we want to resolve something stronger about "commercial" stuff on our Wiki?
18:56:38 <KostyaSha> The effort of the Debian project is to build a free operating system, but not every package we want to make accessible is free in our sense (see the Debian Free Software Guidelines, below), or may be imported/exported without restrictions. Thus, the archive is split into areas[3] based on their licenses and other restrictions.
18:56:38 <hare_brain> Not in the time that we have left.
18:58:07 <hare_brain> Fair enough
18:58:19 <kohsuke> #topic Should we only include plugins in the Update Centre if they have a wiki page?
18:58:28 <kohsuke> oh I see it's all inter-related
18:58:38 <kohsuke> #info https://groups.google.com/forum/#!msg/jenkinsci-dev/oEHEjKo08yA/_z2GEtcUfz0J
18:58:44 <KostyaSha> i think it will eat all meeting time
18:58:55 <danielbeck> Yes. And get rid of the code to determine the wiki page automatically.
18:59:25 <KostyaSha> there are many old plugins that may have no pages, Who wants wrote 1k pages with descriptions?
18:59:33 <danielbeck> basically make <url> in POM mandatory for UC distribution
18:59:49 <kohsuke> I wonder how many plugins would be impacted.
19:00:02 <danielbeck> KostyaSha UC generator knows when it was built so these old releases can be grandfathered it
19:00:05 <teilo> +1 on db's suggestion (does not need to be a wiki IMHO - could be github readme.md)
19:00:14 <KostyaSha> i propose collect statistics firstly for discussion
19:00:22 <danielbeck> teilo Wiki page is better as it has the macro
19:00:23 <kohsuke> +1 for applying rules like this going forward
19:00:57 <danielbeck> from October:
19:00:58 <kohsuke> I'd also suggest we allow the older plugins as-is for now
19:01:00 <danielbeck> 18:16:04 <danielbeck> 35 plugins specify no wiki URL, leaving the update center to guess or not specify an URL
19:01:03 <danielbeck> 18:16:08 <danielbeck> 9 plugins specify URLs (linked from update center) that aren't wiki.jenkins-ci.org / wiki.hudson-ci.org
19:01:06 <teilo> danielbeck: but missing other features..
19:01:32 <danielbeck> teilo IMO it could just point to the 'real' documentation to Github
19:02:22 <KostyaSha> +1 for danielbeck to update this plugins or those who doesn't like it and then +1 for enforcing rules with not publishing new +1 for adding to documentation enforcement
19:02:43 <ogondza> I have to run now, for LTS.next I propose 1.608. If the decision is not made in meeting time, I will propose that on dev list tomorrow.
19:02:56 <kohsuke> Yeah, time check
19:03:06 <kohsuke> I do want to talk a bit about LTS.next because that's kind of time sensitive
19:03:11 <danielbeck> ogondza 1.609 is just one user complaining about SSH Slaves AFAICT
19:03:57 <danielbeck> kohsuke Postpone this item and continue with LTS?
19:04:11 <kohsuke> Yes, let's do that, sorry orrc
19:04:15 <kohsuke> #topic LTS.next
19:04:28 <orrc> np
19:04:50 <kohsuke> ogondza: are you still around or already gone?
19:04:58 <ogondza> danielbeck: what issue is that?
19:05:08 <danielbeck> ogondza The changelog linked issues
19:05:16 <kohsuke> stephenc told me that he would like to get 1.610 but he recognize it's rather new
19:05:21 <danielbeck> 1.609 has mixed feedback: JENKINS-14332 JENKINS-17366 JENKINS-13237 JENKINS-18706 JENKINS-25997
19:05:24 <jenkins-admin> JENKINS-14332:Repeated channel/timeout errors from Jenkins slave (Open) https://issues.jenkins-ci.org/browse/JENKINS-14332
19:05:26 <jenkins-admin> JENKINS-17366:ssh slave login via keyfile not working in 0.23 (In Progress) https://issues.jenkins-ci.org/browse/JENKINS-17366
19:05:26 <KostyaSha> no 1.610
19:05:28 <jenkins-admin> JENKINS-13237:Unsuccessful SSH slave start do not timeout and cannot be retry, even manually (Open) https://issues.jenkins-ci.org/browse/JENKINS-13237
19:05:30 <jenkins-admin> JENKINS-18706:ssh-saves 0.27 and jenknis 1.522 not working: java.io.IOException: Unexpected termination of the channel (Open) https://issues.jenkins-ci.org/browse/JENKINS-18706
19:05:32 <jenkins-admin> JENKINS-25997:Jenkins node connectivity Issue using SSH agent (Open) https://issues.jenkins-ci.org/browse/JENKINS-25997
19:05:33 <kohsuke> And I believe glick has a thought too
19:06:05 * jglick scrambles for changelog
19:06:17 <danielbeck> I understand 1.610 would be preferable because of CB Templates, but the descriptor issue is still ongoing AFAICT
19:06:18 <kohsuke> 1.608 is nice in that packaging was normalized
19:06:25 <orrc> jglick said on the list "hoping for 1.607+ definitely, or 1.609+ ideally"
19:06:27 <danielbeck> kohsuke We don't even have a tag for 1.608
19:06:40 <jglick> #info http://jenkins-ci.org/changelog click both upcoming changes & community ratings
19:06:56 <jglick> yeah I think 1.608 may have gotten botched somehow?
19:07:17 <danielbeck> that was the one with the half dozen changelog entries as well IIRC
19:07:45 <kohsuke> just pushed it
19:08:34 <danielbeck> e544304c0b11df946c0cdb7a79535785a08ad746
19:08:43 <teilo> didn;t stephenc mention he wanted 1.610 even though it was not a candidate?
19:08:49 <kohsuke> 1.609 doesn't look like it contains any problem commit though
19:08:58 <jglick> What makes 1.610 not a candidate? Two-week rule?
19:09:14 <KostyaSha> jglick, broken archivation
19:09:14 <kohsuke> yeah
19:09:21 <KostyaSha> broken maven plugin
19:09:23 <danielbeck> jglick Broken descriptors
19:09:24 <oleg-nenashev> we would have to backport almost everything from 1.611
19:09:39 <teilo> I guess so..
19:09:47 <oleg-nenashev> What about 1.611 BTW?
19:09:49 <KostyaSha> because of this issues most people reverted jenkins
19:09:50 <danielbeck> Archiving wouldn't be that bad we have a fix. But are we positive the descriptor ID issue is resolved?
19:10:00 <jglick> I intend to propose the fixes to Descriptor in 1.610, 1.611, and 1.612 as backports anyway.
19:10:05 <KostyaSha> so 1.610 is not something well used/reported at all
19:10:14 <danielbeck> jglick Too recent for a new baseline IMO
19:10:19 <jglick> Because the state in 1.609 (back to 1.598 IIRC) is definitely wrong.
19:10:47 <danielbeck> When is RC scheduled? In two weeks
19:10:47 <danielbeck> ?
19:10:52 <ogondza> yes
19:11:26 <ogondza> 2 weeks from the decision is made
19:11:40 <jglick> The fixes to the queue in 1.610 are important too, although it is not quite clear to me whether all the regressions have been cleaned up yet.
19:11:54 <danielbeck> jglick That would be a definite backport IMO
19:12:01 <jglick> Which would be?
19:12:10 <danielbeck> queue fix
19:12:10 <KostyaSha> i think >1.610 is not well tested at all, is there any statistics about number of installations?
19:12:26 <danielbeck> jglick Did you look into performance and node plugin?
19:12:28 <jglick> The 1.610 Queue fix was pretty complicated, I am not sure it would work well as a backport (tricky to merge).
19:12:38 <jglick> danielbeck: yes those should be fixed in 1.612 already (merged today)
19:12:57 <danielbeck> jglick Is the fix something that should resolve it for other plugins with similar issues as well?
19:13:08 <jglick> danielbeck: yes I think so. Of course without a global test suite I cannot be sure I am done here.
19:13:36 <danielbeck> Honestly I'd like to push the schedule back two weeks
19:13:42 <danielbeck> we have no good choices right now
19:14:16 <KostyaSha> +1 for deciding later
19:14:22 <kohsuke> You don't like 1.608 either?
19:14:40 <KostyaSha> kohsuke, it doesn't satisfy other people as i see
19:14:41 <danielbeck> 1.608 has the original descriptor problem, and the queue issue
19:14:52 <danielbeck> queue was broken in 1.607 IIRC
19:15:09 <oleg-nenashev> queue issue can be backported, but we're not sure about the fix reliability
19:15:11 <kohsuke> 1.606 or 1.605 has great feedback scores
19:15:34 <ogondza> 1.607 is ~12 weeks after the previous one
19:15:43 <jglick> Right, main Queue change was in 1.607, my mistake.
19:15:52 <oleg-nenashev> kohsuke: too close to the previous LTS., there was no major features
19:16:15 <danielbeck> 1.606 would be feasible, except for the original descriptor issue from 1.59x
19:16:15 <ogondza> kohsuke: 606 has security fixes
19:16:17 <KostyaSha> picking lts now can delay many awaited fixes in LTS base line
19:17:07 <ogondza> oleg-nenashev: is that a problem?
19:17:08 <danielbeck> jglick Issue is way older, you just made it painful enough to require a fix so that's a win :-)
19:17:48 <kohsuke> I think we should stick to the train model
19:17:55 <oleg-nenashev> ogondza: I think it's not a problem, but an additional LTS to a previous line could be preferable
19:18:51 <danielbeck> Do we know how much users rely on the train?
19:19:09 <danielbeck> If they do and expect an RC in two weeks, we should deliver
19:19:22 <danielbeck> (RC of new 1.xxx.1 that is)
19:19:45 <KostyaSha> can RC be skipped? and new xxx.1 RC be picked?
19:19:54 <KostyaSha> if testing will show that it bad
19:20:03 <kohsuke> I got positive feedbacks on the train model in the past JUC tours especially from people in the large companies
19:20:11 <jglick> I think it is only a “candidate” insofar as a candidate can be rejected. :-)
19:20:48 <oleg-nenashev> For large companies we should include queue fixes to as a car to the new train
19:21:00 <KostyaSha> this should also indicate how really "large companies" testing RC
19:21:28 <teilo> KoysyaSha - from my prior life badly :-)
19:21:44 <oleg-nenashev> I suppose it would be the most expected feature. Previous release include minor changes exception JENKINS-24380
19:21:46 <jenkins-admin> JENKINS-24380:Use build numbers as IDs (Resolved) https://issues.jenkins-ci.org/browse/JENKINS-24380
19:21:47 <danielbeck> could we choose aggressively (i.e. new version) and just tell users to test really well this time because of that?
19:21:50 <jglick> To be clear, train model would mean 1.609 and whatever backports are needed to deal with regressions between 1.596–1.609, right?
19:22:20 <kohsuke> train model means picking one today
19:22:36 <kohsuke> i.e., not pushing it for two weeks
19:22:44 <jglick> I meant 1.609 as the most recent build which is at least two weeks old as of today.
19:23:08 <danielbeck> train is just release date, not which baseline is chosen
19:23:09 <teilo> we also said this would be Java7 only...
19:23:16 <oleg-nenashev> jglick: AFAIK we have such rule for backporting only
19:23:41 <orrc> I imagine companies using the *stable* release line would rather wait two extra weeks in this one difficult case, so that they get a better baseline (and there's less backporting work required)
19:23:52 <ogondza> danielbeck: the rc testing feedback is poor despite my efforts, doubt it would help us
19:24:38 <danielbeck> realistically, what are the choices? 606 seems safest, while 609 would be good IF the fixes (queue and descriptor) qualify and are good enough
19:24:53 <kohsuke> it's unclear if we have anything better to pick in two weeks
19:25:12 <kohsuke> If I'm hearing right, I think 1.606 is the leading option
19:25:26 <danielbeck> kohsuke In two weeks we'd know whether the descriptor fixes are good enough
19:25:28 <kohsuke> I believe 1.607 has some much wanted changes for workflog plugin
19:25:47 <danielbeck> kohsuke 1.607 completely broke the queue, Throttle concurrent builds plugin etc.
19:25:48 <oleg-nenashev> And queue performance...
19:26:06 <kohsuke> but I guess people aren't comfortable enough for 1.607.
19:26:15 <oleg-nenashev> danielbeck: Queue fix from 1.610 can be easily backported
19:26:32 <danielbeck> oleg-nenashev Which release was the big queue overhaul?
19:26:39 <danielbeck> 1.607?
19:26:41 <jglick> (More precisely, workflow-plugin is awaiting things in both 1.607 and 1.609. If they do not come in this round, so be it.)
19:27:17 <oleg-nenashev> danielbeck: 1.607 + fix in 1.610
19:27:18 <jglick> Yeah 1.607 was the big Queue change, with some minor regression fixes thereafter like in 1.610 and 1.612.
19:27:38 <danielbeck> okay so if we're considering 1.609, 1.607 wouldn't be worse for backporting
19:28:14 <KostyaSha> jglick,  as teilo mentioned 1.612 will be java7?
19:28:27 <jglick> Correct, 1.612 is 7+ only.
19:28:35 <KostyaSha> but lts must be 1.6?
19:28:40 <danielbeck> but why would 1.609 be worse than 1.607? both have the descriptor issue, and need a minor queue fix?
19:28:49 <danielbeck> otherwise they seem identical
19:28:50 <KostyaSha> 7+ requirement can be reverted as  i see
19:29:26 <teilo> I thought the next LTS would be Java7.
19:29:38 <jglick> Yes the 7+ requirement is so far a small patch, easily reverted (that was intentional).
19:29:58 <jglick> (Or easily backported if we pick a pre-1.612 and want the LTS to be 7+.)
19:30:21 <kohsuke> jglick: is getting 1.607 as the base line no good for the workflow stuff, compared to 1.606?
19:30:22 <KostyaSha> so it not issue, ok
19:30:40 <jglick> kohsuke: 1.607 is better than 1.606, and 1.609 is better than both
19:30:47 <jglick> (from that limited perspective)
19:30:54 <kohsuke> Thanks
19:31:28 <danielbeck> jglick Would we want to backport the descriptor changes to LTS?
19:31:33 <ogondza> sorry I really have to run now
19:31:35 <teilo> my bad - I thought we had said that the next LTS would be java7, but we said it could be 1.7
19:31:36 <oleg-nenashev> If we take 1.609, than we backport everything from 1.610. So it makes sense to increment the version
19:31:40 <jglick> I feel like the discussion is confused because we have a pseudo-train model, and have conflicting considerations of user features (or major fixes), APIs, and avoiding regressions.
19:32:11 <kohsuke> danielbeck: I think I propose 1.607. It has some issues, but fixes can be backported, and it's older and that brings some comfort.
19:32:29 <jglick> oleg-nenashev: the tar change would have to be reverted if we started with 1.610. Not that that is difficult, just pointing it out.
19:32:49 <KostyaSha> jglick, because of tar this version was not well used, what other changes does it have?
19:33:08 <danielbeck> the descriptor fix
19:33:17 <danielbeck> was added in 1.610 as well
19:33:25 <KostyaSha> remoting update?
19:33:26 <danielbeck> which required rework in 1.611 and 1.612
19:34:01 <jglick> Yeah, starting from 1.607 I would *propose* backporting a series of Descriptor fixes, but can certainly understand getting pushback on that.
19:36:22 <jglick> #info https://github.com/jenkinsci/jenkins/compare/jenkins-1.607...jenkins-1.609
19:36:27 <kohsuke> I'm just trying to build some consensus here.
19:36:37 <kohsuke> We need to start agreeing on something or we'll be here forever
19:36:58 <kohsuke> danielbeck: do you want to propose 1.609?
19:37:27 <danielbeck> kohsuke Yes, it looks better than 1.607
19:37:59 <danielbeck> kohsuke Assuming there's no packaging related issue
19:38:26 <kohsuke> I'm not aware of any.
19:38:38 <kohsuke> OK, anyone wants to disagree with 1.609?
19:39:01 <kohsuke> going once...
19:39:12 <oleg-nenashev> no, +1 for 1.609
19:39:24 <jglick> Hold on, let us take a look at changes since then?
19:39:34 <jglick> (For things omitted from changelog.)
19:39:47 <danielbeck> jglick jenkins-1.609...master or WDYM?
19:39:54 <KostyaSha> https://github.com/jenkinsci/jenkins/compare/jenkins-1.609...master ?
19:39:58 <jglick> #info https://github.com/jenkinsci/jenkins/compare/jenkins-1.609...master
19:40:32 <jglick> Anyway, provisional +1 for 1.609.
19:41:18 <KostyaSha> +1 1.609
19:41:27 <kohsuke> #agreed next LTS will be based on 1.609
19:41:53 <kohsuke> #topic next meeting
19:42:09 <danielbeck> too late for other topics?
19:42:23 <KostyaSha> i still have not answered item from pre 1apr...
19:42:36 <kohsuke> #info next meeting will be in May 13th
19:43:23 <kohsuke> danielbeck: let's end the meeting but we can have some discussions to help build the consensus
19:43:37 <kohsuke> KostyaSha: I'm sorry, which one did I leave out?
19:43:52 <kohsuke> #endmeeting