13:49:58  * bnoordhuisquit (Ping timeout: 260 seconds)
14:00:01  * jenkins-monitorquit (Remote host closed the connection)
14:00:16  * jenkins-monitorjoined
14:04:28  * DavidTPatejoined
14:32:46  * DavidTPa_joined
14:36:10  * DavidTPatequit (Ping timeout: 260 seconds)
14:40:46  * chorrelljoined
14:42:21  * DavidTPa_quit (Quit: My Mac has gone to sleep. ZZZzzz…)
14:47:39  * DavidTPatejoined
14:48:10  * DavidTPatequit (Client Quit)
14:55:51  * bnoordhuisjoined
14:59:23  * DavidTPatejoined
14:59:23  * DavidTPatequit (Client Quit)
15:00:01  * jenkins-monitorquit (Remote host closed the connection)
15:00:09  * bnoordhuisquit (Ping timeout: 245 seconds)
15:00:16  * jenkins-monitorjoined
15:18:17  * bnoordhuisjoined
15:20:46  * trottjoined
15:23:59  <joaocgreis>rvagg: now I understand the "wanted them bad", the new icons are way way better than the old faded and flashing icons
15:25:09  * trottquit (Ping timeout: 245 seconds)
15:26:49  * thealphanerdquit (Ping timeout: 245 seconds)
15:28:52  * thealphanerdjoined
15:30:04  * chorrellquit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:30:43  * rmgjoined
15:31:30  <joaocgreis>jbergstroem, rvagg: please don't update jenkins unless there's some new feature you want... test-commit is broken again because of the multijob plugin, this is so frustrating.
15:35:37  * rmgquit (*.net *.split)
15:35:38  * thealphanerdquit (*.net *.split)
15:35:39  * bnoordhuisquit (*.net *.split)
15:37:07  * joaocgreisquit (*.net *.split)
15:37:21  * jbergstroemquit (*.net *.split)
15:37:26  * michael___quit (*.net *.split)
15:37:28  * benglquit (*.net *.split)
15:37:33  * starefossenquit (*.net *.split)
15:39:12  * rvaggquit (*.net *.split)
15:41:25  * orangemochaquit (Ping timeout: 246 seconds)
16:00:02  * jenkins-monitorquit (Remote host closed the connection)
16:00:16  * jenkins-monitorjoined
16:12:57  * orangemochajoined
16:12:57  * rvaggjoined
16:12:57  * starefossenjoined
16:12:57  * thealphanerdjoined
16:12:57  * bnoordhuisjoined
16:12:57  * joaocgreisjoined
16:12:57  * jbergstroemjoined
16:12:57  * michael___joined
16:12:57  * bengljoined
16:15:21  * orangemochaquit (Changing host)
16:15:21  * orangemochajoined
16:22:43  * orangemochaquit (*.net *.split)
16:22:48  * rvaggquit (*.net *.split)
16:22:51  * starefossenquit (*.net *.split)
16:23:02  * joaocgreisquit (*.net *.split)
16:23:04  * jbergstroemquit (*.net *.split)
16:23:05  * michael___quit (*.net *.split)
16:23:06  * benglquit (*.net *.split)
16:23:14  * thealphanerdquit (*.net *.split)
16:23:14  * bnoordhuisquit (*.net *.split)
16:46:48  * orangemochajoined
16:46:49  * rvaggjoined
16:46:49  * starefossenjoined
16:46:49  * bengljoined
16:46:49  * michael___joined
16:46:49  * jbergstroemjoined
16:46:49  * joaocgreisjoined
16:46:49  * bnoordhuisjoined
16:46:49  * thealphanerdjoined
16:48:20  * orangemochaquit (Changing host)
16:48:20  * orangemochajoined
16:49:59  * bnoordhuisquit (Ping timeout: 260 seconds)
16:56:36  * rmgjoined
17:00:01  * jenkins-monitorquit (Remote host closed the connection)
17:00:15  * jenkins-monitorjoined
17:05:43  * orangemochachanged nick to Guest95756
17:31:37  * jgijoined
17:35:16  * bnoordhuisjoined
17:41:35  * orangemochajoined
17:42:00  * orangemochachanged nick to Guest8425
17:42:37  <Guest8425>rvagg jbergstroem: sorry, having issues with irccloud. The hosting provider is 'azure' and the sponsor is Microsoft, so should we add both, as in 'azure-msft' according to the new naming conventions?
17:43:04  * Guest8425quit (Read error: Connection reset by peer)
17:50:19  * Guest95756part
17:51:18  * orangemocha_joined
17:56:26  * orangemocha__joined
17:56:31  * orangemocha__quit (Read error: Connection reset by peer)
17:57:21  * orangemocha_changed nick to orangemocha
17:57:46  <orangemocha>that was me ^^
18:00:01  * jenkins-monitorquit (Remote host closed the connection)
18:00:16  * jenkins-monitorjoined
18:01:35  * jgiquit (Quit: jgi)
18:08:28  * jgijoined
18:18:51  * trottjoined
18:20:27  <trott>jbergstroem: Is there a written plan/status/something for debug builds? Basically, what's the anticipated slowest debug build that is likely to run tests and can I find out (either by being told or running the test myself) what tests timeout on it now?
18:41:29  * jgiquit (Quit: jgi)
18:43:00  * jgijoined
19:00:01  * jenkins-monitorquit (Remote host closed the connection)
19:00:15  * jenkins-monitorjoined
19:26:26  * bnoordhuisquit (Ping timeout: 260 seconds)
19:33:37  * rvaggquit (Remote host closed the connection)
19:40:23  <orangemocha>re: debug builds, I also had done a prototype change to one of the test-commit jobs to support debug for any test run. But the job was wiped out during the latest security crisis, maybe it can still be restored? https://ci.nodejs.org/job/orangemocha-test-commit-linux/2/
19:40:35  <orangemocha>as seen here: https://github.com/nodejs/node/pull/3293#issuecomment-147736624
19:41:46  <orangemocha>jbergstroem: probably superseded by what you have been doing, so just FYI, especially about Ben's PR
19:43:09  <jbergstroem>orangemocha: hm, what are you referring to?
19:45:22  <orangemocha>jbergstroem Ben's PR enables to run ci in debug mode by just setting BUILDTYPE=Debug
19:45:34  * bnoordhuisjoined
19:45:59  <orangemocha>in orangemocha-test-commit-linux I had added an argument to my own copy of node-test-commit-linux, to enable debug builds
19:46:03  <jbergstroem>orangemocha: i thought that landed a good while ago? (my client might be messing with playback, sorry)
19:46:14  <orangemocha>and the same could be applied to all the node-test-commit* jobs
19:46:40  <jbergstroem>orangemocha: i'd prefer if we could wrap it in a check for nodes that has a debug label
19:47:04  <orangemocha>mmm, the PR is still open. bnoordhuis: did it land?
19:47:15  <orangemocha>https://github.com/nodejs/node/pull/3293
19:47:43  <jbergstroem>oh, i thought it landed
19:48:50  <orangemocha>there shouldn't be any downside in making the job parametric. Then node-test-commit can call two instances of say node-test-commit linux, one in debug, one in release if we decide to run a debug test for each commit
19:49:09  <orangemocha>anyway, just wanted to make sure you knew about that PR, because you'll probably need it to enable debug runs
19:49:17  <jbergstroem>orangemocha: the reason i'd like to check for labels is because the required amount of ram to compile is over 2G
19:49:28  <jbergstroem>orangemocha: i did a slightly hackier invocation, have a look at my job
19:49:37  <orangemocha>I see
19:50:20  <orangemocha>add to wish list: being able to pass the nodes to run as an argument. So that we don't have to define each job just so we can define a set of nodes to run. In fact, this shouldn't be too complicated with Jenkins.
19:52:57  <joaocgreis>orangemocha: it's easy to select specific machines, there's a parameter type for it. It's quite hard on the other hand to select a group of specific labels, the best I came up with is in stress-single-test
19:54:06  <joaocgreis>I tried to pass a string with a list of labels, but the groovy functions you can use in combination filter is very limited and I did not find a way to split the list
19:54:28  <orangemocha>maybe with this plugin? https://wiki.jenkins-ci.org/display/JENKINS/DynamicAxis+Plugin
20:00:01  * jenkins-monitorquit (Remote host closed the connection)
20:00:15  * jenkins-monitorjoined
20:02:26  * benglquit (Ping timeout: 240 seconds)
20:02:39  <joaocgreis>looks like it could work.. I'll have to try
20:04:20  <bnoordhuis>i need to dust off #3293... maybe friday
20:10:08  * rvaggjoined
20:14:47  * bengljoined
20:47:10  * jgiquit (Quit: jgi)
21:00:02  * jenkins-monitorquit (Remote host closed the connection)
21:00:08  * jenkins-monitorjoined
21:45:07  <rvagg>+ to "azure-msft" if that works in the naming scheme jbergstroem
21:45:35  <jbergstroem>if we're doing provider/sponsor it'd be msft_azure
21:45:44  <jbergstroem>or the other way around?
21:46:00  <rvagg>joaocgreis: noted, will try and resist updating anything .. people complain about the pain of shifting dependencies in the node ecosystem but the jenkins plugin breakage is so much worse than anything that happens in node-land
21:46:01  <jbergstroem>the rpi would be somehting like nodesource_jbergstroem
21:46:20  <rvagg>jbergstroem: azure is technically a separate company owned by microsoft so it could be either way really
21:47:00  <rvagg>from a marketing standpoint they really want to highlight azure, and that's where we're pulling most of the build resources (aside from orangemocha & joaocgreis' time) so I'd highlight that first
21:47:02  <rvagg>azure_msft
21:48:40  <jbergstroem>ok
21:58:34  <orangemocha>azure is not really a separate company, it's a cloud service owned by Microsoft
21:58:46  <orangemocha>in this case, it's the hosting provider
21:58:52  <orangemocha>and msft is the sponsor
21:58:58  * jgijoined
21:59:14  <orangemocha>you could theoretically imagine msft sponsoring resources on digital ocean, or on rackspace
21:59:22  <orangemocha>or the foundation sponsoring resources to run on azure
22:00:02  * jenkins-monitorquit (Remote host closed the connection)
22:00:18  * jenkins-monitorjoined
22:02:10  <orangemocha>if we are doing provider_sponsor, it should be azure_msft
22:02:31  <orangemocha>re: upgrading jenkins, yes we should refrain as much as possible
22:03:03  <orangemocha>I think the fact that upgrades can be so disruptive is a good argument for having another master where we can stage changes
22:04:03  <orangemocha>.. which is in general an obvious guideline for running a highly available service... you don't upgrade your production environment before testing it in a separate environment
22:04:58  <jbergstroem>fwiw, ibm is using both osuosl and softlayer
22:05:22  <orangemocha>I am assuming that the ssh approach for connecting master to slave would facilitate having multiple masters. Though it's possible that there are other ways of doing that. I intend to do some research on existing best practices
22:09:13  <jbergstroem>isn't it great how cisco stuff requires console (rj45) access for initial setup? :'(
22:13:29  <orangemocha>btw there is a jenkins LTS release line. We should probably stick to that: https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line
22:15:30  <jbergstroem>do we dare downgrading?
22:16:53  <orangemocha>at this point I'd stick with what we have. And work on a staging master setup so we can then re-introduce freedom to experiment
22:35:09  * jgiquit (Quit: jgi)
22:36:54  * jgijoined
23:00:01  * jenkins-monitorquit (Remote host closed the connection)
23:00:15  * jenkins-monitorjoined