Re: [VOTE] Release MXNet version 1.3.0.RC0

1. As a Apache MXNet community member, I raised the concern of broken functionality for the user. I explained and provided the data points on the issue, workaround and why I think it is important. If after all this, you think my vote is biased on my employer just because a user I quoted

Re: [VOTE] Release MXNet version 1.3.0.RC0

btw, there are no vetoes on package releases: VOTES ON PACKAGE RELEASES Votes on whether a package is ready to be released use majority approval -- i.e. at least three P

Re: [VOTE] Release MXNet version 1.3.0.RC0

"Releases may not be vetoed" http://www.apache.org/legal/release-policy.html#release-approval I haven't tested the release yet, I'll do so tomorrow. > On Sep 4, 2018, at 7:13 PM, Sheng Zha wrote: > > Thanks for sharing your opinions, Thomas. Your recognition and respect of > people's efforts on

Re: [VOTE] Release MXNet version 1.3.0.RC0

Thanks for sharing your opinions, Thomas. Your recognition and respect of people's efforts on preparing the release candidate are certainly appreciated. Now that the vote is set to fail thanks to the veto, there will be plenty of opportunities to include those bug fixes, including the one Zhi ment

Re: [VOTE] Release MXNet version 1.3.0.RC0

-0 (non-binding) If I may add some nuancing plus a personal data point as one of the users commenting in the bug report in question: - Performance vs. Basic functionality => I don't think high performance use-cases and basic functionality are two obviously opposed concepts and see no contradictio

Re: [VOTE] Release MXNet version 1.3.0.RC0

Sandeep, Thanks for explaining your veto. We have open bugs that impacted a lot more than just 3 customers, just by referring to the number of commenters on the issue [1]. You said that this is for "high performance use cases", which contradicts with Hagay's assement that this is "basic functiona

Re: [VOTE] Release MXNet version 1.3.0.RC0

Hi Hagay, You asked, "It can be fixed and included in the release alongside the rest of the release content, right?" Yes, it can, after it has appropriate approval and merged to master, and at the cost of restarting the vote. However, personally, I do not think there's enough justification for t

Re: [VOTE] Release MXNet version 1.3.0.RC0

My initial vote of “-0” was due to lack of info from a user who had said, he overcame this issue for FP16 model. However, suggested workaround [1] for the issue is not straight forward and generally usable for all users. Also, issue is not simple and isolated to be listed in the Release Notes as

Re: [VOTE] Release MXNet version 1.3.0.RC0

Hi Sheng, Addressing your questions: - "why this specific bug is more important than all the other known bugs, that this becomes a release blocker" I do not consider it to be more or less important than other fixes. It can be fixed and included in the release alongside the rest of the release con

Re: [LAZY VOTE] Consolidating developer guide in one place (cwiki preferred)

+1 On Tue, Sep 4, 2018 at 1:46 PM Aaron Markham wrote: > I'd like to call for a lazy vote on this before proceeding. Already had > some +1s but let's be sure. > > The vote is to move developer guide info to cwiki. User guides would remain > on the website. > > On Tue, Aug 21, 2018 at 12:53 PM sa

Re: [LAZY VOTE] Consolidating developer guide in one place (cwiki preferred)

I'd like to call for a lazy vote on this before proceeding. Already had some +1s but let's be sure. The vote is to move developer guide info to cwiki. User guides would remain on the website. On Tue, Aug 21, 2018 at 12:53 PM sandeep krishnamurthy < sandeep.krishn...@gmail.com> wrote: > +1 > Than

Re: [VOTE] Release MXNet version 1.3.0.RC0

Hi Hagay and Sandeep, Could you help us understand why this specific bug is more important than all the other known bugs, that this becomes a release blocker? Some facts to consider: - The bug exists since SymbolBlock was introduced a year ago and has survived at least three releases, so this is

Re: [VOTE] Release MXNet version 1.3.0.RC0

Sandeep mentions the issue of an error when user tries to load model params trained/saved as FP16. https://github.com/apache/incubator-mxnet/issues/11849 The fix was done by Sandeep: https://github.com/apache/incubator-mxnet/pull/12412 and is ready to be cherry picked into the release branch. This

Re: [VOTE] Release MXNet version 1.3.0.RC0

"- 0" I believe the bug #11849 , unable to import non-fp32 models into Gluon, fixed in this PR #12412 is important for the users. I would rather pick this fix in this release than plan a

Re: New Java Inference API

this proposal is missing many of the offline discussions that happened and subsequent changes. @andrewfayres: Please update the wiki(may be you forgot to publish the changes) On Tue, Sep 4, 2018 at 11:11 AM Qing Lan wrote: > Hi All, > > Here is an update for the Java Inference API design doc on

New Java Inference API

Hi All, Here is an update for the Java Inference API design doc on CWIKI: https://cwiki.apache.org/confluence/display/MXNET/MXNet+Java+Inference+API. Currently, MXNet Java bindings is an extension of MXNet Scala API that allow users to use Java to do inference on MXNet. Users will be able to im

Re: Propose to discontinue supporting Apache MXNet on Windows 7

I have contacted some friends in industry, they claim that some controller PCs are still on win7 and have no plan to upgrade in near future, so I would strongly go -1. In terms of build system on Windows 7, MS does give warnings in VS 2015, but with compatibility mode, we can still install it

Re: Propose to discontinue supporting Apache MXNet on Windows 7

One more data point: Mathematica still supports Windows 7 (with Platform Update), and we use MXNet as a backend for our neural net framework. So I would also vote against deprecating Windows 7 support. > On Sep 2, 2018, at 7:40 PM, Marco de Abreu > wrote: > > Thanks for the data and these qui