00:38 < rcurtin> Marcus presenting mlpack at the MLOSS 2018 workshop at NeurIPS:

00:38 < rcurtin> https://twitter.com/DanielPressel/status/1071427961344147457

00:38 < rcurtin> :)

00:41 < zoq> yeah that's me :)

01:01 < robertohueso> Happy to see mlpack at NeurIPS :D

13:10 < jenkins-mlpack2> Project docker mlpack nightly build build #148: STILL UNSTABLE in 7 hr 56 min: http://ci.mlpack.org/job/docker%20mlpack%20nightly%20build/148/

16:15 < jenkins-mlpack2> Project mlpack - git commit test build #63: UNSTABLE in 33 min: http://ci.mlpack.org/job/mlpack%20-%20git%20commit%20test/63/

16:15 < jenkins-mlpack2> noreply: Merge pull request #1570 from zoq/ens_transition

17:41 < ShikharJ_> rcurtin: Do the merge commit builds need to run their length as well?

17:53 < rcurtin> ShikharJ_: what do you mean? I don't think I understand

18:00 < ShikharJ_> Basically when you merge a PR, the Travis and AppVeyor builds get initiated. Are they required to run their course as well, or we can cancel them to our wish?

18:01 < rcurtin> I guess we could cancel them, but I don't know why we would want to

18:01 < rcurtin> maybe I am overlooking why we would want to do that? I don't have a strong opinion, I just don't fully understand I think :)

18:02 < ShikharJ_> Guess I see them as a waste of CI resources, a past GSoC mentor I was under was very particular about running CI builds even though they were free.

18:03 < ShikharJ_> I got this habit from him maybe.

18:04 < rcurtin> I guess so; if we can find some way to be sure that the build is still successful then I don't see the need for the extra build

18:05 < rcurtin> but really the big 'waste' to focus on would be the nightly and weekly and monthly matrix builds

18:05 < rcurtin> but I feel like those are needed to catch rare random test failures

18:05 < rcurtin> (actually I am working with some of those now...)

18:06 < rcurtin> if you have ideas for how to make things more efficient while still having the same level of guarantee code is working I am all for it :)

18:08 < ShikharJ_> I agree, different communities have different needs. It's just that Appveyor takes almost a couple of hours per build, it seems wasteful to build the merge commits there, since we can anyways run the nightly build (or make it bi-nightly).

18:12 < ShikharJ_> Working on a Sunday?

18:15 < ShikharJ_> I'm also seeing a 10% decrease in build time on Appveyor after zoq's ensmallen work got merged, a nice speedup indeed.

18:15 < rcurtin> ShikharJ_: yeah, I am at the airport coming home from NeurIPS

18:15 < rcurtin> I showed up early to try and catch and earlier flight but it did not work

18:16 < rcurtin> so I figured I woild write some code :)

18:16 < rcurtin> I actually find the AppVeyor builds useful for Windows, but I notice sometimes the queue gets really long sonce AppVeyor tries to build every commit

18:16 < rcurtin> so if I push a commit, then another one, then another one, three builds get queued not just one

18:17 < rcurtin> so that is pretty inefficient, since only the last one matters

22:27 < zoq> hm, I think there is some option to autocancel the build

22:56 < rcurtin> I set 'auto-cancel branch builds' for travis as well (it was already enabled for PRs)

22:56 < rcurtin> I'm looking for the option for appveyor also

23:01 < rcurtin> I see that we need to enable the 'rolling builds' option in the appveyor "settings UI" for the mlpack project

23:01 < rcurtin> but I don't see any option to get into it. maybe my AppVeyor account doesn't have permission to do that?

23:01 < rcurtin> zoq: if you have a second, maybe can you log in and see if you can do it?

23:17 < zoq> enabled

23:18 < zoq> everyone one from mlpack should be able to set options, if they use the github login

23:25 < zoq> I manually updates both of your user settings

23:27 < zoq> *updated

23:45 < rcurtin> ah, ok, thanks!