Podling Mxnet Report Reminder - January 2020

Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 15 January 2020, 10:30 am PDT. The report for your podling will

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

re the need for explicit type checking code in TVM FFI. Actually there is no explicit code for type checking as they are generated automatically via template expansion(on the receiving end), also we also have a "strong typed" signature that wraps the packed function interface, which gives you

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

Test On Fri, Dec 27, 2019 at 11:54 AM Pedro Larroy wrote: > Thanks for the explanation. I'm not so concerned about complexity of > dispatching. If I understood you correctly the main benefit that you > explain for the TVM project was not having to change the C API, but still > you need to do

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

Test On Fri, Dec 27, 2019 at 11:54 AM Pedro Larroy wrote: > Thanks for the explanation. I'm not so concerned about complexity of > dispatching. If I understood you correctly the main benefit that you > explain for the TVM project was not having to change the C API, but still > you need to do

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

Thanks for the explanation. I'm not so concerned about complexity of dispatching. If I understood you correctly the main benefit that you explain for the TVM project was not having to change the C API, but still you need to do type checking in both ends, or at least on the receiving end of the

Re: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc0

Agree with Sheng, I think it would be good to have the nice fixes that Leonard has done for 1.6 and not delay them to further releases since they are beneficial to users and developers. Thanks Leonard for helping fix these long standing issues. On Fri, Dec 27, 2019 at 11:03 AM Lin Yuan wrote: >

Re: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc0

No, I just wanted to call it out because the title of the issue says "Failed OpenMP assertion when loading MXNet compiled with DEBUG=1 ". If this is considered a release blocker, I think we should backport it to 1.6. Thanks, Lin On Fri,

Re: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc0

Reading these issues it’s pretty clear to me that these are fixes for broken builds. I think we do consider broken builds to be release blockers. Lin, am I missing something on which you base your suggestion for delaying these changes? -sz > On Dec 27, 2019, at 10:30 AM, Lin Yuan wrote: > >

Re: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc0

Are these release blocker? It's very risky to make such last-minute big change after code freeze. Can we do this in the next release? Lin On Fri, Dec 27, 2019 at 7:37 AM Lausen, Leonard wrote: > In case of backporting #17012, also > https://github.com/apache/incubator-mxnet/pull/17098 must be

Re: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc0

In case of backporting #17012, also https://github.com/apache/incubator-mxnet/pull/17098 must be backported. The updated OpenMP added a new target which is not used by MXNet but breaks the build on some systems with nvptx. #17098 disables building this unused and broken feature. On Thu,

Re: [apache/incubator-mxnet] [RFC] Apache MXNet 2.0 Roadmap (#16167)

+1 for using master branch for 2.0 development. I think we need 3 branches at least: 1. master branch: for 2.0 development 2. v1.x: for 1.x development and maintenance 3. v1.7.x: for 1.7.x release -- You are receiving this because you were mentioned. Reply to this email directly or view it on

Re: [apache/incubator-mxnet] [RFC] Apache MXNet 2.0 Roadmap (#16167)

In the past we always kept development on the master branch, thus how about branching out 1.7.0 release branch and keeping development on master? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: