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

2019-05-03 Thread Anirudh Subramanian
Hi Junru,

I am on v1.4.x , and my dmlc-core commit is this one :
https://github.com/dmlc/dmlc-core/tree/0a0e8addf92e1287fd7a25c6314016b8c0138dee

Anirudh

On Fri, May 3, 2019 at 8:30 PM Junru Shao  wrote:

> Hey Anirudh,
>
> Although the vote has been closed, I am very interested in digging into
> this issue.
>
> I build on my EC2 machine using your instructions, and it seems that
> everything is working fine...
>
> Then, I noticed that your issue seems to be related to unittests in
> dmlc-core, not in mxnet. Could you kindly check the submodule git hash?
> Also, could you check if you are testing on v1.4.x branch?
>
> Thanks,
> Junru
>
>
>
> On Fri, May 3, 2019 at 4:33 PM Anirudh Subramanian 
> wrote:
>
> > -1 (binding)
> >
> > Is the cmake build failing for the 1.4.1 release tag ? Is this a known
> > issue ?
> >
> > Did the following:
> >
> > cd build && cmake VERBOSE=1 -DUSE_CUDA=ON -DUSE_CUDNN=ON -DUSE_OPENMP=ON
> > -DCMAKE_BUILD_TYPE=Debug -DUSE_DIST_KVSTORE=0 -DUSE_OPENCV=1
> > -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda -DCUDNN_ROOT=/usr/local/cuda
> > -DUSE_MKLDNN=1 -DUSE_MKL_IF_AVAILABLE=1 -DUSE_MKLML_MKL=1 -DUSE_ASAN=0
> > -GNinja -DUSE_OPERATOR_TUNING=1 -DUSE_CPP_PACKAGE=0 -DCUDA_ARCH_NAME=Auto
> > .. && ninja -v
> >
> > [272/488] : && /usr/bin/c++   -Wall -Wno-unknown-pragmas -fPIC -g -O0
> > -msse2 -std=c++11 -fopenmp -g  -pthread
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_lockfree.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_param.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_parser.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_array_view.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_any.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_config.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_serializer.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer_exc_handling.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_inputsplit.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_json.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_optional.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_main.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_env.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_thread_group.cc.o
> > -o 3rdparty/dmlc-core/test/unittest/dmlc_unit_tests  -rdynamic
> > lib/libgtestd.a 3rdparty/dmlc-core/libdmlc.a -lpthread && :
> > FAILED: : && /usr/bin/c++   -Wall -Wno-unknown-pragmas -fPIC -g -O0
> -msse2
> > -std=c++11 -fopenmp -g  -pthread
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_lockfree.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_param.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_parser.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_array_view.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_any.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_config.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_serializer.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer_exc_handling.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_inputsplit.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_json.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_optional.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_main.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_env.cc.o
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_thread_group.cc.o
> > -o 3rdparty/dmlc-core/test/unittest/dmlc_unit_tests  -rdynamic
> > lib/libgtestd.a 3rdparty/dmlc-core/libdmlc.a -lpthread && :
> >
> >
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o:
> > In function `Logging_basics_Test::TestBody()':
> 

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

2019-05-03 Thread Junru Shao
Hey Anirudh,

Although the vote has been closed, I am very interested in digging into
this issue.

I build on my EC2 machine using your instructions, and it seems that
everything is working fine...

Then, I noticed that your issue seems to be related to unittests in
dmlc-core, not in mxnet. Could you kindly check the submodule git hash?
Also, could you check if you are testing on v1.4.x branch?

Thanks,
Junru



On Fri, May 3, 2019 at 4:33 PM Anirudh Subramanian 
wrote:

> -1 (binding)
>
> Is the cmake build failing for the 1.4.1 release tag ? Is this a known
> issue ?
>
> Did the following:
>
> cd build && cmake VERBOSE=1 -DUSE_CUDA=ON -DUSE_CUDNN=ON -DUSE_OPENMP=ON
> -DCMAKE_BUILD_TYPE=Debug -DUSE_DIST_KVSTORE=0 -DUSE_OPENCV=1
> -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda -DCUDNN_ROOT=/usr/local/cuda
> -DUSE_MKLDNN=1 -DUSE_MKL_IF_AVAILABLE=1 -DUSE_MKLML_MKL=1 -DUSE_ASAN=0
> -GNinja -DUSE_OPERATOR_TUNING=1 -DUSE_CPP_PACKAGE=0 -DCUDA_ARCH_NAME=Auto
> .. && ninja -v
>
> [272/488] : && /usr/bin/c++   -Wall -Wno-unknown-pragmas -fPIC -g -O0
> -msse2 -std=c++11 -fopenmp -g  -pthread
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_lockfree.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_param.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_parser.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_array_view.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_any.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_config.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_serializer.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer_exc_handling.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_inputsplit.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_json.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_optional.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_main.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_env.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_thread_group.cc.o
> -o 3rdparty/dmlc-core/test/unittest/dmlc_unit_tests  -rdynamic
> lib/libgtestd.a 3rdparty/dmlc-core/libdmlc.a -lpthread && :
> FAILED: : && /usr/bin/c++   -Wall -Wno-unknown-pragmas -fPIC -g -O0 -msse2
> -std=c++11 -fopenmp -g  -pthread
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_lockfree.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_param.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_parser.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_array_view.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_any.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_config.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_serializer.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer_exc_handling.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_inputsplit.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_json.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_optional.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_main.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_env.cc.o
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_thread_group.cc.o
> -o 3rdparty/dmlc-core/test/unittest/dmlc_unit_tests  -rdynamic
> lib/libgtestd.a 3rdparty/dmlc-core/libdmlc.a -lpthread && :
>
> 3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o:
> In function `Logging_basics_Test::TestBody()':
>
> /home/ubuntu/experimentals/master_mxnet/build/../3rdparty/dmlc-core/test/unittest/unittest_logging.cc:19:
> undefined reference to `testing::internal::DeathTest::Create(char const*,
> testing::internal::RE const*, char const*, int,
> testing::internal::DeathTest**)'
> collect2: error: ld returned 1 exit status
>
> Anirudh
>
> On Fri, May 3, 2019 at 8:04 AM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > No problem Damien, glad to have you helping us validating 

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

2019-05-03 Thread Anirudh Subramanian
-1 (binding)

Is the cmake build failing for the 1.4.1 release tag ? Is this a known
issue ?

Did the following:

cd build && cmake VERBOSE=1 -DUSE_CUDA=ON -DUSE_CUDNN=ON -DUSE_OPENMP=ON
-DCMAKE_BUILD_TYPE=Debug -DUSE_DIST_KVSTORE=0 -DUSE_OPENCV=1
-DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda -DCUDNN_ROOT=/usr/local/cuda
-DUSE_MKLDNN=1 -DUSE_MKL_IF_AVAILABLE=1 -DUSE_MKLML_MKL=1 -DUSE_ASAN=0
-GNinja -DUSE_OPERATOR_TUNING=1 -DUSE_CPP_PACKAGE=0 -DCUDA_ARCH_NAME=Auto
.. && ninja -v

[272/488] : && /usr/bin/c++   -Wall -Wno-unknown-pragmas -fPIC -g -O0
-msse2 -std=c++11 -fopenmp -g  -pthread
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_lockfree.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_param.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_parser.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_array_view.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_any.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_config.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_serializer.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer_exc_handling.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_inputsplit.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_json.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_optional.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_main.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_env.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_thread_group.cc.o
-o 3rdparty/dmlc-core/test/unittest/dmlc_unit_tests  -rdynamic
lib/libgtestd.a 3rdparty/dmlc-core/libdmlc.a -lpthread && :
FAILED: : && /usr/bin/c++   -Wall -Wno-unknown-pragmas -fPIC -g -O0 -msse2
-std=c++11 -fopenmp -g  -pthread
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_lockfree.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_param.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_parser.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_array_view.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_any.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_config.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_serializer.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_threaditer_exc_handling.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_inputsplit.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_json.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_optional.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_main.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_env.cc.o
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_thread_group.cc.o
-o 3rdparty/dmlc-core/test/unittest/dmlc_unit_tests  -rdynamic
lib/libgtestd.a 3rdparty/dmlc-core/libdmlc.a -lpthread && :
3rdparty/dmlc-core/test/unittest/CMakeFiles/dmlc_unit_tests.dir/unittest_logging.cc.o:
In function `Logging_basics_Test::TestBody()':
/home/ubuntu/experimentals/master_mxnet/build/../3rdparty/dmlc-core/test/unittest/unittest_logging.cc:19:
undefined reference to `testing::internal::DeathTest::Create(char const*,
testing::internal::RE const*, char const*, int,
testing::internal::DeathTest**)'
collect2: error: ld returned 1 exit status

Anirudh

On Fri, May 3, 2019 at 8:04 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> No problem Damien, glad to have you helping us validating the release.
> Just wanted to make suer we have enough votes to pass the general vote (the
> next release step) and with Sheng I think we should.
>
> On Fri, May 3, 2019 at 7:52 AM Damien Stanton 
> wrote:
>
> > Ah, I misunderstood the binding/non-binding distinction. I am not a PPMC
> > member, so my vote is non-binding.
> >
> > Best,
> > Damien
> >
> > On Fri, May 3, 2019 at 3:19 AM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > Hi Junru could you give a quick summary of the binding / non-binding
> > votes.
> > >
> > > Damien just want to confirm, are you a member of the PPMC for MXNet?
> > > Usually committers or community members (like 

Re: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread Junru Shao
Hi Konstantin, Kellen,

Thank you guys for the very detailed explanation! I was lacking some
relevant contexts and previous discussions, which got me confused
previously.

My understanding that C++ is short of a perfect package manager. I totally
agree that for any C++ project, it would be great to try possible
opportunities to make our building experience smoother. This will largely
help improve the usability of any project in the C++ community.

TensorFlow uses Bazel officially, CMake supported unofficially. PyTorch
seems to use CMake as wellMy. My understanding is that it helps users from
the community to quickly pick up the building process. If we could help
customers (industrial or academic, internal or external) build stuff more
smoothly, it would be definitely a big plus.

It will be a good idea if we have something to try out or play with. For
example, instructions for building MXNet with Conan, customizing MXNet
build with Conan, etc. Considering mshadow is going to be merged into
mxnet, I believe it is a good opportunity to illustrate the power and
convenience of Conan.

Again, thank you guys for the valuable and patient explanation!

Thanks,
Junru

On Fri, May 3, 2019 at 10:14 AM Konstantin Ivlev 
wrote:

> Hi Junru,
>
> > I am actually a bit concerned about the security issues. We are asked to
> download binaries from third-party websites, which are not controlled or
> validated by Apache
> it's possible to run conan server inside apache network and download
> binaries and sources only from this remote
>
> > CMake does support download artifacts from a pre-defined website very
> well
> same for conan, it also supports downloading of artifacts from pre-defined
> web-sites
>
> > rather than broken links to nonsense
> please let me know which links are broken. I've checked them all, and they
> are all available for me. may be your ISP is blocking something?
>
> > most of the dependencies you mentioned adopts CMake, rather than Conan
> I don't think it's relevant to compare CMake (meta-build-system) and Conan
> (package manager), they have different purposes, and they might be used
> simultaneously, or only one of them might be used, they aren't mutually
> exclusive.
>
> > Would you mind at least mentioning the benefits somewhere in this thread
> okay, let me list some benefits (not all of them, but something I have on
> mind)
> - cross-platform, runs on Windows, Linux, OSX, FreeBSD, etc., also supports
> cross-compiling for various platforms, like iOS, Android, Emscripten,
> Windows Phone, etc.
> - open-source (MIT licensed) and freeware
> - supports both build from sources and pre-built artifacts (for instance,
> if compare to usage of submodules, you probably wouldn't use pre-built
> binaries in that case, as repo size will grow)
> - supports multiple versions of libraries (some package managers provide
> only "latest")
> - supports options of libraries (whatever you need is configurable per
> library, e.g. shared vs static, with or without assembler, multi-threaded
> vs single-threaded, etc)
> - supports installation of build tools as well (something like bison, flex,
> nasm, yasm, etc.)
> - has concept of profiles and their management (include options, tools and
> environment variables to be used for build)
> - supports various build systems (CMake, Meson, MSBuild, boost build,
> etc.), pretty much build system agnostic
> - decentralized, you may use in-house server (e.g. conan server or
> artifactory), or bintray
> - extensible via hooks
> there are some comparisons of package managers on reddit (e.g.
> https://www.reddit.com/r/cpp/comments/9m4l0p/conan_vcpkg_or_build2/ and
>
> https://www.reddit.com/r/cpp/comments/8ldhu0/opinions_on_the_conan_package_manager/
> ).
>
> > and eagerly asking for avote? I believe that reasonable discussion would
> keep us within a *healthy* discussion.
> I am asking for a vote because I was told to do this on GitHub discussion
> by MXNet developers. I've already started discussions using all suggested
> channels (GitHub, JIRA and this mail list). all questions were answered,
> and no further questions appeared until today. I was thinking we already
> have passed the discussion stage, as all discussion have stalled with no
> objections (nobody clearly said something like "we're going to adopt conan"
> or "we will not use conan definetely"). so my impression was discussion
> stage was already passed, and now it's time for the decision. sorry if I
> had wrong impression, I am not really very familiar with your processes.
>
> > why not I simply specify versions in git submidule, which everyone
> understands how it behaves
> I haven't said usage of submodules itself is something bad, if you're fine
> with submodules, it's okay, but it seems like for MXNet they don't fit all
> use-cases, as some dependencies are downloaded via other ways (as mentioned
> above, via conda, cmake or just downloaded from GitHub archives in CI
> scripts). this causes fragmentation and 

Re: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread Konstantin Ivlev
Hi Junru,

> I am actually a bit concerned about the security issues. We are asked to
download binaries from third-party websites, which are not controlled or
validated by Apache
it's possible to run conan server inside apache network and download
binaries and sources only from this remote

> CMake does support download artifacts from a pre-defined website very well
same for conan, it also supports downloading of artifacts from pre-defined
web-sites

> rather than broken links to nonsense
please let me know which links are broken. I've checked them all, and they
are all available for me. may be your ISP is blocking something?

> most of the dependencies you mentioned adopts CMake, rather than Conan
I don't think it's relevant to compare CMake (meta-build-system) and Conan
(package manager), they have different purposes, and they might be used
simultaneously, or only one of them might be used, they aren't mutually
exclusive.

> Would you mind at least mentioning the benefits somewhere in this thread
okay, let me list some benefits (not all of them, but something I have on
mind)
- cross-platform, runs on Windows, Linux, OSX, FreeBSD, etc., also supports
cross-compiling for various platforms, like iOS, Android, Emscripten,
Windows Phone, etc.
- open-source (MIT licensed) and freeware
- supports both build from sources and pre-built artifacts (for instance,
if compare to usage of submodules, you probably wouldn't use pre-built
binaries in that case, as repo size will grow)
- supports multiple versions of libraries (some package managers provide
only "latest")
- supports options of libraries (whatever you need is configurable per
library, e.g. shared vs static, with or without assembler, multi-threaded
vs single-threaded, etc)
- supports installation of build tools as well (something like bison, flex,
nasm, yasm, etc.)
- has concept of profiles and their management (include options, tools and
environment variables to be used for build)
- supports various build systems (CMake, Meson, MSBuild, boost build,
etc.), pretty much build system agnostic
- decentralized, you may use in-house server (e.g. conan server or
artifactory), or bintray
- extensible via hooks
there are some comparisons of package managers on reddit (e.g.
https://www.reddit.com/r/cpp/comments/9m4l0p/conan_vcpkg_or_build2/ and
https://www.reddit.com/r/cpp/comments/8ldhu0/opinions_on_the_conan_package_manager/
).

> and eagerly asking for avote? I believe that reasonable discussion would
keep us within a *healthy* discussion.
I am asking for a vote because I was told to do this on GitHub discussion
by MXNet developers. I've already started discussions using all suggested
channels (GitHub, JIRA and this mail list). all questions were answered,
and no further questions appeared until today. I was thinking we already
have passed the discussion stage, as all discussion have stalled with no
objections (nobody clearly said something like "we're going to adopt conan"
or "we will not use conan definetely"). so my impression was discussion
stage was already passed, and now it's time for the decision. sorry if I
had wrong impression, I am not really very familiar with your processes.

> why not I simply specify versions in git submidule, which everyone
understands how it behaves
I haven't said usage of submodules itself is something bad, if you're fine
with submodules, it's okay, but it seems like for MXNet they don't fit all
use-cases, as some dependencies are downloaded via other ways (as mentioned
above, via conda, cmake or just downloaded from GitHub archives in CI
scripts). this causes fragmentation and includes complexity. so, it's clear
that submodules somehow didn't satisfy all MXNet needs, as they aren't used
for everything.

> Everyone know how to include a sub-directory in cmake in one line
probably, because not all of your dependencies are using CMake to build, so
you can't simply include them into cmake in one line.

yours sincerely, Konstantin

пт, 3 мая 2019 г. в 23:10, Junru Shao :

> I am actually a bit concerned about the security issues. We are asked to
> download binaries from third-party websites, which are not controlled or
> validated by Apache. Although it is claimed to be “decentralized”, I am
> really not convinced where the security comes from.
>
> In the meantime, sacrificing security doesn’t really bring us tangible
> benefits. CMake does support download artifacts from a pre-defined website
> very well. We may also have pre-built binaries stored in our CI docker
> without having to download it them from the internet.
>
> Another point is that I am not convinced of any advantage of Conan over
> other package managers for C++. Would you mind at least mentioning the
> benefits somewhere in this thread, rather than carelessly includes tons of
> irrelevant links (some of which are even wrong) and eagerly asking for a
> vote? I believe that reasonable discussion would keep us within a *healthy*
> discussion.
>
> Last but not least, as 

Re: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread kellen sunderland
So firstly let's try to keep our responses empathetic and avoid ad-hom
comments.  It might be beneficial to take some time to review the Apache
Code of Conduct [1].  Konstantin has taken a lot of time to think about
dependency management in MXNet on a volunteer basis which is commendable.

Second, Junru, I share many of your security concerns, but my understanding
is that Conan.io allows you to pull dependencies as binaries, or as source
using the -build option, so we're not limited to strictly pulling binaries
from remote servers.

Some benefits I see:
* A uniform method of pulling dependencies is much easier to maintain and
reason about.  Need to update a package because of a security
vulnerability?  Go to the single place we configure dependencies and update
it.
* We have many dependencies that do not need to be checked out depending on
the build options a user desires (so called build conditional
dependencies).  There's not much point in downloading / checking out these
dependencies if you're not going to use them.
* Subrepo sources have to have certified license reviews every release.
Using a package manager would solve this issue.
* We have an extra user base (Conan.io users) who get exposure to MXNet,
growing our user base.

Many of these benefits we'd get with other package management systems.  One
option I had previously proposed was Hunter, which is basically a wrapper
around CMake's ExternalProject functionality.  The tradeoff I see between
the two is that Hunter (or ExternalProject via CMake) wold be lighter
weight but would have less support, a smaller community and would be hard
to use consistently across the project with the variety of collaborators it
has.

1: https://www.apache.org/foundation/policies/conduct.html.
2: https://github.com/ruslo/hunter

On Fri, May 3, 2019 at 9:10 AM Junru Shao  wrote:

> I am actually a bit concerned about the security issues. We are asked to
> download binaries from third-party websites, which are not controlled or
> validated by Apache. Although it is claimed to be “decentralized”, I am
> really not convinced where the security comes from.
>
> In the meantime, sacrificing security doesn’t really bring us tangible
> benefits. CMake does support download artifacts from a pre-defined website
> very well. We may also have pre-built binaries stored in our CI docker
> without having to download it them from the internet.
>
> Another point is that I am not convinced of any advantage of Conan over
> other package managers for C++. Would you mind at least mentioning the
> benefits somewhere in this thread, rather than carelessly includes tons of
> irrelevant links (some of which are even wrong) and eagerly asking for a
> vote? I believe that reasonable discussion would keep us within a *healthy*
> discussion.
>
> Last but not least, as we all know, most of the dependencies you mentioned
> adopts CMake, rather than Conan, the meta-generator which generates CMake.
> I didn’t see your logic stands like “oh you have tons of dependencies so
> you must use Conan”, why not I simply specify versions in git submidule,
> which everyone understands how it behaves? Everyone know how to include a
> sub-directory in cmake in one line, so why we have to write python to make
> it less understandable and more complicated?
>
> In conclusion, we need to be reasonable in healthy discussion. I don’t
> particularly want to rudely +1 or -1 for a thing that is unclear to me, but
> I really want to see pros and cons, discussion about issues and concerns,
> rather than broken links to nonsense.
>
> Looking forward to your reply!
>
> Thanks,
> Junru
>
> On Fri, May 3, 2019 at 08:05 kellen sunderland <
> kellen.sunderl...@gmail.com>
> wrote:
>
> > Hey Konstantin.  Thanks for starting an email thread and sorry for the
> > confusion.  I think the ides is that we should discuss and agree on
> > Conan.io adoption first on the dev list, then start merging PRs.  Release
> > 1.4.1 is already in testing and the 1.5 code freeze deadline is also near
> > so I think it could be difficult to make such a large change on one of
> > those releases.  I've looked into package management solutions for the
> > project before.  I was in favour of hunter, but I think Conan's adoption
> > rate now makes it the best option.  It's simple to use and is becoming
> > industry standard, with a minor downside of requiring Python (which has
> > meanwhile become the most popular dev language).  I'd personally be -1
> for
> > 1.4.1 or 1.5, +1 for using Conan in 1.6 or 2.0.
> >
> > -Kellen
> >
> > On Fri, May 3, 2019 at 12:59 AM Konstantin Ivlev 
> > wrote:
> >
> > > hi Sheng Zha,
> > >
> > > on pull request review I was told by Anirudh anirudhacharya and Roshani
> > > Nagmote to start discussion/vote on the mxnet dev list. it seems to be
> a
> > > vicious circle now - on GitHub I am told to use vote, and on vote I am
> > told
> > > to use GitHub, this doesn't help much.
> > > FYI GitHub review stuck, it's already opened 

Re: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread Junru Shao
I am actually a bit concerned about the security issues. We are asked to
download binaries from third-party websites, which are not controlled or
validated by Apache. Although it is claimed to be “decentralized”, I am
really not convinced where the security comes from.

In the meantime, sacrificing security doesn’t really bring us tangible
benefits. CMake does support download artifacts from a pre-defined website
very well. We may also have pre-built binaries stored in our CI docker
without having to download it them from the internet.

Another point is that I am not convinced of any advantage of Conan over
other package managers for C++. Would you mind at least mentioning the
benefits somewhere in this thread, rather than carelessly includes tons of
irrelevant links (some of which are even wrong) and eagerly asking for a
vote? I believe that reasonable discussion would keep us within a *healthy*
discussion.

Last but not least, as we all know, most of the dependencies you mentioned
adopts CMake, rather than Conan, the meta-generator which generates CMake.
I didn’t see your logic stands like “oh you have tons of dependencies so
you must use Conan”, why not I simply specify versions in git submidule,
which everyone understands how it behaves? Everyone know how to include a
sub-directory in cmake in one line, so why we have to write python to make
it less understandable and more complicated?

In conclusion, we need to be reasonable in healthy discussion. I don’t
particularly want to rudely +1 or -1 for a thing that is unclear to me, but
I really want to see pros and cons, discussion about issues and concerns,
rather than broken links to nonsense.

Looking forward to your reply!

Thanks,
Junru

On Fri, May 3, 2019 at 08:05 kellen sunderland 
wrote:

> Hey Konstantin.  Thanks for starting an email thread and sorry for the
> confusion.  I think the ides is that we should discuss and agree on
> Conan.io adoption first on the dev list, then start merging PRs.  Release
> 1.4.1 is already in testing and the 1.5 code freeze deadline is also near
> so I think it could be difficult to make such a large change on one of
> those releases.  I've looked into package management solutions for the
> project before.  I was in favour of hunter, but I think Conan's adoption
> rate now makes it the best option.  It's simple to use and is becoming
> industry standard, with a minor downside of requiring Python (which has
> meanwhile become the most popular dev language).  I'd personally be -1 for
> 1.4.1 or 1.5, +1 for using Conan in 1.6 or 2.0.
>
> -Kellen
>
> On Fri, May 3, 2019 at 12:59 AM Konstantin Ivlev 
> wrote:
>
> > hi Sheng Zha,
> >
> > on pull request review I was told by Anirudh anirudhacharya and Roshani
> > Nagmote to start discussion/vote on the mxnet dev list. it seems to be a
> > vicious circle now - on GitHub I am told to use vote, and on vote I am
> told
> > to use GitHub, this doesn't help much.
> > FYI GitHub review stuck, it's already opened since November 2018, and
> it's
> > still not approved (however, there were no objections during the review).
> > Previous discussion in e-mail thread also didn't encounter any
> objections,
> > and all questions were answered.
> > JIRA ticket has no discussion at all (except it has duplicates of
> comments
> > made on GitHub).
> > so let's process with 3-day vote for now, as other communication channels
> > were already tried with no success.
> >
> > yours sincerely, Konstantin
> >
> > пт, 3 мая 2019 г. в 14:17, Sheng Zha :
> >
> > > Hi Konstantin,
> > >
> > > While conan looks like an option that's worth exploring, given that
> your
> > > request is to merge the pull request, I'd suggest that the request
> should
> > > go through the regular pull request review and it doesn't really need a
> > > vote (as it doesn't substitute reviews anyway)
> > >
> > > If you would like to gather more attention to it, feel free to ping in
> a
> > > discussion thread.
> > >
> > > -sz
> > >
> > > On 2019/05/03 06:29:55, Konstantin Ivlev  wrote:
> > > > Dear MXNet community,
> > > >
> > > > This is the 3-day vote to add conan support for Apache MXNet
> > (incubating)
> > > > version v1.4.1.
> > > > The voting on dev@ list will start May 03 23:59:59 (PST) and close
> on
> > > May
> > > > 06 23:59:59.
> > > >
> > > > Background: conan is open-source, freeware, cross-platform package
> > > manager
> > > > for C and C++ projects, written in python. it provides integration
> with
> > > > various build systems, include CMake. conan may use bintray as a
> server
> > > to
> > > > store and download pre-built packages, or packages might be always
> > built
> > > > from sources.
> > > >
> > > > Problem: currently (as for v1.4.1), Apache MXNet (incubating) is
> using
> > > > several ways to fetch 3rd-party dependencies simultaneously, for
> > > instance:
> > > > 1. download GitHub archives during the build
> > > > - OpenBLAS
> > > > - OpenCV
> > > > 2. conda (alternative way to GitHub archives)
> > 

Re: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread kellen sunderland
Hey Konstantin.  Thanks for starting an email thread and sorry for the
confusion.  I think the ides is that we should discuss and agree on
Conan.io adoption first on the dev list, then start merging PRs.  Release
1.4.1 is already in testing and the 1.5 code freeze deadline is also near
so I think it could be difficult to make such a large change on one of
those releases.  I've looked into package management solutions for the
project before.  I was in favour of hunter, but I think Conan's adoption
rate now makes it the best option.  It's simple to use and is becoming
industry standard, with a minor downside of requiring Python (which has
meanwhile become the most popular dev language).  I'd personally be -1 for
1.4.1 or 1.5, +1 for using Conan in 1.6 or 2.0.

-Kellen

On Fri, May 3, 2019 at 12:59 AM Konstantin Ivlev 
wrote:

> hi Sheng Zha,
>
> on pull request review I was told by Anirudh anirudhacharya and Roshani
> Nagmote to start discussion/vote on the mxnet dev list. it seems to be a
> vicious circle now - on GitHub I am told to use vote, and on vote I am told
> to use GitHub, this doesn't help much.
> FYI GitHub review stuck, it's already opened since November 2018, and it's
> still not approved (however, there were no objections during the review).
> Previous discussion in e-mail thread also didn't encounter any objections,
> and all questions were answered.
> JIRA ticket has no discussion at all (except it has duplicates of comments
> made on GitHub).
> so let's process with 3-day vote for now, as other communication channels
> were already tried with no success.
>
> yours sincerely, Konstantin
>
> пт, 3 мая 2019 г. в 14:17, Sheng Zha :
>
> > Hi Konstantin,
> >
> > While conan looks like an option that's worth exploring, given that your
> > request is to merge the pull request, I'd suggest that the request should
> > go through the regular pull request review and it doesn't really need a
> > vote (as it doesn't substitute reviews anyway)
> >
> > If you would like to gather more attention to it, feel free to ping in a
> > discussion thread.
> >
> > -sz
> >
> > On 2019/05/03 06:29:55, Konstantin Ivlev  wrote:
> > > Dear MXNet community,
> > >
> > > This is the 3-day vote to add conan support for Apache MXNet
> (incubating)
> > > version v1.4.1.
> > > The voting on dev@ list will start May 03 23:59:59 (PST) and close on
> > May
> > > 06 23:59:59.
> > >
> > > Background: conan is open-source, freeware, cross-platform package
> > manager
> > > for C and C++ projects, written in python. it provides integration with
> > > various build systems, include CMake. conan may use bintray as a server
> > to
> > > store and download pre-built packages, or packages might be always
> built
> > > from sources.
> > >
> > > Problem: currently (as for v1.4.1), Apache MXNet (incubating) is using
> > > several ways to fetch 3rd-party dependencies simultaneously, for
> > instance:
> > > 1. download GitHub archives during the build
> > > - OpenBLAS
> > > - OpenCV
> > > 2. conda (alternative way to GitHub archives)
> > > 3. download from CMake
> > > - Intel Math Kernel Library (MKL)
> > > 4. Git submodules
> > > - cub
> > > - dlpack
> > > - dmlc-core
> > > - googletest
> > > - mkldnn
> > > - mshadow
> > > - onnx-tensorrt
> > > - openmp
> > > - ps-lite
> > > - tvm
> > > therefore, there are multiple places to look for 3rd parties, and its
> > hard
> > > to update them, as you need to remember or figure it out how to update
> a
> > > particular dependency to newer version, for instance.
> > > current Apache MXNet (incubating) build instructions differ very much
> per
> > > platform, require to download and unzip some archives manually,
> > specifying
> > > variables with paths to this archives, in conjunction of updating git
> > > submodules,
> > >
> > > Action: merge pull request providing an initial conan support for
> Apache
> > > MXNet (incubating). support conan as an alternate approach to fetch
> > various
> > > 3rd-party dependencies. old approaches will be still available,
> supported
> > > and left intact.
> > >
> > > Below are links to
> > > 1) conan web-site:  https://conan.io/
> > > 2) conan GitHub repository: https://github.com/conan-io/conan
> > > 3) conan documentation: https://docs.conan.io/en/latest/
> > > 4) bintray: https://bintray.com
> > > 5) pull request adding conan support to Apache MXNet (incubating):
> > > https://github.com/apache/incubator-mxnet/pull/13400
> > > 6) JIRA issue: https://issues.apache.org/jira/browse/MXNET-1229
> > > 7) previous email discussion:
> > >
> >
> https://lists.apache.org/thread.html/301a46a637f7e3c249c475713f701bef7530c32bc92d8834c0882897@%3Cdev.mxnet.apache.org%3E
> > > 8) MXNet build instructions:
> > > https://mxnet-tqchen.readthedocs.io/en/latest/how_to/build.html
> > > 9) MXNet build instructions (Windows):
> > >
> >
> https://mxnet.incubator.apache.org/versions/master/install/windows_setup.html
> > > 10) MXNet build instructions (OSX):
> > >
> 

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

2019-05-03 Thread kellen sunderland
No problem Damien, glad to have you helping us validating the release.
Just wanted to make suer we have enough votes to pass the general vote (the
next release step) and with Sheng I think we should.

On Fri, May 3, 2019 at 7:52 AM Damien Stanton 
wrote:

> Ah, I misunderstood the binding/non-binding distinction. I am not a PPMC
> member, so my vote is non-binding.
>
> Best,
> Damien
>
> On Fri, May 3, 2019 at 3:19 AM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > Hi Junru could you give a quick summary of the binding / non-binding
> votes.
> >
> > Damien just want to confirm, are you a member of the PPMC for MXNet?
> > Usually committers or community members (like most of us) are encouraged
> to
> > test and vote, but technically count as non-binding for releases.
> >
> > Sheng can we assume you're +1 on the release?
> >
> > On Fri, May 3, 2019 at 12:09 AM Junru Shao 
> > wrote:
> >
> > > Hi folks,
> > >
> > > So far we have collected enough binding votes. Thank you guys for the
> > hard
> > > work testing the release!
> > >
> > > The vote on dev@ is closed on May 02 23:59:59 (PST). Next, we are
> going
> > to
> > > vote for the Apache MXNet (incubating) release 1.4.1 on general@
> > tomorrow,
> > > which starts on May 3 2019, 23:59:59 PST, and ends on May 07 2019,
> > 23:59:59
> > > PST.
> > >
> > > Best,
> > > Junru
> > >
> > > On Thu, May 2, 2019 at 11:29 PM Aston Zhang 
> > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Passed all the code at zh.d2l.ai
> > > >
> > > > On Thu, May 2, 2019 at 1:46 PM Joshua Z. Zhang  >
> > > > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Build from source with cuda/cudnn.
> > > > >
> > > > > - All tests passed
> > > > > - GluonCV unittest scripts passed
> > > > > - GluonCV training scripts passed
> > > > > - No issue with python multiprocessing
> > > > >
> > > > > Best,
> > > > > Zhi
> > > > > > On May 2, 2019, at 11:34 AM, kellen sunderland <
> > > > > kellen.sunderl...@gmail.com> wrote:
> > > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > I checked TRT integration builds and tests pass.
> > > > > > MD5s
> > > > > > Sigs look good.
> > > > > >
> > > > > > -Kellen
> > > > > >
> > > > > > On Thu, May 2, 2019 at 10:51 AM Damien Stanton <
> > > > damien.stan...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> +1 (binding)
> > > > > >>
> > > > > >> Built from source / Scala / Clojure. All tests pass. The only
> > issue
> > > of
> > > > > >> minor note: The macOS build guide indicates a directive `brew
> > > install
> > > > > >> opencv` however this installs OpenCV 4, which is currently
> > > > incompatible
> > > > > >> with mxnet and causes a failed build. The guide should specify
> > `brew
> > > > > >> install opencv@3` until/if version 4 is supported.
> > > > > >>
> > > > > >> Best,
> > > > > >> Damien
> > > > > >>
> > > > > >> On Thu, May 2, 2019 at 12:53 PM Lai Wei 
> > > wrote:
> > > > > >>
> > > > > >>> +1
> > > > > >>>
> > > > > >>> Built from source and tested keras-mxnet working fine.
> > > > > >>>
> > > > > >>> Best Regards
> > > > > >>>
> > > > > >>> Lai
> > > > > >>>
> > > > > >>>
> > > > > >>> On Wed, May 1, 2019 at 4:22 PM Carin Meier <
> carinme...@gmail.com
> > >
> > > > > wrote:
> > > > > >>>
> > > > >  + 1 (binding)
> > > > > 
> > > > >  Built Scala/ Clojure and ran tests
> > > > > 
> > > > >  On Wed, May 1, 2019 at 7:06 PM Aaron Markham <
> > > > > >> aaron.s.mark...@gmail.com>
> > > > >  wrote:
> > > > > 
> > > > > > Make that +1 (non-binding)
> > > > > >
> > > > > > On Wed, May 1, 2019 at 3:42 PM Aaron Markham <
> > > > > >>> aaron.s.mark...@gmail.com>
> > > > > > wrote:
> > > > > >>
> > > > > >> +1 (binding)
> > > > > >>
> > > > > >> * Built with GPU and tested the first part of the ssd
> example.
> > > > > >> * Built with GPU / cross-compiled to arm8 for Jetson.
> > > > > >> * Built Scala/Java on top of the cross-compiled arm8 (ran
> into
> > > > > >>> trouble
> > > > > >> here, but I think this is not popular enough yet to derail
> > > things,
> > > > > >> plus there are workarounds)
> > > > > >> * Built on CPU instance and tested docs.
> > > > > >> http://34.201.8.176/versions/1.4.1/api/python/io/io.html
> > > > > >> I don't see anything specific being different in this patch
> > for
> > > > > >> docs,
> > > > > >> so hard to tell if there's an issue. I'll assume not given
> the
> > > > > >> successful generation of the API docs.
> > > > > >>
> > > > > >>
> > > > > >> On Wed, May 1, 2019 at 1:28 PM Pedro Larroy
> > > > > >>  wrote:
> > > > > >>>
> > > > > >>> +1 (non-binding)
> > > > > >>>
> > > > > >>> Tried CPU build + C++ tests + 714 Python unit tests in
> 605s.
> > > > > >>> ARMv7 build + small unit test in QEMU + ARMv8 builds.
> > > > > >>>
> > > > > >>> Thanks. Regards
> > > > > >>>
> > > > > >>> Pedro.
> > > > > >>>
> > > > 

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

2019-05-03 Thread Damien Stanton
Ah, I misunderstood the binding/non-binding distinction. I am not a PPMC
member, so my vote is non-binding.

Best,
Damien

On Fri, May 3, 2019 at 3:19 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Hi Junru could you give a quick summary of the binding / non-binding votes.
>
> Damien just want to confirm, are you a member of the PPMC for MXNet?
> Usually committers or community members (like most of us) are encouraged to
> test and vote, but technically count as non-binding for releases.
>
> Sheng can we assume you're +1 on the release?
>
> On Fri, May 3, 2019 at 12:09 AM Junru Shao 
> wrote:
>
> > Hi folks,
> >
> > So far we have collected enough binding votes. Thank you guys for the
> hard
> > work testing the release!
> >
> > The vote on dev@ is closed on May 02 23:59:59 (PST). Next, we are going
> to
> > vote for the Apache MXNet (incubating) release 1.4.1 on general@
> tomorrow,
> > which starts on May 3 2019, 23:59:59 PST, and ends on May 07 2019,
> 23:59:59
> > PST.
> >
> > Best,
> > Junru
> >
> > On Thu, May 2, 2019 at 11:29 PM Aston Zhang 
> wrote:
> >
> > > +1 (non-binding)
> > >
> > > Passed all the code at zh.d2l.ai
> > >
> > > On Thu, May 2, 2019 at 1:46 PM Joshua Z. Zhang 
> > > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Build from source with cuda/cudnn.
> > > >
> > > > - All tests passed
> > > > - GluonCV unittest scripts passed
> > > > - GluonCV training scripts passed
> > > > - No issue with python multiprocessing
> > > >
> > > > Best,
> > > > Zhi
> > > > > On May 2, 2019, at 11:34 AM, kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > I checked TRT integration builds and tests pass.
> > > > > MD5s
> > > > > Sigs look good.
> > > > >
> > > > > -Kellen
> > > > >
> > > > > On Thu, May 2, 2019 at 10:51 AM Damien Stanton <
> > > damien.stan...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> +1 (binding)
> > > > >>
> > > > >> Built from source / Scala / Clojure. All tests pass. The only
> issue
> > of
> > > > >> minor note: The macOS build guide indicates a directive `brew
> > install
> > > > >> opencv` however this installs OpenCV 4, which is currently
> > > incompatible
> > > > >> with mxnet and causes a failed build. The guide should specify
> `brew
> > > > >> install opencv@3` until/if version 4 is supported.
> > > > >>
> > > > >> Best,
> > > > >> Damien
> > > > >>
> > > > >> On Thu, May 2, 2019 at 12:53 PM Lai Wei 
> > wrote:
> > > > >>
> > > > >>> +1
> > > > >>>
> > > > >>> Built from source and tested keras-mxnet working fine.
> > > > >>>
> > > > >>> Best Regards
> > > > >>>
> > > > >>> Lai
> > > > >>>
> > > > >>>
> > > > >>> On Wed, May 1, 2019 at 4:22 PM Carin Meier  >
> > > > wrote:
> > > > >>>
> > > >  + 1 (binding)
> > > > 
> > > >  Built Scala/ Clojure and ran tests
> > > > 
> > > >  On Wed, May 1, 2019 at 7:06 PM Aaron Markham <
> > > > >> aaron.s.mark...@gmail.com>
> > > >  wrote:
> > > > 
> > > > > Make that +1 (non-binding)
> > > > >
> > > > > On Wed, May 1, 2019 at 3:42 PM Aaron Markham <
> > > > >>> aaron.s.mark...@gmail.com>
> > > > > wrote:
> > > > >>
> > > > >> +1 (binding)
> > > > >>
> > > > >> * Built with GPU and tested the first part of the ssd example.
> > > > >> * Built with GPU / cross-compiled to arm8 for Jetson.
> > > > >> * Built Scala/Java on top of the cross-compiled arm8 (ran into
> > > > >>> trouble
> > > > >> here, but I think this is not popular enough yet to derail
> > things,
> > > > >> plus there are workarounds)
> > > > >> * Built on CPU instance and tested docs.
> > > > >> http://34.201.8.176/versions/1.4.1/api/python/io/io.html
> > > > >> I don't see anything specific being different in this patch
> for
> > > > >> docs,
> > > > >> so hard to tell if there's an issue. I'll assume not given the
> > > > >> successful generation of the API docs.
> > > > >>
> > > > >>
> > > > >> On Wed, May 1, 2019 at 1:28 PM Pedro Larroy
> > > > >>  wrote:
> > > > >>>
> > > > >>> +1 (non-binding)
> > > > >>>
> > > > >>> Tried CPU build + C++ tests + 714 Python unit tests in 605s.
> > > > >>> ARMv7 build + small unit test in QEMU + ARMv8 builds.
> > > > >>>
> > > > >>> Thanks. Regards
> > > > >>>
> > > > >>> Pedro.
> > > > >>>
> > > > >>> On Wed, May 1, 2019 at 10:41 AM Qing Lan <
> lanking...@live.com>
> > > >  wrote:
> > > > 
> > > >  +1 (binding)
> > > > 
> > > >  build from source works for OSX and Ubuntu CPU
> > > >  Scala build/test successfully with Dynamic link and static
> > > > >> link.
> > > > 
> > > >  Thanks,
> > > >  Qing
> > > > 
> > > >  
> > > >  From: Sheng Zha 
> > > >  Sent: Wednesday, May 1, 2019 13:14
> > > >  To: d...@mxnet.apache.org
> > > >  

Re: DNS failures in jenkins

2019-05-03 Thread Max G. Faraday
Hey,

This sounds likely. Yes, we’ll take a look, if they haven’t already. 


"I'm trying real hard to be the shepherd." -Jules Winnfield


> On Apr 25, 2019, at 8:00 PM, Pedro Larroy  
> wrote:
> 
> Hi
> 
> I see some DNS resolution failures on jenkins, I think this is the
> cause of jenkins not reporting the build status sometimes. What dns
> server are we using in the master? should we add a couple of secondary
> resolvers to remediate?
> 
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Fwebsite/detail/PR-14788/2/pipeline/
> 
> 
> Thanks.
> 
> Pedro.


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

2019-05-03 Thread chohyu01
+1 (non-binding)

Built MXNet from source for CPU target.
I was able to run the quantization example with MKLDNN at 
https://github.com/apache/incubator-mxnet/tree/1.4.1.rc0/example/quantization

Philip.

On 2019/04/30 06:51:45, Junru Shao  wrote: 
> Dear MXNet community,
> 
> This is the 3-day vote to release Apache MXNet (incubating) version v1.4.1.
> The voting on dev@ list will start Apr 29 23:59:59 (PST) and close on May
> 02 23:59:59.
> 
> Below are links to
> 1) Release notes:
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.1+Release+Notes
> .
> 2) Release Candidate:
> https://github.com/apache/incubator-mxnet/releases/tag/1.4.1.rc0.
> 3) Source and signatures on Apache dist server:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.1.rc0/.
> 
> Please remember to TEST first before voting accordingly:
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
> 
> Best regards,
> Junru Shao
> 


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

2019-05-03 Thread kellen sunderland
Awesome.  That should do it.  Thanks Sheng, and Junru for being the manager
this time around.

On Fri, May 3, 2019, 12:24 AM Sheng Zha  wrote:

> Hi Kellen,
>
> Of course, feel free to count in my vote if that’s ok. Since I helped
> prepare the artifacts I wasn’t sure if it was appropriate for me to vote so
> I refrained from voting till now.
>
> +1
>
> -sz
>
> > On May 3, 2019, at 12:19 AM, kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
> >
> > Hi Junru could you give a quick summary of the binding / non-binding
> votes.
> >
> > Damien just want to confirm, are you a member of the PPMC for MXNet?
> > Usually committers or community members (like most of us) are encouraged
> to
> > test and vote, but technically count as non-binding for releases.
> >
> > Sheng can we assume you're +1 on the release?
> >
> >> On Fri, May 3, 2019 at 12:09 AM Junru Shao 
> wrote:
> >>
> >> Hi folks,
> >>
> >> So far we have collected enough binding votes. Thank you guys for the
> hard
> >> work testing the release!
> >>
> >> The vote on dev@ is closed on May 02 23:59:59 (PST). Next, we are
> going to
> >> vote for the Apache MXNet (incubating) release 1.4.1 on general@
> tomorrow,
> >> which starts on May 3 2019, 23:59:59 PST, and ends on May 07 2019,
> 23:59:59
> >> PST.
> >>
> >> Best,
> >> Junru
> >>
> >>> On Thu, May 2, 2019 at 11:29 PM Aston Zhang 
> wrote:
> >>>
> >>> +1 (non-binding)
> >>>
> >>> Passed all the code at zh.d2l.ai
> >>>
> >>> On Thu, May 2, 2019 at 1:46 PM Joshua Z. Zhang 
> >>> wrote:
> >>>
>  +1 (non-binding)
> 
>  Build from source with cuda/cudnn.
> 
>  - All tests passed
>  - GluonCV unittest scripts passed
>  - GluonCV training scripts passed
>  - No issue with python multiprocessing
> 
>  Best,
>  Zhi
> > On May 2, 2019, at 11:34 AM, kellen sunderland <
>  kellen.sunderl...@gmail.com> wrote:
> >
> > +1 (non-binding)
> >
> > I checked TRT integration builds and tests pass.
> > MD5s
> > Sigs look good.
> >
> > -Kellen
> >
> > On Thu, May 2, 2019 at 10:51 AM Damien Stanton <
> >>> damien.stan...@gmail.com
> >
> > wrote:
> >
> >> +1 (binding)
> >>
> >> Built from source / Scala / Clojure. All tests pass. The only issue
> >> of
> >> minor note: The macOS build guide indicates a directive `brew
> >> install
> >> opencv` however this installs OpenCV 4, which is currently
> >>> incompatible
> >> with mxnet and causes a failed build. The guide should specify `brew
> >> install opencv@3` until/if version 4 is supported.
> >>
> >> Best,
> >> Damien
> >>
> >> On Thu, May 2, 2019 at 12:53 PM Lai Wei 
> >> wrote:
> >>
> >>> +1
> >>>
> >>> Built from source and tested keras-mxnet working fine.
> >>>
> >>> Best Regards
> >>>
> >>> Lai
> >>>
> >>>
> >>> On Wed, May 1, 2019 at 4:22 PM Carin Meier 
>  wrote:
> >>>
>  + 1 (binding)
> 
>  Built Scala/ Clojure and ran tests
> 
>  On Wed, May 1, 2019 at 7:06 PM Aaron Markham <
> >> aaron.s.mark...@gmail.com>
>  wrote:
> 
> > Make that +1 (non-binding)
> >
> > On Wed, May 1, 2019 at 3:42 PM Aaron Markham <
> >>> aaron.s.mark...@gmail.com>
> > wrote:
> >>
> >> +1 (binding)
> >>
> >> * Built with GPU and tested the first part of the ssd example.
> >> * Built with GPU / cross-compiled to arm8 for Jetson.
> >> * Built Scala/Java on top of the cross-compiled arm8 (ran into
> >>> trouble
> >> here, but I think this is not popular enough yet to derail
> >> things,
> >> plus there are workarounds)
> >> * Built on CPU instance and tested docs.
> >> http://34.201.8.176/versions/1.4.1/api/python/io/io.html
> >> I don't see anything specific being different in this patch for
> >> docs,
> >> so hard to tell if there's an issue. I'll assume not given the
> >> successful generation of the API docs.
> >>
> >>
> >> On Wed, May 1, 2019 at 1:28 PM Pedro Larroy
> >>  wrote:
> >>>
> >>> +1 (non-binding)
> >>>
> >>> Tried CPU build + C++ tests + 714 Python unit tests in 605s.
> >>> ARMv7 build + small unit test in QEMU + ARMv8 builds.
> >>>
> >>> Thanks. Regards
> >>>
> >>> Pedro.
> >>>
> >>> On Wed, May 1, 2019 at 10:41 AM Qing Lan 
>  wrote:
> 
>  +1 (binding)
> 
>  build from source works for OSX and Ubuntu CPU
>  Scala build/test successfully with Dynamic link and static
> >> link.
> 
>  Thanks,
>  Qing
> 
>  
>  From: Sheng Zha 
>  Sent: Wednesday, May 1, 2019 13:14
> 

Re: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread Konstantin Ivlev
hi Sheng Zha,

on pull request review I was told by Anirudh anirudhacharya and Roshani
Nagmote to start discussion/vote on the mxnet dev list. it seems to be a
vicious circle now - on GitHub I am told to use vote, and on vote I am told
to use GitHub, this doesn't help much.
FYI GitHub review stuck, it's already opened since November 2018, and it's
still not approved (however, there were no objections during the review).
Previous discussion in e-mail thread also didn't encounter any objections,
and all questions were answered.
JIRA ticket has no discussion at all (except it has duplicates of comments
made on GitHub).
so let's process with 3-day vote for now, as other communication channels
were already tried with no success.

yours sincerely, Konstantin

пт, 3 мая 2019 г. в 14:17, Sheng Zha :

> Hi Konstantin,
>
> While conan looks like an option that's worth exploring, given that your
> request is to merge the pull request, I'd suggest that the request should
> go through the regular pull request review and it doesn't really need a
> vote (as it doesn't substitute reviews anyway)
>
> If you would like to gather more attention to it, feel free to ping in a
> discussion thread.
>
> -sz
>
> On 2019/05/03 06:29:55, Konstantin Ivlev  wrote:
> > Dear MXNet community,
> >
> > This is the 3-day vote to add conan support for Apache MXNet (incubating)
> > version v1.4.1.
> > The voting on dev@ list will start May 03 23:59:59 (PST) and close on
> May
> > 06 23:59:59.
> >
> > Background: conan is open-source, freeware, cross-platform package
> manager
> > for C and C++ projects, written in python. it provides integration with
> > various build systems, include CMake. conan may use bintray as a server
> to
> > store and download pre-built packages, or packages might be always built
> > from sources.
> >
> > Problem: currently (as for v1.4.1), Apache MXNet (incubating) is using
> > several ways to fetch 3rd-party dependencies simultaneously, for
> instance:
> > 1. download GitHub archives during the build
> > - OpenBLAS
> > - OpenCV
> > 2. conda (alternative way to GitHub archives)
> > 3. download from CMake
> > - Intel Math Kernel Library (MKL)
> > 4. Git submodules
> > - cub
> > - dlpack
> > - dmlc-core
> > - googletest
> > - mkldnn
> > - mshadow
> > - onnx-tensorrt
> > - openmp
> > - ps-lite
> > - tvm
> > therefore, there are multiple places to look for 3rd parties, and its
> hard
> > to update them, as you need to remember or figure it out how to update a
> > particular dependency to newer version, for instance.
> > current Apache MXNet (incubating) build instructions differ very much per
> > platform, require to download and unzip some archives manually,
> specifying
> > variables with paths to this archives, in conjunction of updating git
> > submodules,
> >
> > Action: merge pull request providing an initial conan support for Apache
> > MXNet (incubating). support conan as an alternate approach to fetch
> various
> > 3rd-party dependencies. old approaches will be still available, supported
> > and left intact.
> >
> > Below are links to
> > 1) conan web-site:  https://conan.io/
> > 2) conan GitHub repository: https://github.com/conan-io/conan
> > 3) conan documentation: https://docs.conan.io/en/latest/
> > 4) bintray: https://bintray.com
> > 5) pull request adding conan support to Apache MXNet (incubating):
> > https://github.com/apache/incubator-mxnet/pull/13400
> > 6) JIRA issue: https://issues.apache.org/jira/browse/MXNET-1229
> > 7) previous email discussion:
> >
> https://lists.apache.org/thread.html/301a46a637f7e3c249c475713f701bef7530c32bc92d8834c0882897@%3Cdev.mxnet.apache.org%3E
> > 8) MXNet build instructions:
> > https://mxnet-tqchen.readthedocs.io/en/latest/how_to/build.html
> > 9) MXNet build instructions (Windows):
> >
> https://mxnet.incubator.apache.org/versions/master/install/windows_setup.html
> > 10) MXNet build instructions (OSX):
> > http://mxnet.incubator.apache.org/versions/master/install/osx_setup.html
> > 11) MXNet build instructions (Linux):
> >
> http://mxnet.incubator.apache.org/versions/master/install/ubuntu_setup.html
> > 12) MXNet development setup (OSX):
> >
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac
> >
> > Please remember to TEST first before voting accordingly:
> > +1 = approve
> > +0 = no opinion
> > -1 = disapprove (provide reason)
> >
> > Best regards,
> > Konstantin Ivlev
> >
>


Re: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread Konstantin Ivlev
hi Sheng Zha,

on pull request review I was told by Anirudh anirudhacharya and Roshani
Nagmote to start discussion/vote on the mxnet dev list. it seems to be a
vicious circle now - on GitHub I am told to use vote, and on vote I am told
to use GitHub, this doesn't help much.
FYI GitHub review stuck, it's already opened since November 2018, and it's
still not approved (however, there were no objections during the review).
Previous discussion in e-mail thread also didn't encounter any objections,
and all questions were answered.
JIRA ticket has no discussion at all (except it has duplicates of comments
made on GitHub).
so let's process with 3-day vote for now, as other communication channels
were already tried with no success.

yours sincerely, Konstantin

пт, 3 мая 2019 г. в 14:17, Sheng Zha :

> Hi Konstantin,
>
> While conan looks like an option that's worth exploring, given that your
> request is to merge the pull request, I'd suggest that the request should
> go through the regular pull request review and it doesn't really need a
> vote (as it doesn't substitute reviews anyway)
>
> If you would like to gather more attention to it, feel free to ping in a
> discussion thread.
>
> -sz
>
> On 2019/05/03 06:29:55, Konstantin Ivlev  wrote:
> > Dear MXNet community,
> >
> > This is the 3-day vote to add conan support for Apache MXNet (incubating)
> > version v1.4.1.
> > The voting on dev@ list will start May 03 23:59:59 (PST) and close on
> May
> > 06 23:59:59.
> >
> > Background: conan is open-source, freeware, cross-platform package
> manager
> > for C and C++ projects, written in python. it provides integration with
> > various build systems, include CMake. conan may use bintray as a server
> to
> > store and download pre-built packages, or packages might be always built
> > from sources.
> >
> > Problem: currently (as for v1.4.1), Apache MXNet (incubating) is using
> > several ways to fetch 3rd-party dependencies simultaneously, for
> instance:
> > 1. download GitHub archives during the build
> > - OpenBLAS
> > - OpenCV
> > 2. conda (alternative way to GitHub archives)
> > 3. download from CMake
> > - Intel Math Kernel Library (MKL)
> > 4. Git submodules
> > - cub
> > - dlpack
> > - dmlc-core
> > - googletest
> > - mkldnn
> > - mshadow
> > - onnx-tensorrt
> > - openmp
> > - ps-lite
> > - tvm
> > therefore, there are multiple places to look for 3rd parties, and its
> hard
> > to update them, as you need to remember or figure it out how to update a
> > particular dependency to newer version, for instance.
> > current Apache MXNet (incubating) build instructions differ very much per
> > platform, require to download and unzip some archives manually,
> specifying
> > variables with paths to this archives, in conjunction of updating git
> > submodules,
> >
> > Action: merge pull request providing an initial conan support for Apache
> > MXNet (incubating). support conan as an alternate approach to fetch
> various
> > 3rd-party dependencies. old approaches will be still available, supported
> > and left intact.
> >
> > Below are links to
> > 1) conan web-site:  https://conan.io/
> > 2) conan GitHub repository: https://github.com/conan-io/conan
> > 3) conan documentation: https://docs.conan.io/en/latest/
> > 4) bintray: https://bintray.com
> > 5) pull request adding conan support to Apache MXNet (incubating):
> > https://github.com/apache/incubator-mxnet/pull/13400
> > 6) JIRA issue: https://issues.apache.org/jira/browse/MXNET-1229
> > 7) previous email discussion:
> >
> https://lists.apache.org/thread.html/301a46a637f7e3c249c475713f701bef7530c32bc92d8834c0882897@%3Cdev.mxnet.apache.org%3E
> > 8) MXNet build instructions:
> > https://mxnet-tqchen.readthedocs.io/en/latest/how_to/build.html
> > 9) MXNet build instructions (Windows):
> >
> https://mxnet.incubator.apache.org/versions/master/install/windows_setup.html
> > 10) MXNet build instructions (OSX):
> > http://mxnet.incubator.apache.org/versions/master/install/osx_setup.html
> > 11) MXNet build instructions (Linux):
> >
> http://mxnet.incubator.apache.org/versions/master/install/ubuntu_setup.html
> > 12) MXNet development setup (OSX):
> >
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac
> >
> > Please remember to TEST first before voting accordingly:
> > +1 = approve
> > +0 = no opinion
> > -1 = disapprove (provide reason)
> >
> > Best regards,
> > Konstantin Ivlev
> >
>


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

2019-05-03 Thread Sheng Zha
Hi Kellen,

Of course, feel free to count in my vote if that’s ok. Since I helped prepare 
the artifacts I wasn’t sure if it was appropriate for me to vote so I refrained 
from voting till now.

+1

-sz

> On May 3, 2019, at 12:19 AM, kellen sunderland  
> wrote:
> 
> Hi Junru could you give a quick summary of the binding / non-binding votes.
> 
> Damien just want to confirm, are you a member of the PPMC for MXNet?
> Usually committers or community members (like most of us) are encouraged to
> test and vote, but technically count as non-binding for releases.
> 
> Sheng can we assume you're +1 on the release?
> 
>> On Fri, May 3, 2019 at 12:09 AM Junru Shao  wrote:
>> 
>> Hi folks,
>> 
>> So far we have collected enough binding votes. Thank you guys for the hard
>> work testing the release!
>> 
>> The vote on dev@ is closed on May 02 23:59:59 (PST). Next, we are going to
>> vote for the Apache MXNet (incubating) release 1.4.1 on general@ tomorrow,
>> which starts on May 3 2019, 23:59:59 PST, and ends on May 07 2019, 23:59:59
>> PST.
>> 
>> Best,
>> Junru
>> 
>>> On Thu, May 2, 2019 at 11:29 PM Aston Zhang  wrote:
>>> 
>>> +1 (non-binding)
>>> 
>>> Passed all the code at zh.d2l.ai
>>> 
>>> On Thu, May 2, 2019 at 1:46 PM Joshua Z. Zhang 
>>> wrote:
>>> 
 +1 (non-binding)
 
 Build from source with cuda/cudnn.
 
 - All tests passed
 - GluonCV unittest scripts passed
 - GluonCV training scripts passed
 - No issue with python multiprocessing
 
 Best,
 Zhi
> On May 2, 2019, at 11:34 AM, kellen sunderland <
 kellen.sunderl...@gmail.com> wrote:
> 
> +1 (non-binding)
> 
> I checked TRT integration builds and tests pass.
> MD5s
> Sigs look good.
> 
> -Kellen
> 
> On Thu, May 2, 2019 at 10:51 AM Damien Stanton <
>>> damien.stan...@gmail.com
> 
> wrote:
> 
>> +1 (binding)
>> 
>> Built from source / Scala / Clojure. All tests pass. The only issue
>> of
>> minor note: The macOS build guide indicates a directive `brew
>> install
>> opencv` however this installs OpenCV 4, which is currently
>>> incompatible
>> with mxnet and causes a failed build. The guide should specify `brew
>> install opencv@3` until/if version 4 is supported.
>> 
>> Best,
>> Damien
>> 
>> On Thu, May 2, 2019 at 12:53 PM Lai Wei 
>> wrote:
>> 
>>> +1
>>> 
>>> Built from source and tested keras-mxnet working fine.
>>> 
>>> Best Regards
>>> 
>>> Lai
>>> 
>>> 
>>> On Wed, May 1, 2019 at 4:22 PM Carin Meier 
 wrote:
>>> 
 + 1 (binding)
 
 Built Scala/ Clojure and ran tests
 
 On Wed, May 1, 2019 at 7:06 PM Aaron Markham <
>> aaron.s.mark...@gmail.com>
 wrote:
 
> Make that +1 (non-binding)
> 
> On Wed, May 1, 2019 at 3:42 PM Aaron Markham <
>>> aaron.s.mark...@gmail.com>
> wrote:
>> 
>> +1 (binding)
>> 
>> * Built with GPU and tested the first part of the ssd example.
>> * Built with GPU / cross-compiled to arm8 for Jetson.
>> * Built Scala/Java on top of the cross-compiled arm8 (ran into
>>> trouble
>> here, but I think this is not popular enough yet to derail
>> things,
>> plus there are workarounds)
>> * Built on CPU instance and tested docs.
>> http://34.201.8.176/versions/1.4.1/api/python/io/io.html
>> I don't see anything specific being different in this patch for
>> docs,
>> so hard to tell if there's an issue. I'll assume not given the
>> successful generation of the API docs.
>> 
>> 
>> On Wed, May 1, 2019 at 1:28 PM Pedro Larroy
>>  wrote:
>>> 
>>> +1 (non-binding)
>>> 
>>> Tried CPU build + C++ tests + 714 Python unit tests in 605s.
>>> ARMv7 build + small unit test in QEMU + ARMv8 builds.
>>> 
>>> Thanks. Regards
>>> 
>>> Pedro.
>>> 
>>> On Wed, May 1, 2019 at 10:41 AM Qing Lan 
 wrote:
 
 +1 (binding)
 
 build from source works for OSX and Ubuntu CPU
 Scala build/test successfully with Dynamic link and static
>> link.
 
 Thanks,
 Qing
 
 
 From: Sheng Zha 
 Sent: Wednesday, May 1, 2019 13:14
 To: d...@mxnet.apache.org
 Subject: Re: [VOTE] Release Apache MXNet (incubating) version
> 1.4.1.rc0
 
 Hi all,
 
 Reminder that the vote for 1.4.1 release is still ongoing. If
>> you
> can, please help out. Thank you.
 
 -sz
 
 On 2019/04/30 06:51:45, Junru Shao 
 wrote:
> Dear MXNet 

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

2019-05-03 Thread kellen sunderland
Hi Junru could you give a quick summary of the binding / non-binding votes.

Damien just want to confirm, are you a member of the PPMC for MXNet?
Usually committers or community members (like most of us) are encouraged to
test and vote, but technically count as non-binding for releases.

Sheng can we assume you're +1 on the release?

On Fri, May 3, 2019 at 12:09 AM Junru Shao  wrote:

> Hi folks,
>
> So far we have collected enough binding votes. Thank you guys for the hard
> work testing the release!
>
> The vote on dev@ is closed on May 02 23:59:59 (PST). Next, we are going to
> vote for the Apache MXNet (incubating) release 1.4.1 on general@ tomorrow,
> which starts on May 3 2019, 23:59:59 PST, and ends on May 07 2019, 23:59:59
> PST.
>
> Best,
> Junru
>
> On Thu, May 2, 2019 at 11:29 PM Aston Zhang  wrote:
>
> > +1 (non-binding)
> >
> > Passed all the code at zh.d2l.ai
> >
> > On Thu, May 2, 2019 at 1:46 PM Joshua Z. Zhang 
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > Build from source with cuda/cudnn.
> > >
> > > - All tests passed
> > > - GluonCV unittest scripts passed
> > > - GluonCV training scripts passed
> > > - No issue with python multiprocessing
> > >
> > > Best,
> > > Zhi
> > > > On May 2, 2019, at 11:34 AM, kellen sunderland <
> > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > > +1 (non-binding)
> > > >
> > > > I checked TRT integration builds and tests pass.
> > > > MD5s
> > > > Sigs look good.
> > > >
> > > > -Kellen
> > > >
> > > > On Thu, May 2, 2019 at 10:51 AM Damien Stanton <
> > damien.stan...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> +1 (binding)
> > > >>
> > > >> Built from source / Scala / Clojure. All tests pass. The only issue
> of
> > > >> minor note: The macOS build guide indicates a directive `brew
> install
> > > >> opencv` however this installs OpenCV 4, which is currently
> > incompatible
> > > >> with mxnet and causes a failed build. The guide should specify `brew
> > > >> install opencv@3` until/if version 4 is supported.
> > > >>
> > > >> Best,
> > > >> Damien
> > > >>
> > > >> On Thu, May 2, 2019 at 12:53 PM Lai Wei 
> wrote:
> > > >>
> > > >>> +1
> > > >>>
> > > >>> Built from source and tested keras-mxnet working fine.
> > > >>>
> > > >>> Best Regards
> > > >>>
> > > >>> Lai
> > > >>>
> > > >>>
> > > >>> On Wed, May 1, 2019 at 4:22 PM Carin Meier 
> > > wrote:
> > > >>>
> > >  + 1 (binding)
> > > 
> > >  Built Scala/ Clojure and ran tests
> > > 
> > >  On Wed, May 1, 2019 at 7:06 PM Aaron Markham <
> > > >> aaron.s.mark...@gmail.com>
> > >  wrote:
> > > 
> > > > Make that +1 (non-binding)
> > > >
> > > > On Wed, May 1, 2019 at 3:42 PM Aaron Markham <
> > > >>> aaron.s.mark...@gmail.com>
> > > > wrote:
> > > >>
> > > >> +1 (binding)
> > > >>
> > > >> * Built with GPU and tested the first part of the ssd example.
> > > >> * Built with GPU / cross-compiled to arm8 for Jetson.
> > > >> * Built Scala/Java on top of the cross-compiled arm8 (ran into
> > > >>> trouble
> > > >> here, but I think this is not popular enough yet to derail
> things,
> > > >> plus there are workarounds)
> > > >> * Built on CPU instance and tested docs.
> > > >> http://34.201.8.176/versions/1.4.1/api/python/io/io.html
> > > >> I don't see anything specific being different in this patch for
> > > >> docs,
> > > >> so hard to tell if there's an issue. I'll assume not given the
> > > >> successful generation of the API docs.
> > > >>
> > > >>
> > > >> On Wed, May 1, 2019 at 1:28 PM Pedro Larroy
> > > >>  wrote:
> > > >>>
> > > >>> +1 (non-binding)
> > > >>>
> > > >>> Tried CPU build + C++ tests + 714 Python unit tests in 605s.
> > > >>> ARMv7 build + small unit test in QEMU + ARMv8 builds.
> > > >>>
> > > >>> Thanks. Regards
> > > >>>
> > > >>> Pedro.
> > > >>>
> > > >>> On Wed, May 1, 2019 at 10:41 AM Qing Lan 
> > >  wrote:
> > > 
> > >  +1 (binding)
> > > 
> > >  build from source works for OSX and Ubuntu CPU
> > >  Scala build/test successfully with Dynamic link and static
> > > >> link.
> > > 
> > >  Thanks,
> > >  Qing
> > > 
> > >  
> > >  From: Sheng Zha 
> > >  Sent: Wednesday, May 1, 2019 13:14
> > >  To: d...@mxnet.apache.org
> > >  Subject: Re: [VOTE] Release Apache MXNet (incubating) version
> > > > 1.4.1.rc0
> > > 
> > >  Hi all,
> > > 
> > >  Reminder that the vote for 1.4.1 release is still ongoing. If
> > > >> you
> > > > can, please help out. Thank you.
> > > 
> > >  -sz
> > > 
> > >  On 2019/04/30 06:51:45, Junru Shao 
> > >  wrote:
> > > > Dear MXNet community,
> > > >
> > > > This is the 3-day vote to release Apache MXNet (incubating)
> > > > version v1.4.1.
> 

Re: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread Sheng Zha
Hi Konstantin,

While conan looks like an option that's worth exploring, given that your 
request is to merge the pull request, I'd suggest that the request should go 
through the regular pull request review and it doesn't really need a vote (as 
it doesn't substitute reviews anyway)

If you would like to gather more attention to it, feel free to ping in a 
discussion thread.

-sz

On 2019/05/03 06:29:55, Konstantin Ivlev  wrote: 
> Dear MXNet community,
> 
> This is the 3-day vote to add conan support for Apache MXNet (incubating)
> version v1.4.1.
> The voting on dev@ list will start May 03 23:59:59 (PST) and close on May
> 06 23:59:59.
> 
> Background: conan is open-source, freeware, cross-platform package manager
> for C and C++ projects, written in python. it provides integration with
> various build systems, include CMake. conan may use bintray as a server to
> store and download pre-built packages, or packages might be always built
> from sources.
> 
> Problem: currently (as for v1.4.1), Apache MXNet (incubating) is using
> several ways to fetch 3rd-party dependencies simultaneously, for instance:
> 1. download GitHub archives during the build
> - OpenBLAS
> - OpenCV
> 2. conda (alternative way to GitHub archives)
> 3. download from CMake
> - Intel Math Kernel Library (MKL)
> 4. Git submodules
> - cub
> - dlpack
> - dmlc-core
> - googletest
> - mkldnn
> - mshadow
> - onnx-tensorrt
> - openmp
> - ps-lite
> - tvm
> therefore, there are multiple places to look for 3rd parties, and its hard
> to update them, as you need to remember or figure it out how to update a
> particular dependency to newer version, for instance.
> current Apache MXNet (incubating) build instructions differ very much per
> platform, require to download and unzip some archives manually, specifying
> variables with paths to this archives, in conjunction of updating git
> submodules,
> 
> Action: merge pull request providing an initial conan support for Apache
> MXNet (incubating). support conan as an alternate approach to fetch various
> 3rd-party dependencies. old approaches will be still available, supported
> and left intact.
> 
> Below are links to
> 1) conan web-site:  https://conan.io/
> 2) conan GitHub repository: https://github.com/conan-io/conan
> 3) conan documentation: https://docs.conan.io/en/latest/
> 4) bintray: https://bintray.com
> 5) pull request adding conan support to Apache MXNet (incubating):
> https://github.com/apache/incubator-mxnet/pull/13400
> 6) JIRA issue: https://issues.apache.org/jira/browse/MXNET-1229
> 7) previous email discussion:
> https://lists.apache.org/thread.html/301a46a637f7e3c249c475713f701bef7530c32bc92d8834c0882897@%3Cdev.mxnet.apache.org%3E
> 8) MXNet build instructions:
> https://mxnet-tqchen.readthedocs.io/en/latest/how_to/build.html
> 9) MXNet build instructions (Windows):
> https://mxnet.incubator.apache.org/versions/master/install/windows_setup.html
> 10) MXNet build instructions (OSX):
> http://mxnet.incubator.apache.org/versions/master/install/osx_setup.html
> 11) MXNet build instructions (Linux):
> http://mxnet.incubator.apache.org/versions/master/install/ubuntu_setup.html
> 12) MXNet development setup (OSX):
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac
> 
> Please remember to TEST first before voting accordingly:
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
> 
> Best regards,
> Konstantin Ivlev
> 


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

2019-05-03 Thread Junru Shao
Hi folks,

So far we have collected enough binding votes. Thank you guys for the hard
work testing the release!

The vote on dev@ is closed on May 02 23:59:59 (PST). Next, we are going to
vote for the Apache MXNet (incubating) release 1.4.1 on general@ tomorrow,
which starts on May 3 2019, 23:59:59 PST, and ends on May 07 2019, 23:59:59
PST.

Best,
Junru

On Thu, May 2, 2019 at 11:29 PM Aston Zhang  wrote:

> +1 (non-binding)
>
> Passed all the code at zh.d2l.ai
>
> On Thu, May 2, 2019 at 1:46 PM Joshua Z. Zhang 
> wrote:
>
> > +1 (non-binding)
> >
> > Build from source with cuda/cudnn.
> >
> > - All tests passed
> > - GluonCV unittest scripts passed
> > - GluonCV training scripts passed
> > - No issue with python multiprocessing
> >
> > Best,
> > Zhi
> > > On May 2, 2019, at 11:34 AM, kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> > >
> > > +1 (non-binding)
> > >
> > > I checked TRT integration builds and tests pass.
> > > MD5s
> > > Sigs look good.
> > >
> > > -Kellen
> > >
> > > On Thu, May 2, 2019 at 10:51 AM Damien Stanton <
> damien.stan...@gmail.com
> > >
> > > wrote:
> > >
> > >> +1 (binding)
> > >>
> > >> Built from source / Scala / Clojure. All tests pass. The only issue of
> > >> minor note: The macOS build guide indicates a directive `brew install
> > >> opencv` however this installs OpenCV 4, which is currently
> incompatible
> > >> with mxnet and causes a failed build. The guide should specify `brew
> > >> install opencv@3` until/if version 4 is supported.
> > >>
> > >> Best,
> > >> Damien
> > >>
> > >> On Thu, May 2, 2019 at 12:53 PM Lai Wei  wrote:
> > >>
> > >>> +1
> > >>>
> > >>> Built from source and tested keras-mxnet working fine.
> > >>>
> > >>> Best Regards
> > >>>
> > >>> Lai
> > >>>
> > >>>
> > >>> On Wed, May 1, 2019 at 4:22 PM Carin Meier 
> > wrote:
> > >>>
> >  + 1 (binding)
> > 
> >  Built Scala/ Clojure and ran tests
> > 
> >  On Wed, May 1, 2019 at 7:06 PM Aaron Markham <
> > >> aaron.s.mark...@gmail.com>
> >  wrote:
> > 
> > > Make that +1 (non-binding)
> > >
> > > On Wed, May 1, 2019 at 3:42 PM Aaron Markham <
> > >>> aaron.s.mark...@gmail.com>
> > > wrote:
> > >>
> > >> +1 (binding)
> > >>
> > >> * Built with GPU and tested the first part of the ssd example.
> > >> * Built with GPU / cross-compiled to arm8 for Jetson.
> > >> * Built Scala/Java on top of the cross-compiled arm8 (ran into
> > >>> trouble
> > >> here, but I think this is not popular enough yet to derail things,
> > >> plus there are workarounds)
> > >> * Built on CPU instance and tested docs.
> > >> http://34.201.8.176/versions/1.4.1/api/python/io/io.html
> > >> I don't see anything specific being different in this patch for
> > >> docs,
> > >> so hard to tell if there's an issue. I'll assume not given the
> > >> successful generation of the API docs.
> > >>
> > >>
> > >> On Wed, May 1, 2019 at 1:28 PM Pedro Larroy
> > >>  wrote:
> > >>>
> > >>> +1 (non-binding)
> > >>>
> > >>> Tried CPU build + C++ tests + 714 Python unit tests in 605s.
> > >>> ARMv7 build + small unit test in QEMU + ARMv8 builds.
> > >>>
> > >>> Thanks. Regards
> > >>>
> > >>> Pedro.
> > >>>
> > >>> On Wed, May 1, 2019 at 10:41 AM Qing Lan 
> >  wrote:
> > 
> >  +1 (binding)
> > 
> >  build from source works for OSX and Ubuntu CPU
> >  Scala build/test successfully with Dynamic link and static
> > >> link.
> > 
> >  Thanks,
> >  Qing
> > 
> >  
> >  From: Sheng Zha 
> >  Sent: Wednesday, May 1, 2019 13:14
> >  To: d...@mxnet.apache.org
> >  Subject: Re: [VOTE] Release Apache MXNet (incubating) version
> > > 1.4.1.rc0
> > 
> >  Hi all,
> > 
> >  Reminder that the vote for 1.4.1 release is still ongoing. If
> > >> you
> > > can, please help out. Thank you.
> > 
> >  -sz
> > 
> >  On 2019/04/30 06:51:45, Junru Shao 
> >  wrote:
> > > Dear MXNet community,
> > >
> > > This is the 3-day vote to release Apache MXNet (incubating)
> > > version v1.4.1.
> > > The voting on dev@ list will start Apr 29 23:59:59 (PST) and
> > > close on May
> > > 02 23:59:59.
> > >
> > > Below are links to
> > > 1) Release notes:
> > >
> > >
> > 
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.1+Release+Notes
> > > .
> > > 2) Release Candidate:
> > >
> > >>> https://github.com/apache/incubator-mxnet/releases/tag/1.4.1.rc0
> >  .
> > > 3) Source and signatures on Apache dist server:
> > >
> >  https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.1.rc0/.
> > >
> > > 

[VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread Konstantin Ivlev
Dear MXNet community,

This is the 3-day vote to add conan support for Apache MXNet (incubating)
version v1.4.1.
The voting on dev@ list will start May 03 23:59:59 (PST) and close on May
06 23:59:59.

Background: conan is open-source, freeware, cross-platform package manager
for C and C++ projects, written in python. it provides integration with
various build systems, include CMake. conan may use bintray as a server to
store and download pre-built packages, or packages might be always built
from sources.

Problem: currently (as for v1.4.1), Apache MXNet (incubating) is using
several ways to fetch 3rd-party dependencies simultaneously, for instance:
1. download GitHub archives during the build
- OpenBLAS
- OpenCV
2. conda (alternative way to GitHub archives)
3. download from CMake
- Intel Math Kernel Library (MKL)
4. Git submodules
- cub
- dlpack
- dmlc-core
- googletest
- mkldnn
- mshadow
- onnx-tensorrt
- openmp
- ps-lite
- tvm
therefore, there are multiple places to look for 3rd parties, and its hard
to update them, as you need to remember or figure it out how to update a
particular dependency to newer version, for instance.
current Apache MXNet (incubating) build instructions differ very much per
platform, require to download and unzip some archives manually, specifying
variables with paths to this archives, in conjunction of updating git
submodules,

Action: merge pull request providing an initial conan support for Apache
MXNet (incubating). support conan as an alternate approach to fetch various
3rd-party dependencies. old approaches will be still available, supported
and left intact.

Below are links to
1) conan web-site:  https://conan.io/
2) conan GitHub repository: https://github.com/conan-io/conan
3) conan documentation: https://docs.conan.io/en/latest/
4) bintray: https://bintray.com
5) pull request adding conan support to Apache MXNet (incubating):
https://github.com/apache/incubator-mxnet/pull/13400
6) JIRA issue: https://issues.apache.org/jira/browse/MXNET-1229
7) previous email discussion:
https://lists.apache.org/thread.html/301a46a637f7e3c249c475713f701bef7530c32bc92d8834c0882897@%3Cdev.mxnet.apache.org%3E
8) MXNet build instructions:
https://mxnet-tqchen.readthedocs.io/en/latest/how_to/build.html
9) MXNet build instructions (Windows):
https://mxnet.incubator.apache.org/versions/master/install/windows_setup.html
10) MXNet build instructions (OSX):
http://mxnet.incubator.apache.org/versions/master/install/osx_setup.html
11) MXNet build instructions (Linux):
http://mxnet.incubator.apache.org/versions/master/install/ubuntu_setup.html
12) MXNet development setup (OSX):
https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac

Please remember to TEST first before voting accordingly:
+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)

Best regards,
Konstantin Ivlev


Fwd: [VOTE] add conan support for Apache MXNet (incubating)

2019-05-03 Thread Konstantin Ivlev
Dear MXNet community,

This is the 3-day vote to add conan support for Apache MXNet (incubating)
version v1.4.1.
The voting on dev@ list will start May 03 23:59:59 (PST) and close on May
06 23:59:59.

Background: conan is open-source, freeware, cross-platform package manager
for C and C++ projects, written in python. it provides integration with
various build systems, include CMake. conan may use bintray as a server to
store and download pre-built packages, or packages might be always built
from sources.

Problem: currently (as for v1.4.1), Apache MXNet (incubating) is using
several ways to fetch 3rd-party dependencies simultaneously, for instance:
1. download GitHub archives during the build
- OpenBLAS
- OpenCV
2. conda (alternative way to GitHub archives)
3. download from CMake
- Intel Math Kernel Library (MKL)
4. Git submodules
- cub
- dlpack
- dmlc-core
- googletest
- mkldnn
- mshadow
- onnx-tensorrt
- openmp
- ps-lite
- tvm
therefore, there are multiple places to look for 3rd parties, and its hard
to update them, as you need to remember or figure it out how to update a
particular dependency to newer version, for instance.
current Apache MXNet (incubating) build instructions differ very much per
platform, require to download and unzip some archives manually, specifying
variables with paths to this archives, in conjunction of updating git
submodules,

Action: merge pull request providing an initial conan support for Apache
MXNet (incubating). support conan as an alternate approach to fetch various
3rd-party dependencies. old approaches will be still available, supported
and left intact.

Below are links to
1) conan web-site:  https://conan.io/
2) conan GitHub repository: https://github.com/conan-io/conan
3) conan documentation: https://docs.conan.io/en/latest/
4) bintray: https://bintray.com
5) pull request adding conan support to Apache MXNet (incubating):
https://github.com/apache/incubator-mxnet/pull/13400
6) JIRA issue: https://issues.apache.org/jira/browse/MXNET-1229
7) previous email discussion:
https://lists.apache.org/thread.html/301a46a637f7e3c249c475713f701bef7530c32bc92d8834c0882897@%3Cdev.mxnet.apache.org%3E
8) MXNet build instructions:
https://mxnet-tqchen.readthedocs.io/en/latest/how_to/build.html
9) MXNet build instructions (Windows):
https://mxnet.incubator.apache.org/versions/master/install/windows_setup.html
10) MXNet build instructions (OSX):
http://mxnet.incubator.apache.org/versions/master/install/osx_setup.html
11) MXNet build instructions (Linux):
http://mxnet.incubator.apache.org/versions/master/install/ubuntu_setup.html
12) MXNet development setup (OSX):
https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac

Please remember to TEST first before voting accordingly:
+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)

Best regards,
Konstantin Ivlev


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

2019-05-03 Thread Aston Zhang
+1 (non-binding)

Passed all the code at zh.d2l.ai

On Thu, May 2, 2019 at 1:46 PM Joshua Z. Zhang  wrote:

> +1 (non-binding)
>
> Build from source with cuda/cudnn.
>
> - All tests passed
> - GluonCV unittest scripts passed
> - GluonCV training scripts passed
> - No issue with python multiprocessing
>
> Best,
> Zhi
> > On May 2, 2019, at 11:34 AM, kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
> >
> > +1 (non-binding)
> >
> > I checked TRT integration builds and tests pass.
> > MD5s
> > Sigs look good.
> >
> > -Kellen
> >
> > On Thu, May 2, 2019 at 10:51 AM Damien Stanton  >
> > wrote:
> >
> >> +1 (binding)
> >>
> >> Built from source / Scala / Clojure. All tests pass. The only issue of
> >> minor note: The macOS build guide indicates a directive `brew install
> >> opencv` however this installs OpenCV 4, which is currently incompatible
> >> with mxnet and causes a failed build. The guide should specify `brew
> >> install opencv@3` until/if version 4 is supported.
> >>
> >> Best,
> >> Damien
> >>
> >> On Thu, May 2, 2019 at 12:53 PM Lai Wei  wrote:
> >>
> >>> +1
> >>>
> >>> Built from source and tested keras-mxnet working fine.
> >>>
> >>> Best Regards
> >>>
> >>> Lai
> >>>
> >>>
> >>> On Wed, May 1, 2019 at 4:22 PM Carin Meier 
> wrote:
> >>>
>  + 1 (binding)
> 
>  Built Scala/ Clojure and ran tests
> 
>  On Wed, May 1, 2019 at 7:06 PM Aaron Markham <
> >> aaron.s.mark...@gmail.com>
>  wrote:
> 
> > Make that +1 (non-binding)
> >
> > On Wed, May 1, 2019 at 3:42 PM Aaron Markham <
> >>> aaron.s.mark...@gmail.com>
> > wrote:
> >>
> >> +1 (binding)
> >>
> >> * Built with GPU and tested the first part of the ssd example.
> >> * Built with GPU / cross-compiled to arm8 for Jetson.
> >> * Built Scala/Java on top of the cross-compiled arm8 (ran into
> >>> trouble
> >> here, but I think this is not popular enough yet to derail things,
> >> plus there are workarounds)
> >> * Built on CPU instance and tested docs.
> >> http://34.201.8.176/versions/1.4.1/api/python/io/io.html
> >> I don't see anything specific being different in this patch for
> >> docs,
> >> so hard to tell if there's an issue. I'll assume not given the
> >> successful generation of the API docs.
> >>
> >>
> >> On Wed, May 1, 2019 at 1:28 PM Pedro Larroy
> >>  wrote:
> >>>
> >>> +1 (non-binding)
> >>>
> >>> Tried CPU build + C++ tests + 714 Python unit tests in 605s.
> >>> ARMv7 build + small unit test in QEMU + ARMv8 builds.
> >>>
> >>> Thanks. Regards
> >>>
> >>> Pedro.
> >>>
> >>> On Wed, May 1, 2019 at 10:41 AM Qing Lan 
>  wrote:
> 
>  +1 (binding)
> 
>  build from source works for OSX and Ubuntu CPU
>  Scala build/test successfully with Dynamic link and static
> >> link.
> 
>  Thanks,
>  Qing
> 
>  
>  From: Sheng Zha 
>  Sent: Wednesday, May 1, 2019 13:14
>  To: d...@mxnet.apache.org
>  Subject: Re: [VOTE] Release Apache MXNet (incubating) version
> > 1.4.1.rc0
> 
>  Hi all,
> 
>  Reminder that the vote for 1.4.1 release is still ongoing. If
> >> you
> > can, please help out. Thank you.
> 
>  -sz
> 
>  On 2019/04/30 06:51:45, Junru Shao 
>  wrote:
> > Dear MXNet community,
> >
> > This is the 3-day vote to release Apache MXNet (incubating)
> > version v1.4.1.
> > The voting on dev@ list will start Apr 29 23:59:59 (PST) and
> > close on May
> > 02 23:59:59.
> >
> > Below are links to
> > 1) Release notes:
> >
> >
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.1+Release+Notes
> > .
> > 2) Release Candidate:
> >
> >>> https://github.com/apache/incubator-mxnet/releases/tag/1.4.1.rc0
>  .
> > 3) Source and signatures on Apache dist server:
> >
>  https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.1.rc0/.
> >
> > Please remember to TEST first before voting accordingly:
> > +1 = approve
> > +0 = no opinion
> > -1 = disapprove (provide reason)
> >
> > Best regards,
> > Junru Shao
> >
> >
> 
> >>>
> >>
>
>