Re: Remove MKLML as dependency
Will test it out tomorrow. On the side, what is the best way to test MKL build for MXnet. MKL is licensed? Best, Alex On 9/18/18, 7:50 PM, "Lv, Tao A" wrote: Hi Alex, Thanks for bringing this up. The original intention of MKLML is to provide a light and easy-to-access library for ML/DL community. It's released with MKL-DNN under Apache-2.0 license. AFAIK, MKL-DNN still relies on it for better performance. So I'm afraid there will be a performance regression in MKL pip packages if MKLML is simply removed. Have you ever tried the build without MKLML and how does the performance look like? -tao -Original Message- From: Alex Zai [mailto:aza...@gmail.com] Sent: Wednesday, September 19, 2018 4:49 AM To: dev@mxnet.incubator.apache.org Subject: Remove MKLML as dependency On our build from source page we have a list of blas libraries that are recommended: https://mxnet.incubator.apache.org/install/build_from_source.html MKL-DNN MKL MKLML Apple Accelerate OpenBlas MKLML is a subset of MKL (https://github.com/intel/mkl-dnn/issues/102) and therefore MKLML users can just use MKL instead. Does anyone see an issue with me removing this? It would simplify out doc page and build file. Alex
Re: multiple installation guides?
Amol, do you want to post this on discuss.mxnet.io ? > On Sep 19, 2018, at 4:34 AM, Hagay Lupesko wrote: > > The /test site seems to be something old that should have been removed a > long time ago, it lists versions 0.10 and 0.10.14 :) > Maybe Aaron has an idea what needs to be done to remove it... > >> On Fri, Sep 14, 2018 at 4:55 PM Alex Zai wrote: >> >> Why do we have two sets of installation guides? >> >> http://mxnet.incubator.apache.org/test/get_started/install.html >> >> https://mxnet.incubator.apache.org/install/index.html?platform=Linux=Python=CPU >> >> The /test domain is also not secure. If this is not suppose to be >> public we should remove this as it is confusing. >>
Re: multiple installation guides?
The /test site seems to be something old that should have been removed a long time ago, it lists versions 0.10 and 0.10.14 :) Maybe Aaron has an idea what needs to be done to remove it... On Fri, Sep 14, 2018 at 4:55 PM Alex Zai wrote: > Why do we have two sets of installation guides? > > http://mxnet.incubator.apache.org/test/get_started/install.html > > https://mxnet.incubator.apache.org/install/index.html?platform=Linux=Python=CPU > > The /test domain is also not secure. If this is not suppose to be > public we should remove this as it is confusing. >
Re: Questions regarding C Predict and C++ API provided by MxNet.
Amol, I can try and provide my 2 cents on some of these questions: - "What are the typical uses cases in which C++ (cpp-package) or C (C Predict) APIs are used? For example: inference, training or both." Note that the C API supports inference only. >From my experience as an Amazon Web Services employee, teams/customers who used the C API used it mainly for inference. Python is much more convenient and suitable for rapid experimentation that is important for building and training models. - "Currently, users are required to build these APIs from source. Would it be helpful if these APIs are available as standalone packages distributed via package managers (example: apt-get)?" I think it will reduce friction significantly if MXNet offers pre-build binaries. MXNet build takes a while to build and to figure out, there's quite a few build flag options, which may be intimidating for users, especially new users. Package managers will be great, but even just binary libraries available on a shared location (e.g. S3) would be super useful. HTH, Hagay On Mon, Sep 17, 2018 at 3:23 PM Amol Lele wrote: > Hello everybody, > > > > As contributor to Apache MXNet project I would like to ask community a > couple of questions in regards to C Predict and C++ APIs that MXNet > provides to its users. My main goal is to better understand the pain points > community members currently see/have with those APIs as well as to what > contributions to C++ and C Predict APIs would be most beneficial to users > who are using/tried to use these APIs of Apache MXNet. > > 1. What are the typical uses cases in which C++ (cpp-package) or C (C > Predict) APIs are used? For example: inference, training or both. > > 2. Which set of APIs out of C++ and C do users prefer? Preferably > with reasons why. > > 3. What are the frequently used platforms (Linux, Mac, Windows, etc) > and configurations (such as CPU, GPU, etc) on which these APIs are used? > > 4. Currently, users are required to build these APIs from source. > Would it be helpful if these APIs are available as standalone packages > distributed via package managers (example: apt-get)? > > I would highly appreciate your replies to any or all of the above > questions. > > > > Thanks, > > -Amol >
Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).
Bravo indeed! Awesome work Kellen and Marco! On Tue, Sep 18, 2018 at 7:56 PM Lin Yuan wrote: > Bravo! This is a very important piece in CI. Thanks Kellen and Marco to > implement it quickly. > > > Lin > > On Tue, Sep 18, 2018, 4:18 PM Marco de Abreu > wrote: > > > Kellen has fixed the one bug in our build system and thus, there are no > > outstanding tests :) > > > > Exactly, it will run on branch and PR validation. > > > > Best regards, > > Marco > > > > sandeep krishnamurthy schrieb am Di., 18. > > Sep. 2018, 19:32: > > > > > This is awesome. Thanks a lot Kellen and Marco. With this work > complete, > > we > > > will have MXNet Python tests running for Mac on Travis CI, for PR and > > > Branch builds? > > > Thank you for working on fixing the tests and making it run as part of > > > Travis CI for Mac platform. Is there any Github issue or Jira where we > > can > > > see disabled / tests that needs to be fixed for Mac? This might be > useful > > > if we can call for contributions. > > > > > > Best, > > > Sandeep > > > > > > > > > On Tue, Sep 18, 2018 at 9:51 AM Marco de Abreu > > > wrote: > > > > > > > Hey everyone, > > > > > > > > we are about to enable Python tests for Mac. The outstanding bugs > have > > > been > > > > fixed by Kellen and we're just waiting for the PRs to pass. We'll > send > > a > > > > separate email as soon as they are enabled. > > > > > > > > Additionally, we had a small problem that Travis runs got aborted if > > > > multiple commits were done in a short timeframe. While this is > > acceptable > > > > for PRs, this causes our branch jobs to also fail. An examples is > > > available > > > > at [1]. In order to cope with this, I have asked Apache Infra to > > disable > > > > cancellation of concurrent jobs. They agreed to this, but reminded us > > > that > > > > they might turn it back on if we consume too many resources. > > > > > > > > The dashboard to review the Travis resource utilization is available > at > > > > [2]. Just log in as Guest. > > > > > > > > Best regards, > > > > Marco > > > > > > > > [1]: > > > > > > > > > > > > > > https://travis-ci.org/apache/incubator-mxnet/builds/430135867?utm_source=github_status_medium=notification > > > > [2]: > > > > > > > > > > > > > > https://demo.kibble.apache.org/dashboard.html?page=ci=e0ce4eee89a77ec231eee1fdbbc647cb3de2f6ecfc3cef8d8c11dc2d=hour > > > > > > > > > > > > On Thu, Sep 13, 2018 at 1:06 AM kellen sunderland < > > > > kellen.sunderl...@gmail.com> wrote: > > > > > > > > > We've got fairly limited ability to change what's reported by > Travis. > > > > Most > > > > > administration is done by the ASF Infra crew, so it's tough for us > to > > > > > experiment with settings. It'd be great if you could bear with us > > for > > > a > > > > > few days. It shouldn't take too long to either (1) get > happy-feeling > > > > green > > > > > checks back, or (2) decide we don't care as much as we thought we > did > > > > about > > > > > MacOS support. > > > > > > > > > > On Wed, Sep 12, 2018 at 9:53 PM Aaron Markham < > > > aaron.s.mark...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > Is there any way to make it not show a red X failure in the > GitHub > > UI > > > > > when > > > > > > TravisCI fails? I keep going back to check what flakey test > failed > > > this > > > > > > time and realizing that Jenkins is still running and it was the > > "not > > > > > > required" Travis fail. The green checkmark makes me happy and > it's > > > > easier > > > > > > to keep an eye on what's going on. If Travis times out a lot of > the > > > > time, > > > > > > then most of our PRs will look red/bad/sad when they're not. > > > > > > > > > > > > What about no failure flag set, but add a label that Travis > > > failed > > > > or > > > > > > if we can't control the flag, auto-set labels for each Travis and > > > > Jenkins > > > > > > pass/fail so we still get the benefit of at-a-glance status > checks. > > > > > > > > > > > > On Wed, Sep 12, 2018 at 6:04 AM Marco de Abreu > > > > > > wrote: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > Travis CI has successfully been enabled just now. This means > you > > > will > > > > > now > > > > > > > see a new status under your PR which is called > > > > > > > "continuous-integration/travis-ci/pr". > > > > > > > > > > > > > > The job only compiles MXNet on Mac and currently does not run > > unit > > > > > tests > > > > > > - > > > > > > > we expect the overall execution duration to be around 6 minutes > > and > > > > > thus > > > > > > > faster than the full Jenkins pipeline. The status is set to > "not > > > > > > required" > > > > > > > which means that it does not block merging if that job fails > > since > > > > the > > > > > > > pipeline is still in beta. But in general, it would be good if > > > > > committers > > > > > > > review the results in case the job shows a failure. Our last > > known > > > > > state > > > > > > is > > > > > > > that the pipeline works
Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).
Bravo! This is a very important piece in CI. Thanks Kellen and Marco to implement it quickly. Lin On Tue, Sep 18, 2018, 4:18 PM Marco de Abreu wrote: > Kellen has fixed the one bug in our build system and thus, there are no > outstanding tests :) > > Exactly, it will run on branch and PR validation. > > Best regards, > Marco > > sandeep krishnamurthy schrieb am Di., 18. > Sep. 2018, 19:32: > > > This is awesome. Thanks a lot Kellen and Marco. With this work complete, > we > > will have MXNet Python tests running for Mac on Travis CI, for PR and > > Branch builds? > > Thank you for working on fixing the tests and making it run as part of > > Travis CI for Mac platform. Is there any Github issue or Jira where we > can > > see disabled / tests that needs to be fixed for Mac? This might be useful > > if we can call for contributions. > > > > Best, > > Sandeep > > > > > > On Tue, Sep 18, 2018 at 9:51 AM Marco de Abreu > > wrote: > > > > > Hey everyone, > > > > > > we are about to enable Python tests for Mac. The outstanding bugs have > > been > > > fixed by Kellen and we're just waiting for the PRs to pass. We'll send > a > > > separate email as soon as they are enabled. > > > > > > Additionally, we had a small problem that Travis runs got aborted if > > > multiple commits were done in a short timeframe. While this is > acceptable > > > for PRs, this causes our branch jobs to also fail. An examples is > > available > > > at [1]. In order to cope with this, I have asked Apache Infra to > disable > > > cancellation of concurrent jobs. They agreed to this, but reminded us > > that > > > they might turn it back on if we consume too many resources. > > > > > > The dashboard to review the Travis resource utilization is available at > > > [2]. Just log in as Guest. > > > > > > Best regards, > > > Marco > > > > > > [1]: > > > > > > > > > https://travis-ci.org/apache/incubator-mxnet/builds/430135867?utm_source=github_status_medium=notification > > > [2]: > > > > > > > > > https://demo.kibble.apache.org/dashboard.html?page=ci=e0ce4eee89a77ec231eee1fdbbc647cb3de2f6ecfc3cef8d8c11dc2d=hour > > > > > > > > > On Thu, Sep 13, 2018 at 1:06 AM kellen sunderland < > > > kellen.sunderl...@gmail.com> wrote: > > > > > > > We've got fairly limited ability to change what's reported by Travis. > > > Most > > > > administration is done by the ASF Infra crew, so it's tough for us to > > > > experiment with settings. It'd be great if you could bear with us > for > > a > > > > few days. It shouldn't take too long to either (1) get happy-feeling > > > green > > > > checks back, or (2) decide we don't care as much as we thought we did > > > about > > > > MacOS support. > > > > > > > > On Wed, Sep 12, 2018 at 9:53 PM Aaron Markham < > > aaron.s.mark...@gmail.com > > > > > > > > wrote: > > > > > > > > > Is there any way to make it not show a red X failure in the GitHub > UI > > > > when > > > > > TravisCI fails? I keep going back to check what flakey test failed > > this > > > > > time and realizing that Jenkins is still running and it was the > "not > > > > > required" Travis fail. The green checkmark makes me happy and it's > > > easier > > > > > to keep an eye on what's going on. If Travis times out a lot of the > > > time, > > > > > then most of our PRs will look red/bad/sad when they're not. > > > > > > > > > > What about no failure flag set, but add a label that Travis > > failed > > > or > > > > > if we can't control the flag, auto-set labels for each Travis and > > > Jenkins > > > > > pass/fail so we still get the benefit of at-a-glance status checks. > > > > > > > > > > On Wed, Sep 12, 2018 at 6:04 AM Marco de Abreu > > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > Travis CI has successfully been enabled just now. This means you > > will > > > > now > > > > > > see a new status under your PR which is called > > > > > > "continuous-integration/travis-ci/pr". > > > > > > > > > > > > The job only compiles MXNet on Mac and currently does not run > unit > > > > tests > > > > > - > > > > > > we expect the overall execution duration to be around 6 minutes > and > > > > thus > > > > > > faster than the full Jenkins pipeline. The status is set to "not > > > > > required" > > > > > > which means that it does not block merging if that job fails > since > > > the > > > > > > pipeline is still in beta. But in general, it would be good if > > > > committers > > > > > > review the results in case the job shows a failure. Our last > known > > > > state > > > > > is > > > > > > that the pipeline works properly, but we will keep everybody up > to > > > date > > > > > in > > > > > > case we get aware of any problems. > > > > > > > > > > > > The next step will be integration of Python CPU unit tests. There > > > will > > > > > be a > > > > > > separate email if we got an update on that manner. > > > > > > > > > > > > Special thanks to Kellen Sunderland for the contribution of this > > > Travis > > > > > CI > > > > > >
RE: Remove MKLML as dependency
Hi Alex, Thanks for bringing this up. The original intention of MKLML is to provide a light and easy-to-access library for ML/DL community. It's released with MKL-DNN under Apache-2.0 license. AFAIK, MKL-DNN still relies on it for better performance. So I'm afraid there will be a performance regression in MKL pip packages if MKLML is simply removed. Have you ever tried the build without MKLML and how does the performance look like? -tao -Original Message- From: Alex Zai [mailto:aza...@gmail.com] Sent: Wednesday, September 19, 2018 4:49 AM To: dev@mxnet.incubator.apache.org Subject: Remove MKLML as dependency On our build from source page we have a list of blas libraries that are recommended: https://mxnet.incubator.apache.org/install/build_from_source.html MKL-DNN MKL MKLML Apple Accelerate OpenBlas MKLML is a subset of MKL (https://github.com/intel/mkl-dnn/issues/102) and therefore MKLML users can just use MKL instead. Does anyone see an issue with me removing this? It would simplify out doc page and build file. Alex
improving API docs and tutorials user experience
Hello dev list! I've been doing a bit with .htaccess redirects on the site to get us things like custom 404s and redirecting google searches that come in on outdated material. That's working pretty well because the redirects are simple. I need help though. I've written a short proposal on how I think the UX for API docs and tutorials should work. I'm not trying a major jump here. This is a small amount of change for a better experience. For example, right now, if you're browsing API docs for 1.3.0 and want to see the master version, you would hit the dropdown and select master. Then you get taken to the home page for master and have to go find the document again. (It's always done this.) It should stay on that document, but give the latest version. Or for tutorials, if you request a really old, likely broken tutorial because it happens to show up in google search results, the site should kindly escort you to the latest, tested tutorial. mod_rewrite and .htaccess can do this, but it requires regex skills that I lack. I've tried hundreds of variations now, and would like some guidance. Here's the proposal and my notes: https://cwiki.apache.org/confluence/display/MXNET/Version+calls+and+redirects+for+Tutorials+and+API+documents I appreciate your help with this! Cheers, Aaron
Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).
Kellen has fixed the one bug in our build system and thus, there are no outstanding tests :) Exactly, it will run on branch and PR validation. Best regards, Marco sandeep krishnamurthy schrieb am Di., 18. Sep. 2018, 19:32: > This is awesome. Thanks a lot Kellen and Marco. With this work complete, we > will have MXNet Python tests running for Mac on Travis CI, for PR and > Branch builds? > Thank you for working on fixing the tests and making it run as part of > Travis CI for Mac platform. Is there any Github issue or Jira where we can > see disabled / tests that needs to be fixed for Mac? This might be useful > if we can call for contributions. > > Best, > Sandeep > > > On Tue, Sep 18, 2018 at 9:51 AM Marco de Abreu > wrote: > > > Hey everyone, > > > > we are about to enable Python tests for Mac. The outstanding bugs have > been > > fixed by Kellen and we're just waiting for the PRs to pass. We'll send a > > separate email as soon as they are enabled. > > > > Additionally, we had a small problem that Travis runs got aborted if > > multiple commits were done in a short timeframe. While this is acceptable > > for PRs, this causes our branch jobs to also fail. An examples is > available > > at [1]. In order to cope with this, I have asked Apache Infra to disable > > cancellation of concurrent jobs. They agreed to this, but reminded us > that > > they might turn it back on if we consume too many resources. > > > > The dashboard to review the Travis resource utilization is available at > > [2]. Just log in as Guest. > > > > Best regards, > > Marco > > > > [1]: > > > > > https://travis-ci.org/apache/incubator-mxnet/builds/430135867?utm_source=github_status_medium=notification > > [2]: > > > > > https://demo.kibble.apache.org/dashboard.html?page=ci=e0ce4eee89a77ec231eee1fdbbc647cb3de2f6ecfc3cef8d8c11dc2d=hour > > > > > > On Thu, Sep 13, 2018 at 1:06 AM kellen sunderland < > > kellen.sunderl...@gmail.com> wrote: > > > > > We've got fairly limited ability to change what's reported by Travis. > > Most > > > administration is done by the ASF Infra crew, so it's tough for us to > > > experiment with settings. It'd be great if you could bear with us for > a > > > few days. It shouldn't take too long to either (1) get happy-feeling > > green > > > checks back, or (2) decide we don't care as much as we thought we did > > about > > > MacOS support. > > > > > > On Wed, Sep 12, 2018 at 9:53 PM Aaron Markham < > aaron.s.mark...@gmail.com > > > > > > wrote: > > > > > > > Is there any way to make it not show a red X failure in the GitHub UI > > > when > > > > TravisCI fails? I keep going back to check what flakey test failed > this > > > > time and realizing that Jenkins is still running and it was the "not > > > > required" Travis fail. The green checkmark makes me happy and it's > > easier > > > > to keep an eye on what's going on. If Travis times out a lot of the > > time, > > > > then most of our PRs will look red/bad/sad when they're not. > > > > > > > > What about no failure flag set, but add a label that Travis > failed > > or > > > > if we can't control the flag, auto-set labels for each Travis and > > Jenkins > > > > pass/fail so we still get the benefit of at-a-glance status checks. > > > > > > > > On Wed, Sep 12, 2018 at 6:04 AM Marco de Abreu > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > Travis CI has successfully been enabled just now. This means you > will > > > now > > > > > see a new status under your PR which is called > > > > > "continuous-integration/travis-ci/pr". > > > > > > > > > > The job only compiles MXNet on Mac and currently does not run unit > > > tests > > > > - > > > > > we expect the overall execution duration to be around 6 minutes and > > > thus > > > > > faster than the full Jenkins pipeline. The status is set to "not > > > > required" > > > > > which means that it does not block merging if that job fails since > > the > > > > > pipeline is still in beta. But in general, it would be good if > > > committers > > > > > review the results in case the job shows a failure. Our last known > > > state > > > > is > > > > > that the pipeline works properly, but we will keep everybody up to > > date > > > > in > > > > > case we get aware of any problems. > > > > > > > > > > The next step will be integration of Python CPU unit tests. There > > will > > > > be a > > > > > separate email if we got an update on that manner. > > > > > > > > > > Special thanks to Kellen Sunderland for the contribution of this > > Travis > > > > CI > > > > > pipeline. > > > > > > > > > > Best regards, > > > > > Marco > > > > > > > > > > On Wed, Sep 5, 2018 at 8:19 PM Tianqi Chen < > tqc...@cs.washington.edu > > > > > > > > wrote: > > > > > > > > > > > Alrite, then I think it is fine as long as we can kept up with > > build > > > > > speed > > > > > > without timeout. > > > > > > > > > > > > > > > > > > Tianqi > > > > > > > > > > > > On Wed, Sep 5, 2018 at 9:14 AM kellen sunderland < > > > > > >
Remove MKLML as dependency
On our build from source page we have a list of blas libraries that are recommended: https://mxnet.incubator.apache.org/install/build_from_source.html MKL-DNN MKL MKLML Apple Accelerate OpenBlas MKLML is a subset of MKL (https://github.com/intel/mkl-dnn/issues/102) and therefore MKLML users can just use MKL instead. Does anyone see an issue with me removing this? It would simplify out doc page and build file. Alex
Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).
Hey everyone, we are about to enable Python tests for Mac. The outstanding bugs have been fixed by Kellen and we're just waiting for the PRs to pass. We'll send a separate email as soon as they are enabled. Additionally, we had a small problem that Travis runs got aborted if multiple commits were done in a short timeframe. While this is acceptable for PRs, this causes our branch jobs to also fail. An examples is available at [1]. In order to cope with this, I have asked Apache Infra to disable cancellation of concurrent jobs. They agreed to this, but reminded us that they might turn it back on if we consume too many resources. The dashboard to review the Travis resource utilization is available at [2]. Just log in as Guest. Best regards, Marco [1]: https://travis-ci.org/apache/incubator-mxnet/builds/430135867?utm_source=github_status_medium=notification [2]: https://demo.kibble.apache.org/dashboard.html?page=ci=e0ce4eee89a77ec231eee1fdbbc647cb3de2f6ecfc3cef8d8c11dc2d=hour On Thu, Sep 13, 2018 at 1:06 AM kellen sunderland < kellen.sunderl...@gmail.com> wrote: > We've got fairly limited ability to change what's reported by Travis. Most > administration is done by the ASF Infra crew, so it's tough for us to > experiment with settings. It'd be great if you could bear with us for a > few days. It shouldn't take too long to either (1) get happy-feeling green > checks back, or (2) decide we don't care as much as we thought we did about > MacOS support. > > On Wed, Sep 12, 2018 at 9:53 PM Aaron Markham > wrote: > > > Is there any way to make it not show a red X failure in the GitHub UI > when > > TravisCI fails? I keep going back to check what flakey test failed this > > time and realizing that Jenkins is still running and it was the "not > > required" Travis fail. The green checkmark makes me happy and it's easier > > to keep an eye on what's going on. If Travis times out a lot of the time, > > then most of our PRs will look red/bad/sad when they're not. > > > > What about no failure flag set, but add a label that Travis failed or > > if we can't control the flag, auto-set labels for each Travis and Jenkins > > pass/fail so we still get the benefit of at-a-glance status checks. > > > > On Wed, Sep 12, 2018 at 6:04 AM Marco de Abreu > > wrote: > > > > > Hello, > > > > > > Travis CI has successfully been enabled just now. This means you will > now > > > see a new status under your PR which is called > > > "continuous-integration/travis-ci/pr". > > > > > > The job only compiles MXNet on Mac and currently does not run unit > tests > > - > > > we expect the overall execution duration to be around 6 minutes and > thus > > > faster than the full Jenkins pipeline. The status is set to "not > > required" > > > which means that it does not block merging if that job fails since the > > > pipeline is still in beta. But in general, it would be good if > committers > > > review the results in case the job shows a failure. Our last known > state > > is > > > that the pipeline works properly, but we will keep everybody up to date > > in > > > case we get aware of any problems. > > > > > > The next step will be integration of Python CPU unit tests. There will > > be a > > > separate email if we got an update on that manner. > > > > > > Special thanks to Kellen Sunderland for the contribution of this Travis > > CI > > > pipeline. > > > > > > Best regards, > > > Marco > > > > > > On Wed, Sep 5, 2018 at 8:19 PM Tianqi Chen > > > wrote: > > > > > > > Alrite, then I think it is fine as long as we can kept up with build > > > speed > > > > without timeout. > > > > > > > > > > > > Tianqi > > > > > > > > On Wed, Sep 5, 2018 at 9:14 AM kellen sunderland < > > > > kellen.sunderl...@gmail.com> wrote: > > > > > > > > > Travis actually has explicit support for ccache, it's a platform > > > feature. > > > > > I've run it and it seems to work quite well. See for example this > > > build: > > > > > > > > > https://travis-ci.org/KellenSunderland/incubator-mxnet/builds/424768656 > > > > > > > > > > On Wed, Sep 5, 2018 at 7:10 PM Tianqi Chen < > tqc...@cs.washington.edu > > > > > > > > wrote: > > > > > > > > > > > Travis it self is stateless, which means ccache is not likely > going > > > to > > > > > > work. As far as I understand, if jenkins master is in the public > > > > domain, > > > > > > you do not need to setup a vpn to the subset of the master. > > > > > > > > > > > > As for versions of MacOS, we are likely going to be fine with one > > > > > version, > > > > > > as usually the problems exhibits on mac are similar > > > > > > > > > > > > Tianqi > > > > > > On Wed, Sep 5, 2018 at 9:04 AM kellen sunderland < > > > > > > kellen.sunderl...@gmail.com> wrote: > > > > > > > > > > > > > @Tianqi: Yeah there's going to be a lot of trade-offs to using > > > > > Travis. I > > > > > > > hope we can get it running fast enough with ccache that it > won't > > > > > timeout > > > > > > > when running tests, but even that is
