Re: Pylint Undefined variable/name error

Hi, that's a great idea. Unfortunately, we can't enable it in CI first unless all errors have been resolved. Otherwise, your PR is going to fail with the exact same errors and we won't be able to merge it. Best regards, Marco Vandana Kannan schrieb am Fr., 27. Juli 2018, 07:16: > Hi All, > > O

Re: Request to join developing PR Best practice guidelines

Hi Naveen, Thanks for your lead on the initiative of improving PRs! Just curious on the actual usage of the "PR best practices for authors", is it going to be a standard the community enforce on all PRs? That is, all PRs must follow those best practices before they could be merged. Or is it simply

Re: Release blocker: non-determinstic forward in gluon

Hi Tong - thanks for root causing the problem. Sheng - what is 1.2.1.post0? Shouldn't a patch with fix be released as 1.2.2? Steffen On Thu, Jul 26, 2018 at 5:33 PM Sheng Zha wrote: > Dear users and developers of Apache MXNet (Incubating), > > Thanks to Tong's dedication, the root cause for this

Re: Request to join developing PR Best practice guidelines

Hi Hao, It would be a standard(after agreed upon here) and expect reviewers to enforce it. purpose, from my earlier email- "improve PR response time, participation, and PR quality". Since we currently do have any standard or guidelines, currently developers are using their best judgement and in s

Re: Release blocker: non-determinstic forward in gluon

In this case we can regard it as a release problem, which is usually what post release versions are for. It’s still the same release with different dependency, so there is no code change needed. -sz > On Jul 27, 2018, at 8:31 AM, Steffen Rochel wrote: > > Hi Tong - thanks for root causing th

Re: Release blocker: non-determinstic forward in gluon

Forgot to mention, the post release version is a pip package version. -sz > On Jul 27, 2018, at 10:42 AM, Sheng Zha wrote: > > In this case we can regard it as a release problem, which is usually what > post release versions are for. It’s still the same release with different > dependency, so

Re: Release blocker: non-determinstic forward in gluon

Hi Sheng, I also opened an issue on OpenBLAS repo: https://github.com/xianyi/OpenBLAS/issues/1700 . As informed that "0.3.2 should be released this weekend", I tested their develope branch as well, and seems the new version has fixed the bug. Since OpenBLAS 0.3.2 could also have performance impr

Re: Release blocker: non-determinstic forward in gluon

Tong, That's great news. I'm glad that OpenBLAS people are responding so quickly. In that case it's probably a better idea to use that version instead. The latest OpenBLAS version brings many optimization for all kinds of hardware. -sz On Fri, Jul 27, 2018 at 11:10 AM, Tong He wrote: > Hi Shen

Re: Pylint Undefined variable/name error

On 2018/07/27 03:05:18, sandeep krishnamurthy wrote: > Thanks Vandana for picking up this issue. I think this is important to be > fixed and enabled in CI. Please let us know effort required to fix these > issues and we all can jump in and help you. > > On Thu, Jul 26, 2018, 7:27 PM Vandana

[DISCUSS] improve MXNet Scala release process

Hi all, Recently contributors on Scala Language development worked together and finally able to publish Scala package on Maven. Now I would like to raise a discussion to automate Scala release process and also discover a standard way to release different packages for MXNet so we won’t ask any i

Re: [DISCUSS] improve MXNet Scala release process

Qing, For 1, why would it be a blocker, given that there were previous releases? Has there been compatibility issues for scala packages? If so, why did we release? There are many maven packages that include binary already, so if we can find the binary for all dependency it's probably best to link

Re: [DISCUSS] improve MXNet Scala release process

I collaborate with Qing as a part of my day time job, to give you a little more perspective on the proposed work For 1) What we found is that users often run into conflicts when they use a different version of the dependency(CUDA, CUDNN, OpenBLAS, OpenCV, etc,.) and the one we build with MXNet bac

Re: [DISCUSS] improve MXNet Scala release process

Thanks, Naveen. Once we have clarity on 3), it should be no problem for scala to reuse the same solution. For 1), if this is indeed an issue, it seems that we may have rushed a bit on the scala releases. Are there any user reports? -sz On Fri, Jul 27, 2018 at 5:26 PM, Naveen Swamy wrote: > I co

Re: [DISCUSS] improve MXNet Scala release process

Hi all, about the credential management: We already have a solution based on restricted slaves [1] and AWS secrets manager [2] that is generally classified to generate binaries and handle credentials. It was designed with continuous deployment in mind, but we haven't tested it in that field yet.