Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Joshua Z. Zhang]

+1 binding.

Tested

- build
- gluoncv unittests
- gluoncv training examples

Best,
Zhi

> On Jul 22, 2020, at 12:30 AM, Tao Lv  wrote:
> 
> +1 (binding)
> 
> 
> 
> - Untar the source code package;
> 
> - Build from source code with makefile, USE_BLAS=mkl, USE_MKLDNN=1;
> 
> - Check mx.__version__;
> 
> - Run benchmark_score.py under examples/image-classification.
> 
> On Wed, Jul 22, 2020 at 3:13 PM Patrick Mu  wrote:
> 
>> + 1
>> 
>> Test custom operators: all examples using custom operators are passing, no
>> error or regression found
>> 
>> Ziyi
>> 
>> On 2020/07/22 06:56:46, Kshitij Kalambarkar 
>> wrote:
>>> + 1
>>> 
>>> * Built from source on Ubuntu 18.04 with CUDA, CUDNN
>>> * Verified test_higher_order_grad.py
>>> 
>>> Great job!
>>> 
>>> On Wed, Jul 22, 2020 at 12:02 PM Chaitanya Bapat 
>>> wrote:
>>> 
 +1
 
 - Built from source on Ubuntu18 with CUDA ON, USE_INT64_TENSOR_SIZE ON
 - Verified large tensor tests work as expected on a p3.16xl instance
>> [with
 8 Tesla V100 GPUs]
 - Verified OpPerf utility works as expected.
 
 Steps followed:
 https://gist.github.com/ChaiBapchya/8a5131932693d4ca47281368c752b726
 
 Thanks Ciyong for leading with the releases. Incredible job.
 
 Regards,
 Chai
 
 
 On Tue, 21 Jul 2020 at 23:05, Karan Jariwala >> 
 wrote:
 
> +1
> 
> Build from source on Ubuntu 18 with CUDA/CUDNN/NCCL ON and verified
>> with
> Horovod 0.19.5 by running unittest and integration tests.
> 
> Thanks,
> Karan
> 
> On Tue, Jul 21, 2020 at 10:23 PM Sheng Zha 
>> wrote:
> 
>> +1. I checked:
>> 
>> [x] Are release files in correct location? Yes
>> [x] Do release files have the word incubating in their name? Yes
>> [x] Are the digital signature and hashes correct? Yes
>> [x] Does DISCLAIMER file exist? Yes, DISCLAIMER-WIP
>> [x] Do LICENSE and NOTICE files exists? Yes
>> [x] Is the LICENSE and NOTICE text correct?
>> Yes, though the license still reads "Copyright [] [name of
 copyright
>> owner]", which needs correction.
>> 
>> [x] Is the NOTICE year correct? Yes
>> [x] Un-included software dependencies are not mentioned in LICENSE
>> or
>> NOTICE?
>> No. mshadow is now contributed to MXNet via software grant and
>> should
 be
>> removed from NOTICE.
>> 
>> [x] License information is not mentioned in NOTICE? Confirmed
>> 
>> Is there any 3rd party code contained inside the release? If so:
>> [x] Does the software have a compatible license? Yes. Minor issue:
>> Dual license in cmake/Modules/FindJeMalloc.cmake.
>> 
>> [x] Are all software licenses mentioned in LICENSE? Yes
>> [x] Is the full text of the licenses (or pointers to it) in
>> LICENSE?
 Yes
>> 
>> Is any of this code Apache licensed? Do they have NOTICE files? If
>> so:
>> [x] Have relevant parts of those NOTICE files been added to this
>> NOTICE
>> file?
>> No. TVM NOTICE file hasn't been included.
>> 
>> [x] Do all source files have ASF headers?
>> Yes, except those in 3rdparty folder and those mentioned in
>> license.
>> [x] Do the contents of the release match with what's tagged in
>> version
>> control? Yes
>> [x] Are there any unexpected binary files in the release? No
>> [x] Can you compile from source? Are the instruction clear? Yes,
 Makefile
>> is present and is straightforward.
>> Is the issue minor? Yes
>> Could it possibly be fixed in the next release? Yes
>> 
>> I vote with:
>> [x] +1 release the software
>> 
>> 
>> On 2020/07/20 17:25:50, "Skalicky, Sam" >> 
>> wrote:
>>> +1
>>> 
>>> Tested:
>>> - Make flow building from source, verified all
>> example/extensions/*
> work
>> correctly
>>> - staticbuild flow cpu & cu102 variants producing the pip wheels,
> tested
>> with custom extension library
>>> 
>>> Sam
>>> 
>>> On 7/20/20, 4:07 AM, "Chen, Ciyong" 
>> wrote:
>>> 
>>>CAUTION: This email originated from outside of the
>> organization.
 Do
>> not click links or open attachments unless you can confirm the
>> sender
 and
>> know the content is safe.
>>> 
>>> 
>>> 
>>>Thanks Aston, Patric for the vote.
>>> 
>>>Hi Community,
>>> 
>>>I would like to call for action to test/validate/vote for the
>> release candidate (1.7.0.rc1).
>>>As we've not reached the quorum, I would like to extend the
 voting
>> process to July 22, 23:59:59 PST.
>>>Please prepare your time and provide feedback if you've tried
 with
>> the pre-released code base, thanks!
>>> 
>>>Best Regards,
>>>Ciyong
>>> 
>>>-Original Message-
>>>From: Zhao, Patric 
>>>Sent: Monday, July 20, 2020 11:36 AM
>>>To: 

Re: [apache/incubator-mxnet] [mxnet 2.0][item 4.8][RFC] Gluon Data API Extension and Fixes(Part 2) (#17269)

[Joshua Z. Zhang]

Closed #17269.

-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17269#event-3329858545

Re: [apache/incubator-mxnet] [mxnet 2.0][item 4.8][RFC] Gluon Data API Extension and Fixes(Part 2) (#17269)

[Joshua Z. Zhang]

closed by #17841 

-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17269#issuecomment-627676975

Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 API Deprecation (#17676)

[Joshua Z. Zhang]

In the long run, gluon vision model zoo will be maintained in GluonCV and 
therefore mxnet.gluon.vision.model_zoo should be deprecated to avoid duplicate 
maintenance efforts in 2.0

-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-613682982

Re: [apache/incubator-mxnet] [mxnet 2.0][item 4.8][RFC] Gluon Data API Extension and Fixes(Part 2) (#17269)

[Joshua Z. Zhang]

@szha @eric-haibin-lin @sxjscience @szhengac Request for comments regarding NLP 
dataloading

-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17269#issuecomment-573242957

[apache/incubator-mxnet] [mxnet 2.0][item 4.8][RFC] Gluon Data API Extension and Fixes(Part 2) (#17269)

[Joshua Z. Zhang]

## Description
This is the part 2 of Gluon Data API extension and fixes, which mainly focus on 
speed up the current data loading pipeline using gluon dataset and dataloader.

## Motivation

The current data loading pipeline is the major bottleneck for many training 
tasks. We can summarize the entire flow as:

```bash
| Dataset.__getitem__ -> 
| Transform.__call__()/forward() ->
| Batchify ->
| (optional communicate through shared_mem) ->
| split_and_load(ctxs) ->
| 
-> 
```
where there are performance concerns:
- performance of python dataset/transform functions aren't satisfying
- it's not easy to embrace multithreading to speed up dataloading due to global 
interpreter lock
- python multiprocessing is unfortunately slow and error prune, not to mention 
the shared memory implementations on different OS are quite difference and very 
annoying(e.g., it's very likely to run out of shared memory if not properly 
taken care of)
- currently memory planing for batchify is non-exist, causing frequent 
alloc/dealloc for large chunk of memory if the batch size is big
- batchify then split and load can be optimized to partial_batchify

## Proposal
To alleviate the existing troubles I propose to use a hybrid solution, that is 
to 
- provide C++ Datasets that can cover the most usecases
```python
from gluon.data.dataset import TupleDataset, ImageFolderDataset, 
ArrayDataset
# as long as TupleDataset, ImageSequenceDataset, ArrayDataset are supported 
by backend
dataset = TupleDataset([ImageSequenceDataset(img_paths), 
ArrayDataset(image_labels)])
# dataset is an image classification dataset while fully supported in C++
# with TupleDataset we can combine as many data as possible

# a C++ backed Dataset can have a magic __handle__ method to return the c++ 
handle for reference
class TupleDataset:
def __init__(self, datasets):
if all([callable(getattr(dataset, '__handle__')) for dataset in 
datasets]):
# all supported by backend
self._tuple_dataset = 
check_call(_LIB.MXTupleDatasetCreate([getattr(dataset, '__handle__') for 
dataset in datasets]))
else:
self._tuple_dataset = None

def __handle__(self):
return self._tuple_dataset

```
- provide common C++ batchify functions that are split and context aware. 
Batchify with memory planner is TBD.
- provide a C++ `MultithreadingDataLoader` which inherit the same arguments as 
`gluon.data.DataLoader` but use mxnet internal multithreading rather than 
python multiprocessing.
- fallback to python multiprocessing whenever 
- the dataset is not fully supported by backend(e.g., there are custom 
python datasets)
- Transform is not fully hybridizable
- Batchify is not fully supported by backend

User will continue to use the existing `gluon.data.DataLoader`, and the 
conversion will be applied automatically
```python

loader = gluon.data.DataLoader(hybrid_dataset.transform(hybrid_transform), 
batch_size=32, batchify_fn=hybrid_batchify)

def DataLoader:
def __init__(self, dataset, ...):
if isinstance(dataset, _LazyTransformDataset) and 
is_hybrid(dataset._transform) and is_hybrid(dataset) and is_hybrid(batchify_fn):
self._mt_dataloader = 
check_call(_LIB.MXMultiThreadDataLoaderCreate(...))
def __iter__(self):
if self._mt_dataloader:
return self._mt_dataloader
else:
   # fallback to single thread normal dataloader or multiprocessing 
dataloader

```

With this change, mxnet 2.0 will get smooth transition to mixed data loaders. 
Please comment with specific examples where this proposal fail to accommodate.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17269

[apache/incubator-mxnet] [mxnet 2.0][item 4.8][RFC] Gluon Data API Extension and Fixes(Part 1) (#17263)

[Joshua Z. Zhang]

## Description

This is the part 1 of Gluon Data API extension and fixes, which mainly focus on 
cleaning up diverging usage of mxnet module/gluon.
Through long time evolution, there's currently two streams of data loading 
conventions implemented in mxnet
- Iterator: 
mxnet.io.DataIter(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/io/io.py#L180)
- Dataset + DataLoader: gluon.data.Dataset + gluon.data.DataLoader

In order to eliminate the confusion here and to reduce the maintenance efforts, 
the plan is to drop all old iterators and provide similar Dataset + Dataloader 
experience in gluon data API. 
## Things to be removed

### iterators
- Base 
mxnet.io.DataIter(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/io/io.py#L180)
- 
mxnet.io.ResizeIter(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/io/io.py#L282)
- 
mxnet.io.PrefetchIter(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/io/io.py#L347)
- 
mxnet.io.NDArrayIter(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/io/io.py#L491)
- 
mxnet.io.MXDataIter(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/io/io.py#L800)
- 
mxnet.image.ImageIter(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/image/detection.py#L626)
- 
mxnet.image.ImageDetIter(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/image/detection.py#L626)

### Augmenters from mxnet.image and mxnet.image.detection module

Random augmenters, e.g. 
(https://github.com/apache/incubator-mxnet/blob/ac88f1e87aa7da2c33f0cb89524d444ddc3a2ae8/python/mxnet/image/image.py#L615)
 will be removed.

### Transform = args in gluon.data.Datasets

transform = is no longer supported, and can be replaced with 
`dataset.transform` or `dataset.transform_first`

## Things to be added

### Gluon Data Datasets

Dataset + Transfrom combo that simulate the removed Iterators

For example, NDArrayIter can be reimplemented as NDArrayDataset + empty 
transform function.

### Gluon Data Augmentaters/Transforms

Data augmenters as mxnet.gluon.Block

Candidates TBD, useful candidates from 
GluonCV(https://github.com/dmlc/gluon-cv/tree/master/gluoncv/data/transforms) 
and 
GluonNLP(https://github.com/dmlc/gluon-nlp/blob/v0.8.x/src/gluonnlp/data/transforms.py)

### mxnet.image

image processing functions will be absorbed from 
GluonCV(https://github.com/dmlc/gluon-cv/blob/master/gluoncv/data/transforms/image.py)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17263

Re: Stopping nightly releases to Pypi

[Joshua Z. Zhang]

Separating the nightly wheels from PYPI certainly can reduce our turnaround 
time for processing new packages, overall I am in favor of this proposal.

However, one question is that would external private server causing problems 
when you are trying to pin a nightly version of MXNet in Conda pip environment?

For example, GluonCV heavily rely on nightly builds of mxnet in CI 
(https://github.com/dmlc/gluon-cv/blob/master/docs/build.yml#L12 
) and I know 
conda has bad reputation in response to pip installation options: 
https://github.com/conda/conda/issues/6805 


Thanks,
Zhi

> On Dec 1, 2019, at 11:14 PM, Lausen, Leonard  
> wrote:
> 
>> For the d2l.ai case, bugs within MXNet are fine, so long as users are sent to
>> a pinned version that corresponds to the notebooks that are created for it.
> 
> I'm not sure if this approach provides the best user-experience. Ideally we
> would like d2l users to continue using MXNet after going through the book. But
> such adoption could be limited if readers run into bugs due to usage of an old
> (pinned) nightly version when they begin to use more advanced features (not
> included in / tested by the book).
> 
> It seems preferable to have novice users to use a carefully vetted version of
> MXNet. Such version could be easily obtained by backporting the new operators 
> to
> the latest stable release, and tagging a release candidate for a new stable
> minor release. We can set up a pipeline to automatically build such release
> candidates to Pypi?
> 
> But if that's not an option, including the link could be fine as long as users
> can copy-and-paste it. It seems we may expect copy-and-paste ability for the
> online version of the book. What do you think? Arguably any printed version
> should not rely on nightly releases.
> 
> Best regards
> Leonard
> 
> On Mon, 2019-12-02 at 06:13 +, Chung, Alex wrote:
>> For the d2l.ai case, bugs within MXNet are fine, so long as users are sent to
>> a pinned version that corresponds to the notebooks that are created for it. I
>> suppose we can once again provide the whole link, but getting directly from
>> pip is the familiar experience for most devs.
>> 
>> Yes, 1.6 is the target release, but I don't see a world where the team can
>> create new operators, and then get it pushed out to stable fast enough for 
>> the
>> book writers.
>> 
>> Sincerely,
>> 
>> Alex Chung
>> 
>> 
>> From: Lausen, Leonard 
>> Sent: Sunday, December 1, 2019 10:08 PM
>> To: dev@mxnet.incubator.apache.org
>> Cc: Kamakoti, Balaji
>> Subject: Re: Stopping nightly releases to Pypi
>> 
>> If we decide to do weekly pre-release builds to Pypi, what's the benefit? To
>> catch bugs and pinpoint when they were introduced, having weekly builds may 
>> be
>> too coarse. So people would likely prefer the nightly releases and install
>> them
>> from S3 via: pip install --pre mxnet-cu101 -f
>> http://mxnet.s3.amazonaws.com/mxnet-cu101/nightly.html
>> 
>> For any future project that relies on nightly builds of MXNet 1.7 (or later),
>> we
>> can include above line. (Similar to the Install instructions on pytorch.org 
>> if
>> you select "Nightly" and "Pip").
>> 
>> For existing projects, which taught users to use "pip install --pre mxnet-
>> cu101"
>> to get the MXNet 1.6 pre-release: There is no problem, because we will have a
>> stable release of 1.6 in the near future.
>> Based on my understanding, d2l.ai currently targets the MXNet 1.6 release.
>> 
>> On Mon, 2019-12-02 at 05:51 +, Chung, Alex wrote:
>>> Hi Leonard,
>>> 
>>> Is there any reason why we shouldn't take both options? Ie we do weekly
>>> build
>>> on PyPi and provide the s3 option. I would be inclined to make sure we
>>> provide
>>> as many avenues as possible to reduce friction for developers. The d2l.ai
>>> book
>>> by Alex Smola is attracting a community that so far has been relying on the
>>> nightly builds in advance of stable.
>>> 
>>> Sincerely,
>>> 
>>> Alex Chung
>>> 
>>> 
>>> From: Lausen, Leonard 
>>> Sent: Sunday, December 1, 2019 9:42 PM
>>> To: d...@mxnet.apache.org
>>> Subject: Stopping nightly releases to Pypi
>>> 
>>> Hi MXNet Community,
>>> 
>>> since more than 2 months our binary Python nightly releases published on
>>> Pypi
>>> are broken. The problem is that our binaries exceed Pypi's size limit.
>>> Decreasing the binary size by adding compression breaks third-party
>>> libraries
>>> loading libmxnet.so https://github.com/apache/incubator-mxnet/issues/16193
>>> 
>>> Sheng requested Pypi to increase their size limit:
>>> https://github.com/pypa/pypi-support/issues/50
>>> 
>>> Currently "the biggest cost for PyPI from [the many MXNet binaries with
>>> nightly
>>> release to Pypi] is the bandwidth consumed when several hundred mirrors
>>> attempt
>>> to mirror each release immediately after 

Re: new website, docs code freeze

[Joshua Z. Zhang]

I’ve heard existing users are in general happy with the new site’s modern 
appearance.

The biggest issue is that the search bar is now hidden way too deep in the 
python api page, where only experienced users can locate. We might need a 
search button on the navbar.

Best,
Zhi

> On Sep 26, 2019, at 9:24 AM, Anirudh Acharya  wrote:
> 
> Hi,
> 
> In the operator tutorial(
> http://mxnet.incubator.apache.org/api/faq/add_op_in_backend), there are
> sections which do not render properly, for example - forward function,
> backward function and shape inference.
> 
> 
> Thanks
> Anirudh
> 
> 
> 
> 
> On Wed, Sep 25, 2019 at 7:53 AM Aaron Markham 
> wrote:
> 
>> I'm seeing GA code is -1 not -11 in the analytics admin console. 11
>> was for beta.mxnet.io.
>> Either way, the Jekyll prod config file was missing the GA code, so I
>> added it with this PR:
>> https://github.com/apache/incubator-mxnet/pull/16271
>> 
>> Reindexing of the site is being tracked here:
>> https://issues.apache.org/jira/browse/INFRA-19144
>> 
>> .htaccess testing was hampered by it not working on staging. This was
>> tracked here, and it looks like infra just patched staging so we can
>> resume redirect testing:
>> https://issues.apache.org/jira/browse/INFRA-19075
>> I have a CI pipeline for beta testing. If anyone wants to contribute
>> to working on the redirects, you can use this pipeline to publish to
>> the beta staging site.
>> http://jenkins.mxnet-ci.amazon-ml.com/job/restricted-website-publish-beta/
>> I've distilled this information in this issue:
>> https://github.com/apache/incubator-mxnet/issues/16273
>> I'd much rather have another contributor work on this since it will
>> teach testing changes on the website, testing CI deployments to
>> staging using your fork, previewing on staging, and finally deploying
>> it to prod. I'm happy to help & guide along the way.
>> 
>> (echoing Thomas) Please be sure to raise new issues in the repo, so we
>> don't lose them in this thread. Also, more people can work on them. It
>> would great if others can jump in and get familiar with the new site
>> and start contributing patches.
>> 
>> Cheers,
>> Aaron
>> 
>> On Wed, Sep 25, 2019 at 3:15 AM Thomas DELTEIL
>>  wrote:
>>> 
>>> @Philip Yes we're looking at link redirects for older links that might be
>>> hosted externally (using htaccess is my preferred way to handle it for
>> now
>>> as you sugested) and we'll use a broken link checker to update the links
>>> that are hosted internally. We'll update the 404 to add an explanation on
>>> the website update. Google indexes will slowly update across the week so
>>> the google search issues will be less of a problem.
>>> 
>>> If you find any such links yourself, or missing tutorials, please
>> consider
>>> stepping up and helping fixing them. The more people get familiar with
>> the
>>> new website architecture, the least likely it is to fall in a state of
>>> stalled updates like the previous one.
>>> 
>>> For the sphinx issues in the python mini-website, missing API classes, if
>>> anybody is familiar with it, I'd love for us to bring back the automatic
>>> doc generation for each package so at least we have a list of all
>> available
>>> classes in each sub package rather than relying on manual insertion of
>> each
>>> class, which is brittle and not future proof. @Lin, Haibin
>>>  if you have experience with it, could we sync up
>>> offline on how you suggest to do that based on your gluon-nlp experience?
>>> 
>>> @Marco, I'm currently traveling for ICDAR in Sydney, and Aaron is on PTO
>> in
>>> Europe, I'll try make time today to help with the fixes since it is
>>> impacting a lot of users.
>>> 
>>> In the meanwhile, any help is appreciated, and more than the value of the
>>> fixes, let me repeat that there is tremendous value in having more people
>>> familiar with the website build pipelines. Aaron is the main owner for
>> the
>>> docs but he is already super busy with all his other responsibilities.
>> I'm
>>> available to help if anybody is stuck. I believe Aaron has updated the
>>> READMEs on how to test the websites locally, if they're not clear, feel
>>> free to contribute your own explanations or ask for help directly to me
>> by
>>> email or on the discuss forum.
>>> 
>>> Good hunting!
>>> 
>>> Thomas
>>> 
>>> 
>>> 
>>> Le mer. 25 sept. 2019 à 10:10, Marco de Abreu 
>> a
>>> écrit :
>>> 
 Good catch, Mu! Also good idea, Philip!
 
 Aaron and Thomas, are you going to work on this?
 
 -Marco
 
 On Wed, Sep 25, 2019 at 1:28 AM Mu Li  wrote:
 
> The questions I found are:
> 
> 1. Not ever page contains, especially the homepage
> 
> 
 
>> http://mxnet.incubator.apache.org/api/python/docs/_static/google_analytics.js
> 2. The correct tracking id is UA-96378503-1 instead of
>> UA-96378503-11 in
> 
> 
 
>> http://mxnet.incubator.apache.org/api/python/docs/_static/google_analytics.js
> 
> On Tue, Sep 24, 2019 at 

Re: [Announcement] New Committer - Junru Shao

[Joshua Z. Zhang]

Well deserved Junru, welcome!

-Zhi

> On Sep 8, 2019, at 7:04 PM, Yuan Tang  wrote:
> 
> Welcome Junru!
> 
> On Sun, Sep 8, 2019 at 9:21 PM Lin Yuan  wrote:
> 
>> Congratulations!
>> 
>> On Sat, Sep 7, 2019 at 8:14 PM Sheng Zha  wrote:
>> 
>>> Hi all,
>>> 
>>> Please join me in welcoming Junru Shao as a new committer of Apache MXNet
>>> (incubating)!
>>> 
>>> Junru made a number of contributions to this project such as cond and
>>> while_loop control-flow
>>> operators, enabling dynamic shape in control-flow ops, and zero-copy
>> array
>>> creation from numpy
>>> array. He's also been actively working on numpy-compatible programming
>>> experience and
>>> has helped the community recently by driving the 1.4.1 patch release.
>>> 
>>> Welcome, Junru!
>>> 
>>> -sz
>>> 
>> 

Re: [Announcement] New Committer - Lai Wei

[Joshua Z. Zhang]

Congrats Lai, well deserved!

-Zhi

> On Aug 3, 2019, at 11:53 PM, Qing Lan  wrote:
> 
> Congrats Lai!
> 
> 
> From: Kshitij Kalambarkar 
> Sent: Sunday, August 4, 2019 0:19
> To: dev@mxnet.incubator.apache.org 
> Subject: Re: [Announcement] New Committer - Lai Wei
> 
> Congratulations Lai!
> 
> On Sun, Aug 4, 2019, 09:29 Zhao, Patric  wrote:
> 
>> Congratulation, Lai.
>> 
>> Well done for the very challenge release 1.5 and you make the progress
>> going smoothly 
>> 
>> 
>>> -Original Message-
>>> From: kellen sunderland 
>>> Sent: Sunday, August 4, 2019 9:32 AM
>>> To: dev@mxnet.incubator.apache.org
>>> Subject: Re: [Announcement] New Committer - Lai Wei
>>> 
>>> Congrats Lai.  Well deserved.
>>> 
>>> On Sat, Aug 3, 2019, 6:18 PM Jake Lee  wrote:
>>> 
 Congratulations! Lai
 
 On Sat, Aug 3, 2019 at 6:13 PM Sheng Zha  wrote:
 
> Hi all,
> 
> Please join me in welcoming Lai (Roy) Wei as a new committer of
> Apache MXNet (incubating)!
> 
> Lai was one of the main contributor to the MXNet Keras frontend.
> More recently, he contributed the Gluon estimator API, which enables
> easy usage and better modularization for the training scripts of
> Gluon. He also persisted and helped driving the long-running 1.5.0
> release process.
> 
> Welcome, Lai!
> 
> -sz
> 
> 
 
>> 

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

[Joshua Z. Zhang]

+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  
> 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
> 
> 
 
>>> 
>> 

Re: [Announcement] New Committer - Patric Zhao

[Joshua Z. Zhang]

  
  

 Congrats Patrick!
  

  
  

 Zhi
  
>   
> On Mar 15, 2019 at 10:46 PM,   (mailto:marco.g.ab...@gmail.com)>  wrote:
>   
>   
>   
>  Congratulations, great to have you on board!  
>
> -Marco  
>
> Lv, Tao Aschrieb am Fr., 15. März 2019, 15:38:  
>
> >  Wow, congratulation Patric!  
> >   
> >  -Original Message-  
> >  From: Steffen Rochel [mailto:steffenroc...@gmail.com]  
> >  Sent: Friday, March 15, 2019 10:25 PM  
> >  To: dev@mxnet.incubator.apache.org  
> >  Cc: patric zhao 
> >  Subject: Re: [Announcement] New Committer - Patric Zhao  
> >   
> >  Congratulation Patrick!  
> >  Steffen  
> >   
> >  On Fri, Mar 15, 2019 at 5:38 AM Zhao, Patric 
> >  wrote:  
> >   
> >   >  I am very glad to have this opportunity to contribute to the  
> >   >  Apache/MXNet community :)  
> >   >   
> >   >  Thanks all of the supports from the community and Intel.  
> >   >   
> >   >  BR,  
> >   >   
> >   >  --Patric  
> >   >   
> >   >   
> >   >   >  -Original Message-  
> >   >   >  From: MiraiWK WKCN [mailto:w...@live.cn]  
> >   >   >  Sent: Friday, March 15, 2019 12:52 AM  
> >   >   >  To: dev@mxnet.incubator.apache.org; patric zhao  
> >   >   >  
> >   >   >  Subject: Re: [Announcement] New Committer - Patric Zhao  
> >   >   >   
> >   >   >  Welcome Peng Zhao!  
> >   >   >  Peng is the AI Tech Leader in Intel Corporation. We have good  
> >   >   >  cooperation before. He is very professional and contribute a lot 
> > to  
> >   >   >  MXNet,  
> >   >  especially deep  
> >   >   >  learning boost on CPU.  
> >   >   >   
> >   >   >    
> >   >   >  From: Anirudh Subramanian 
> >   >   >  Sent: Thursday, March 14, 2019 3:54:50 PM  
> >   >   >  To: dev@mxnet.incubator.apache.org; patric zhao  
> >   >   >  Subject: [Announcement] New Committer - Patric Zhao  
> >   >   >   
> >   >   >  Hi all,  
> >   >   >   
> >   >   >  Please join me to welcome Patric Zhao as a new committer of Apache 
> >  
> >   >   >  (incubating) MXNet!  
> >   >   >   
> >   >   >  Patric has put in great effort around MKLDNN integration into 
> > MXNet  
> >   >   >  and  
> >   >  has  
> >   >   >  been involved in features like quantization, graph fusion and 
> > fused  
> >   >   >  RNN operators for CPU.  
> >   >   >   
> >   >   >  Dev List activity:  
> >   >   >   
> >   >  
> > https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=3y:patric.  
> >   >  zhao  
> >   >   >   
> >   >   >  Issues:  
> >   >   >  https://github.com/apache/incubator-  
> >   >   >  
> > mxnet/issues?utf8=%E2%9C%93=is%3Aissue+involves%3Apengzhao-intel+  
> >   >   >   
> >   >   >  PR Reviews:  
> >   >   >  https://github.com/apache/incubator-  
> >   >   >  mxnet/pulls?utf8=%E2%9C%93=is%3Apr+reviewed-by%3Apengzhao-intel  
> >   >   >   
> >   >   >  Proposals involved in:  
> >   >   >  
> > https://cwiki.apache.org/confluence/display/MXNET/MXNet+Graph+Optimi  
> >   >   >  z  
> >   >   >  ation+and+Quantization+based+on+subgraph+and+MKL-DNN  
> >   >   >  
> > https://cwiki.apache.org/confluence/display/MXNET/Fused+RNN+Operator  
> >   >   >  s  
> >   >   >  +for+CPU  
> >   >   >   
> >  >   >   >  i  
> >   >   >  zation+and+Quantization+based+on+subgraph+and+MKL-DNN>   
> >   >   >   
> >   >   >   
> >   >   >  Thanks,  
> >   >   >  Anirudh  
> >   >   
> >   
>  

Re: Embedded World 2019 Robotics Demo

[Joshua Z. Zhang]

Played with the demo closely today, and it looks awesome with the real robot 
arms!

-Zhi

> On Feb 27, 2019, at 11:03 PM, Thomas DELTEIL  
> wrote:
> 
> Just tweeted two videos about it:
> https://twitter.com/thdelteil/status/1101012275991764993
> https://twitter.com/thdelteil/status/1101012034051727360
> We will write a blog post or two about the project when Anton, Pavel and
> the others are back from the conference to give more details :)
> 
> To summarize and as can be inferred from the videos, two robotic arms are
> moving according to the position of the wrists of the player. The pose of
> the player is detected using a pose estimation neural network based on the
> implementation of Simple Baselines for Pose Estimation paper
> that
> is going to be released in the next version of gluon-cv, shout out to Zhi
> and He Tong for providing the training code. Another classifier detects the
> hand as open or closed and that decides the position of the grips. The goal
> of the game is to take a book from one side and drop it in the bucket on
> the other side by passing it between the two arms. The robots are from
> Nyrio, a French startup.
> 
> To answer your question Isabel, this project was a joint cooperation
> between a few MXNet team members at AWS, including Anton, Pavel and myself
> and some employees at the QT (the C++ library) company, in their industrial
> automation department.
> 
> All the best,
> 
> Thomas Delteil
> 
> Le mer. 27 févr. 2019 à 22:27, Junru Shao  a
> écrit :
> 
>> Hi Anton,
>> 
>> Would love to know more about this great demo! Will you guys share video
>> clips?
>> 
>> Cheers,
>> Junru
>> 
>> On Wed, Feb 27, 2019 at 8:11 PM Isabel Drost-Fromm 
>> wrote:
>> 
>>> Hi,
>>> 
>>> Sounds interesting. Can you share more on what you are showing and what
>>> role mxnet plays?
>>> 
>>> Also, who's that "we" behind "our booth"?
>>> 
>>> 
>>> Have fun in Nürnberg,
>>> Isabel
>>> 
>>> Am 27. Februar 2019 11:38:57 MEZ schrieb Anton Chernov <
>>> mecher...@gmail.com>:
 Dear MXNet Community,
 
 If you happens to be at the Embedded World exhibition in Nürnberg drop
 by
 our booth at the Qt stand in hall 4 to see a MXNet robotics demo.
 
 Looking forward to see you!
 
 Best
 Anton
>>> 
>>> --
>>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>>> 
>> 

Re: [Announce] Upcoming Apache MXNet (incubating) 1.4.0 release

[Joshua Z. Zhang]

Hi, I would like to bring a critical performance and stability patch of 
existing gluon dataloader to 1.4.0: 
https://github.com/apache/incubator-mxnet/pull/13447 
. 

This PR is finished, waiting for CI to pass. 

Steffen, could you help me add that to the tracked list?

Best,
Zhi

> On Nov 29, 2018, at 4:25 PM, Naveen Swamy  wrote:
> 
> the tests are randomly failing in different stages
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/PR-13105/
> This PR has failed 8 times so far
> 
> On Thu, Nov 29, 2018 at 3:43 PM Steffen Rochel 
> wrote:
> 
>> Pedro - ok. Please add PR to v1.4.x branch after merge to master and please
>> update tracking page
>> <
>> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Plan+and+Status#ApacheMXNet(incubating)1.4.0ReleasePlanandStatus-OpenPRstotrack
>>> 
>> .
>> Steffen
>> 
>> On Thu, Nov 29, 2018 at 3:00 PM Pedro Larroy >> 
>> wrote:
>> 
>>> PR is ready from my side and passes the tests, unless somebody raises
>>> any concerns it's good to go.
>>> On Thu, Nov 29, 2018 at 9:50 PM Steffen Rochel 
>>> wrote:
 
 Pedro - added  to 1.4.0 tracking list
 <
>>> 
>> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Plan+and+Status#ApacheMXNet(incubating)1.4.0ReleasePlanandStatus-OpenPRstotrack
 
 
 Do you have already ETA?
 Steffen
 
 On Thu, Nov 29, 2018 at 6:13 AM Pedro Larroy <
>>> pedro.larroy.li...@gmail.com>
 wrote:
 
> Hi all.
> 
> There are two important issues / fixes that should go in the next
> release in my radar:
> 
> 1) https://github.com/apache/incubator-mxnet/pull/13409/files
> There is a bug in shape inference on CPU when not using MKL, also we
> are running activation on CPU via MKL when we compile CUDNN+MKLDNN.
> I'm finishing a fix for these issues in the above PR.
> 
> 2) https://github.com/apache/incubator-mxnet/issues/13438
> We are seeing crashes due to unsafe setenv in multithreaded code.
> Setenv / getenv from multiple threads is not safe and is causing
> segfaults. This piece of code (the handlers in pthread_atfork)
>> already
> caused a very difficult to diagnose hang in a previous release, where
> a fork inside cudnn would deadlock the engine.
> 
> I would remove setenv from 2) as a mitigation, but we would need to
> check for regressions as we could be creating additional threads
> inside the engine.
> 
> I would suggest that we address these two major issues before the
>> next
> release.
> 
> Pedro
> 
> 
> 
> On Sun, Nov 25, 2018 at 11:41 PM Steffen Rochel <
>>> steffenroc...@gmail.com>
> wrote:
>> 
>> Dear MXNet community,
>> 
>> I will be the release manager for the upcoming Apache MXNet 1.4.0
> release.
>> Sergey Kolychev will be co-managing the release and providing help
>>> from
> the
>> committers side.
>> A release candidate will be cut on November 29, 2018 and voting
>> will
> start
>> December 7, 2018. Release notes have been drafted here [1]. If you
>>> have
> any
>> additional features in progress and would like to include it in
>> this
>> release, please assure they have been merged by November 27, 2018.
> Release
>> schedule is available here [2].
>> 
>> Feel free to add any other comments/suggestions. Please help to
>>> review
> and
>> merge outstanding PR's and resolve issues impacting the quality of
>>> the
>> 1.4.0 release.
>> 
>> Regards,
>> 
>> Steffen
>> 
>> [1]
>> 
> 
>>> 
>> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Notes
>> 
>> [2]
> 
>>> 
>> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Plan+and+Status
>> 
>> 
>> 
>> 
>> On Tue, Nov 20, 2018 at 7:15 PM kellen sunderland <
>> kellen.sunderl...@gmail.com> wrote:
>> 
>>> Spoke too soon[1], looks like others have been adding Turing
>>> support as
>>> well (thanks to those helping with this).  I believe there's
>> still
>>> a
> few
>>> changes we'd have to make to claim support though (mshadow CMake
> changes,
>>> PyPi package creation tweaks).
>>> 
>>> 1:
>>> 
>>> 
> 
>>> 
>> https://github.com/apache/incubator-mxnet/commit/2c3357443ec3d49a11e93c89f278264ce10c2f08
>>> 
>>> On Tue, Nov 20, 2018 at 7:00 PM kellen sunderland <
>>> kellen.sunderl...@gmail.com> wrote:
>>> 
 Hey Steffen, I'd like to be able to merge this PR for version
>>> 1.4:
 https://github.com/apache/incubator-mxnet/pull/13310 . It
>> fixes
>>> a
 regression in master which causes incorrect feature vectors to
>> be
> output
 when 

Re: Propose to discontinue supporting Apache MXNet on Windows 7

[Joshua Z. Zhang]

I have contacted some friends in industry, they claim that some controller PCs 
are still on win7 and have no plan to upgrade in near future, so I would 
strongly go -1. 

In terms of build system on Windows 7, MS does give warnings in VS 2015, but 
with compatibility mode, we can still install it without issue. So I guess it’s 
marketing strategy not technical problem on MS side.

Zhi

> On Sep 4, 2018, at 9:02 AM, sebastianb  wrote:
> 
> One more data point: Mathematica still supports Windows 7 (with Platform 
> Update), and we use MXNet as a backend for our neural net framework. So I 
> would also vote against deprecating Windows 7 support.
> 
>> On Sep 2, 2018, at 7:40 PM, Marco de Abreu 
>>  wrote:
>> 
>> Thanks for the data and these quite important points. I agree and hereby
>> change my vote to -1.
>> 
>> Barber, Christopher  schrieb am So., 2. Sep.
>> 2018, 18:56:
>> 
>>> FWIW, my company is only beginning to transition to Windows 10 now, and my
>>> past experience would lead me to believe that many enterprises stick with
>>> old versions of Windows long past when you think they would.
>>> 
>>> Seems to me that if you are unwilling to deprecate python 2.7, then
>>> continuing to support Windows 7 is a no-brainer. You are more likely to get
>>> users to switch to python 3 than you are to get them to install a new
>>> operating system.
>>> 
>>> And do you really want to drop support for platforms that your competitors
>>> still support? Given MXNet's market share, I wouldn't dream of dropping a
>>> platform until after the more popular frameworks have already done so.
>>> 
>>> I also believe that it is possible to install more recent versions of
>>> Visual Studio on Windows 7.
>>> 
>>> On 9/2/18, 1:57 AM, "kellen sunderland" 
>>> wrote:
>>> 
>>>   Google analytics are sadly probably the best numbers we're going to
>>> get.
>>>   Of course these numbers are likely to over-represent windows usage, as
>>> I'm
>>>   sure many people are looking up documentation on a windows machine
>>> while
>>>   ssh'd into a cloud instance or IoT device.
>>> 
>>>   What's the trend over time for these numbers Mu?  Is Windows 7 usage
>>>   relatively stable over the last year?
>>> 
>>>   On Sun, Sep 2, 2018 at 1:58 AM Mu Li  wrote:
>>> 
 According to google analytics, ~12% users who visited mxnet's
>>> website are
 using Windows 7. It's a significant number. Even though we cannot
>>> conclude
 that all of these users will run MXNet on Windows 7, I suggest we
>>> still
 support win7.
 
 BTW, anyone who can access mxnet's google analytics report can
>>> verify this
 number by following this instruction:
 
 
>>> https://stackoverflow.com/questions/1340778/detecting-windows-7-with-google-analytics
 
 
 
 On Sat, Sep 1, 2018 at 1:55 PM Steffen Rochel <
>>> steffenroc...@gmail.com>
 wrote:
 
> I support a data driven decision. Any suggestions how we can obtain
 insight
> about OS usage of the MXNet user community?
> Can we get such information from pip install statistics or should
>>> we
> perform a user poll on the discussion forum?
> On the other hand the lack of data should not prevent us from
>>> moving
> forward and dropping support for outdated OS.
> In any case we would have to announce dropping a platform support
>>> at
 least
> a release in advance.
> Steffen
> 
> On Thu, Aug 30, 2018 at 12:21 PM Sheng Zha 
>>> wrote:
> 
>> Hi Kellen,
>> 
>> Thanks for the explanation. Unfortunately, I don't have the
>>> usage data,
> so
>> I refrained from voting. If any of the voters have such data I'd
>>> love
 to
>> see it too.
>> 
>> -sz
>> 
>> On 2018/08/30 14:58:09, kellen sunderland <
>>> kellen.sunderl...@gmail.com
> 
>> wrote:
>>> I haven't spoken to anyone about the decision (as I'm
>>> currently on an
>>> island in the med) but to me the quick +1s are likely a result
>>> of
 this
>>> being a fairly straightforward decision.  The factors that
>>> went into
 my
>>> thinking were (1) prioritizing growing platforms rather than
 shrinking
>>> platforms (i.e. thinking long term rather than shirt term) and
>>> (2)
>> earning
>>> our customers' trust.  Claiming support for a platform when we
>>> can't
>>> realistically deliver it would lose us trust.  I'd prefer to
>>> over
> deliver
>>> and under promise when it come to windows 7 for this reason.
>>> 
>>> Now on the flip side one thing I would see as valuable is to
>>> try and
> get
>>> windows builds working with clang.  This could be beneficial
>>> in the
> sense
>>> that it would be easy to maintain for mxnet devs and allow us
>>> to use
>> modern
>>> cpp on older windows machines without using vs 2013(which I
>>> consider
 a
>>> non-starter with our codebase).
>>> 
>>> You have peaked my curiousity though 

Re: [VOTE] Release MXNet version 1.3.0.RC0

[Joshua Z. Zhang]

  
  

  
  

  
  
Sheng, thanks for clarification. That make sense to me. I will change the vote 
to +1
  
  
>   
> On Sep 2, 2018 at 9:43 AM,  mailto:zhash...@apache.org)>  wrote:
>   
>   
>   
>  Hi Steffen and Zhi,  
>
> That's because those are not the artifacts being voted on. I just uploaded 
> the actual release artifact to [1]. Unfortunately, even the lengthy release 
> process doc [2] didn't capture this step...  
>
> Steffen,  
>
> In case you don't already know, regarding the version string, since we cannot 
> change the code after the vote passes, the version never says it's a release 
> candidate, only the file name does. None of the previous releases follow the 
> convention you suggested. Please adjust your expectation and vote again. Feel 
> free to download previous releases and verify:  
>
> % tar -zxf apache-mxnet-src-1.2.1.rc1-incubating.tar.gz -O 
> apache-mxnet-src-1.2.1.rc1-incubating/python/mxnet/libinfo.py | grep 
> '__version__'  
> __version__ = "1.2.1"  
>
> Zhi,  
>
> We are not accepting new patches after the announced cutoff time. If you 
> think this patch is optional and you see no other issue with this release, 
> consider changing your vote. If you think the patch is critical, feel free to 
> sustain your -1 vote until the end of this voting cycle.  
>
> [1] 
> https://github.com/apache/incubator-mxnet/releases/download/1.3.0.rc0/apache-mxnet-src-1.3.0.rc0-incubating.tar.gz
>   
> [2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=73630468 
>  
>
> -sz  
>
> On 2018/09/01 22:08:48, "Joshua Z. Zhang"wrote:  
> >  -1. Please include all 3rd party dependencies, GitHub won’t automatically 
> > do that.  
> >   
> >  BTW, Per user request in forum, I found this 
> > PR(https://github.com/apache/incubator-mxnet/pull/12118  
> > <https://github.com/apache/incubator-mxnet/pull/12118>) is not included in 
> > 1.3 rc0, I recommend to cherry-pick into release to avoid potential 
> > problems.  
> >   
> >  Best,  
> >  Zhi  
> >   >  On Sep 1, 2018, at 2:27 PM, Steffen Rochel
> > wrote:  
> >   >   
> >   >  -1  
> >   >   
> >   >  https://github.com/apache/incubator-mxnet/archive/1.3.0.rc0.zip and  
> >   >  https://github.com/apache/incubator-mxnet/archive/1.3.0.rc0.tar.gz do 
> > not  
> >   >  contain 3rdparty packages, resulting in make failure:  
> >   >  tar zxf incubator-mxnet-1.3.0.rc0.tar.gz  
> >   >  cd incubator-mxnet-1.3.0.rc0/  
> >   >  make USE_OPENCV=1 USE_BLAS=openblas  
> >   >  Makefile:74:  
> >   >  
> > /home/steffen/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty/mshadow/make/  
> >   >  mshadow.mk: No such file or directory  
> >   >  Makefile:75:  
> >   >  
> > /home/steffen/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty/dmlc-core/make/  
> >   >  dmlc.mk: No such file or directory  
> >   >  Makefile:176: "USE_LAPACK disabled because libraries were not found"  
> >   >  Makefile:284: WARNING: Significant performance increases can be 
> > achieved by  
> >   >  installing and enabling gperftools or jemalloc development packages  
> >   >  Makefile:355:  
> >   >  
> > /home/steffen/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty/ps-lite/make/  
> >   >  ps.mk: No such file or directory  
> >   >  make: *** No rule to make target  
> >   >  
> > '/home/steffen/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty/ps-lite/make/  
> >   >  ps.mk'. Stop.  
> >   >   
> >   >  ~/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty$ ls -al *  
> >   >  cub:  
> >   >  total 8  
> >   >  drwxr-xr-x 2 steffen steffen 4096 Aug 29 10:07 .  
> >   >  drwxr-xr-x 12 steffen steffen 4096 Aug 29 10:07 ..  
> >   >   
> >   >  dlpack:  
> >   >  total 8  
> >   >  drwxr-xr-x 2 steffen steffen 4096 Aug 29 10:07 .  
> >   >  drwxr-xr-x 12 steffen steffen 4096 Aug 29 10:07 ..  
> >   >   
> >   >  dmlc-core:  
> >   >  total 8  
> >   >  drwxr-xr-x 2 steffen steffen 4096 Aug 29 10:07 .  
> >   >  drwxr-xr-x 12 steffen steffen 4096 Aug 29 10:07 ..  
> >   >   
> >   >  Environment:  
> >   >  uname -a  
> >   >  Linux steffen 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 
> > 2018  
> >   >  x86_64 x86_64 x86_64 GNU/L  
> >   >   
> >   >  Build from git succeeded:  
> >   >  git clone --recursive https://github.com/apache/incubator-mxnet 
> > --

Re: [VOTE] Release MXNet version 1.3.0.RC0

[Joshua Z. Zhang]

-1. Please include all 3rd party dependencies, GitHub won’t automatically do 
that. 

BTW, Per user request in forum, I found this 
PR(https://github.com/apache/incubator-mxnet/pull/12118 
) is not included in 1.3 
rc0, I recommend to cherry-pick into release to avoid potential problems. 

Best,
Zhi
> On Sep 1, 2018, at 2:27 PM, Steffen Rochel  wrote:
> 
> -1
> 
> https://github.com/apache/incubator-mxnet/archive/1.3.0.rc0.zip and
> https://github.com/apache/incubator-mxnet/archive/1.3.0.rc0.tar.gz do not
> contain 3rdparty packages, resulting in make failure:
> tar zxf incubator-mxnet-1.3.0.rc0.tar.gz
> cd incubator-mxnet-1.3.0.rc0/
> make USE_OPENCV=1 USE_BLAS=openblas
> Makefile:74:
> /home/steffen/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty/mshadow/make/
> mshadow.mk: No such file or directory
> Makefile:75:
> /home/steffen/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty/dmlc-core/make/
> dmlc.mk: No such file or directory
> Makefile:176: "USE_LAPACK disabled because libraries were not found"
> Makefile:284: WARNING: Significant performance increases can be achieved by
> installing and enabling gperftools or jemalloc development packages
> Makefile:355:
> /home/steffen/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty/ps-lite/make/
> ps.mk: No such file or directory
> make: *** No rule to make target
> '/home/steffen/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty/ps-lite/make/
> ps.mk'.  Stop.
> 
> ~/Downloads/incubator-mxnet-1.3.0.rc0/3rdparty$ ls -al *
> cub:
> total 8
> drwxr-xr-x  2 steffen steffen 4096 Aug 29 10:07 .
> drwxr-xr-x 12 steffen steffen 4096 Aug 29 10:07 ..
> 
> dlpack:
> total 8
> drwxr-xr-x  2 steffen steffen 4096 Aug 29 10:07 .
> drwxr-xr-x 12 steffen steffen 4096 Aug 29 10:07 ..
> 
> dmlc-core:
> total 8
> drwxr-xr-x  2 steffen steffen 4096 Aug 29 10:07 .
> drwxr-xr-x 12 steffen steffen 4096 Aug 29 10:07 ..
> 
> Environment:
> uname -a
> Linux steffen 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018
> x86_64 x86_64 x86_64 GNU/L
> 
> Build from git succeeded:
> git clone --recursive https://github.com/apache/incubator-mxnet --branch
> 1.3.0.rc0
> cd incubator-mxnet/
> git checkout 1.3.0.rc0
> make USE_OPENCV=1 USE_BLAS=openblas
> cd python/
> sudo pip install -e .
> 
 import mxnet as mx
 print(mx.__version__)
> 1.3.0
> 
> I was expecting version to be 1.3.0.rc0
> 
> Steffen
> 
> 
> 
> On Sat, Sep 1, 2018 at 3:22 AM Pigeon Lucky  wrote:
> 
>> +1
>> 
>> On Sat, 1 Sep 2018, 10:59 Roshani Nagmote, 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> I would like to propose a vote to release Apache MXNet (incubating)
>> version
>>> 1.3.0.RC0. Voting will start now (Friday, Aug 31st) and end at 7:00 PM
>>> PDT, Wednesday, Sept 5th.
>>> 
>>> Link to release notes:
>>> https://github.com/apache/incubator-mxnet/releases
>>> 
>>> Link to release candidate 1.3.0.rc0:
>>> *https://github.com/apache/incubator-mxnet/releases/tag/1.3.0.rc
>>> 0*
>>> 
>>> View this page, click on "Build from Source", and use the source code
>>> obtained from 1.3.0.rc0 tag:
>>> https://mxnet.incubator.apache.org/install/index.html
>>> 
>>> Please remember to TEST first before voting accordingly:
>>> 
>>> +1 = approve
>>> +0 = no opinion
>>> -1 = disapprove (provide reason)
>>> 
>>> Thanks,
>>> Roshani
>>> 
>> 

Re: Release plan - MXNET 1.3

[Joshua Z. Zhang]

I strongly suggest to track this PR 
https://github.com/apache/incubator-mxnet/pull/11908 
 in 1.3 release which 
fixed the usability issue for lower end machines that don’t have as large 
shared memory space as ec2 instances. 

Best,

- Zhi

> On Aug 7, 2018, at 9:05 AM, Roshani Nagmote  wrote:
> 
> Hi all,
> 
> Right now, we are delaying MXNet 1.3 release for pending TensorRT PR (
> https://github.com/apache/incubator-mxnet/pull/11325 ).
> 
> I wanted to ask everyone for their opinions if we should delay the release
> to get tensorRT integration in or we should go ahead with the release and
> include tensorRT in next release. Please provide suggestions.
> 
> Thanks,
> Roshani
> 
> On Mon, Aug 6, 2018 at 12:45 AM Hagay Lupesko  wrote:
> 
>> Some thoughts: why not keep it out of 1.3, and merge it into master so it
>> can go out with 1.4 instead?
>> Pros:
>> - Reduce quality risks for 1.3
>> - More time to test and get feedback before release
>> - Avoid further delays in 1.3 release (lots of good stuff there already for
>> users)
>> Cons:
>> - People will need to get master to experiment with TRT (not a major issue
>> IMO)
>> 
>> Besides, TRT requires a build flag anyway, so MXNet users consuming built
>> packages (PyPi, Scala) will anyway not be able to try it out unless
>> building from source...
>> 
>> Thoughts?
>> 
>> On Sun, Aug 5, 2018 at 10:38 PM Steffen Rochel 
>> wrote:
>> 
>>> Marek, Kellen, Jun, Da, Eric, myself and a few other people discussed
>>> offline about TensorRT integration PR (
>>> https://github.com/apache/incubator-mxnet/pull/11325 ). We do agree that
>>> it
>>> would be good to include the PR into upcoming 1.3 release, but are all
>>> concerned about the risk involved and the breaking API change. The
>>> discussion converged to following proposal. (1) change to contrib PR and
>>> (2) define a different top level API to indicate that the package is part
>>> of contrib and experimental (details of API TBD between Marek, Kellen and
>>> Eric). This change would allow to include TRT integration with v1.3 to
>>> enable users to try TRT with MXNet, minimize the risk and avoid breaking
>>> API change.
>>> To accommodate the change the request is to delay RC for a few days.
>>> 
>>> Regards,
>>> Steffen
>>> 
>>> On Tue, Jul 31, 2018 at 5:08 PM Roshani Nagmote <
>> roshaninagmo...@gmail.com
 
>>> wrote:
>>> 
 Hi,
 
 I have created a wiki for tracking MXNet 1.3 release with the timeline.
 Please take a look here:
 
 
>>> 
>> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.3.0+Release+Status
 
 I am still waiting for following 2 PRs to get merged:
 TRT integration: https://github.com/apache/incubator-mxnet/pull/11325
 Gluon RNN: https://github.com/apache/incubator-mxnet/pull/11482
 
 *Code freeze date is 08/02(Thursday).* Kindly try to complete ongoing
>>> work
 and get these PRs merged.
 
 Thanks,
 Roshani
 
 
 
 On Mon, Jul 30, 2018 at 1:02 PM Roshani Nagmote <
>>> roshaninagmo...@gmail.com
> 
 wrote:
 
> Hi all,
> 
> Here is an update on MXNet 1.3 release:
> I am still waiting for following PRs to get merged:
> 
> TRT integration:
>> https://github.com/apache/incubator-mxnet/pull/11325
> Gluon RNN: https://github.com/apache/incubator-mxnet/pull/11482
> Scala examples:
> 
> https://github.com/apache/incubator-mxnet/pull/11753
> 
> https://github.com/apache/incubator-mxnet/pull/11621
> 
> *New code freeze date is: 08/03*  Please try to get your ongoing PRs
> merged by then.
> 
> @Pedro, I didn't include your PRs in tracking list as you said those
>>> are
> not critical for now. Please let me know if those needs to be
>> included.
> https://github.com/apache/incubator-mxnet/pull/11636
> https://github.com/apache/incubator-mxnet/pull/11562
> 
> I also have updated project proposal cwiki page to update the status
>> of
> PRs.
> <
 
>>> 
>> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
> 
> 
> Please let me know if I am missing something.
> 
> Thanks,
> Roshani
> 
> 
> On Thu, Jul 26, 2018 at 1:34 PM Pedro Larroy <
 pedro.larroy.li...@gmail.com>
> wrote:
> 
>> I would like to get these PR merged:
>> 
>> https://github.com/apache/incubator-mxnet/pull/11636
>> https://github.com/apache/incubator-mxnet/pull/11562
>> 
>> How much longer until the code freeze?
>> 
>> On Thu, Jul 26, 2018 at 1:44 AM Roshani Nagmote <
>> roshaninagmo...@gmail.com>
>> wrote:
>> 
>>> Hi all,
>>> 
>>> PRs waiting to be merged for 1.3 release:
>>> https://github.com/apache/incubator-mxnet/pull/11325
>>> 
>>> Are there any other PRs waiting to get merged? Please let me know.
>>> 

Re: [VOTE] Subscribe dev@ to Github Activities

[Joshua Z. Zhang]

+1

We NEED to bring valuable discussions to a centralized place (@dev for example) 
rather than scattered single threads.
Per filter options, there are a lot we can do to improve the SNR.

Zhi

On 2018/07/17 16:26:01, Sheng Zha  wrote: 
> Hi Anirudh,
> 
> 1. You need exactly one filter to filter out all the github notifications
> on PRs and issues: "from:notificati...@github.com", and you'd get your S/N
> ratio back.
> 2. Having the option to do design discussion on an issue or PR is actually
> a good thing as many discussions are quite small and better accompanied by
> code. If for some reason a merged design needs revisiting, there's still
> the option of sending an email to dev@ and discuss about it.
> 3. About votes, commit vote (and veto) can already happen on PR per past
> agreement. The discussion for procedural vote IMO should be allowed to
> happen on Github if it's development related. Procedural votes themselves
> should and can still happen on dev@.
> 
> About "you don't really have to do anything explicitly on the dev@ list",
> besides the above arguments, we don't send emails to dev@ just for the
> purpose of sending it. On the other hand, since "whatever didn't happen on
> dev list didn't happen", we'd need better arguments on why we'd choose to
> forego the transparency.
> 
> -sz
> 
> On Tue, Jul 17, 2018 at 8:47 AM, Anirudh  wrote:
> 
> > -1
> >
> > The low signal to noise ratio would mean that we may miss important emails.
> > Even with the different filters that we may setup for dev@, the emails
> > would be too many to not miss the important ones. We would see more and
> > more people starting a design discussion on an issue or PR. Because of the
> > low signal to noise ratio on the dev@ list, many may miss these
> > discussions.
> >
> > Slowly, this would erode the purpose of the dev@ list as this means that
> > you don't really have to do anything explicitly on the dev@ list.
> > You can start a design discussion on a github issue. You can start a
> > vote/discussion on a github issue.
> >
> > Anirudh
> >
> > On Mon, Jul 16, 2018 at 4:35 AM, Timur Shenkao  wrote:
> >
> > > +1 if my vote can be taken into account
> > >
> > > On Mon, Jul 16, 2018 at 4:32 AM, Sheng Zha  wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm starting a vote on subscribing dev@ to Github activities. See
> > > previous
> > > > discussion thread here
> > > >  > > > bfd01f0b78d3cb44034f566442@%3Cdev.mxnet.apache.org%3E>
> > > > .
> > > >
> > > > The vote lasts for three days and ends on 7/18/2018 at 9pm pst.
> > > >
> > > > -sz
> > > >
> > >
> >
>