Re: The operator check for Scala Package

Thanks Jun for your clarification. I think one of the advantages for MXNet is it's language binding. Although the number of customers using Scala is great less than Python, it is still one important language we need to support. About the first question, I would say we all in. At least all

Re: The operator check for Scala Package

We should reach an agreement on the responsibility/ownership before moving forward. 1. Who will take the ownership of fixing Scala build failure if an operator is changed/added in C++? 2. What is the expected turn around time of fixing the scala build failure. 3. What if we are short of resources

Re: The operator check for Scala Package

Hi All, Thank you all for your feedback. This changes do influence a lot on the PRs related to operator changes. I will take what Marco proposed to place that in the nightly build rather than every CI we runs. Thanks, Qing On 6/20/18, 8:40 PM, "Hao Jin" wrote: I don't think we should

Re: The operator check for Scala Package

I don't think we should keep this hash check thing. As Qing stated before on this thread, if there's any change in documentation the hash value is also changed and then flagged as a problem, how will that break any user's code? I would go for something like Marco's proposal: moving this to an

Re: The operator check for Scala Package

Agreed, for new APIs we can turn into a nightly job and report on dev@. The goal here is not to burden anyone but to catch changes on the backend before it propagates and break user's code and co-ordinate changes across language bindings which IMO is essential, so I would like to keep for changes

Re: [LAZY VOTE] Test coverage of PRs

we should have a betting pool on what the current coverage is. On Wed, Jun 20, 2018 at 7:54 PM Naveen Swamy wrote: > +1 to collect data on coverage. > > On Wed, Jun 20, 2018 at 7:38 PM, Marco de Abreu < > marco.g.ab...@googlemail.com.invalid> wrote: > > > Hello, > > > > for now, this is only a

Re: The operator check for Scala Package

I think we should go with an asychronous approach using a nightly job that detects the changes and reports them accordingly. We could then send out a report if there is a mismatch. I agree with the already stated points that we should not put the burden of adding frontend API bindings to somebody

Re: [LAZY VOTE] Test coverage of PRs

+1 to collect data on coverage. On Wed, Jun 20, 2018 at 7:38 PM, Marco de Abreu < marco.g.ab...@googlemail.com.invalid> wrote: > Hello, > > for now, this is only a test for myself and a way to gather data in order > to give us the possibility to make a data-driven decision. So far, we have > not

Re: The operator check for Scala Package

I understand the concerns here. However the problem here is that since the Scala APIs are generated using Macros and we do not(may not ever) have full test coverage on each of the APIs, we will not know for example if an operator/API changes on the backend and that propagates to Scala users, their

Re: The operator check for Scala Package

Hi Qing, What is the exact risk of changing / adding operators? could you provide an example? I also feel the way you proposed is little bit too heavy to developers, and not quite friendly to new contributors. On Wed, Jun 20, 2018 at 10:22 AM Haibin Lin wrote: > > I appreciate the effort and

Re: [LAZY VOTE] Test coverage of PRs

While I think test coverage is a nice information to have. I would object to using this as a metric to decide whether a PR should be merged. Code-cov act as a mere coverage of APIs, which is a useful aspect, it can be misleading in many cases, especially when such change involves cross-language

[LAZY VOTE] Test coverage of PRs

Hello, I'd like to introduce test coverage metrics of PRs using https://codecov.io/. This tool will aggregate coverage reports across multiple runs, platforms and technologies and gives contributors as well as reviewers a new tool that allows to improve the quality of a pull request. Since we

Re: users@mxnet

+1 On Wed, Jun 20, 2018 at 8:43 AM Steffen Rochel wrote: > I had a discussion yesterday with Jun Wu (wujun@gmail.com) to get a > better understanding about the concerns raised, that users might get > confused and maintenance efforts. > I agree with Jim that building and fostering the

Re: [VOTE] Release MXNet version 1.2.1.RC0 (Patch Release)

+1 On Mon, Jun 18, 2018, 6:52 PM Anirudh wrote: > Hi, > > This is the vote to release Apache MXNet (incubating) version 1.2.1. Voting > will start now and close Thursday June 21st 7:00 PM PDT. > > Link to release candidate 1.2.1.rc0: > >

Re: The operator check for Scala Package

I appreciate the effort and understand the motivation. However, I'm concerned that it basically means merging operator PRs becomes sequential. Developers who work on operators have to update their PR every time a new operator is merged to master, the burden becomes significant if there're 20

Re: The operator check for Scala Package

Hi Macro, Thanks for your feedback! I believe this should not be a block for contributor in most of the cases. Firstly, this would only be triggered if there is an operator changes (Only general operators). Secondly, it is simple to go through. Just need to change 1 line of code would make

Re: users@mxnet

I had a discussion yesterday with Jun Wu (wujun@gmail.com) to get a better understanding about the concerns raised, that users might get confused and maintenance efforts. I agree with Jim that building and fostering the community is important. First of all, I suggest we should be open minded