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