Re: ONNX Support

[Anirudh Acharya]

Hi Sam, Lin and Chaitanya,

I am sorry I am not aware of anyone who is willing to actively maintain the
ONNX module. The last commit was made by https://github.com/vandanavk. I am
not sure how much time vandanavk@ can dedicate to this.

I am okay with what the community collectively decides on these tests(
enabling or disabling). The purpose of my previous mail was to let the
community know that there are users of the ONNX module and that there is
some activity regarding code changes in that module.


Thanks
Anirudh


On Mon, Oct 7, 2019 at 1:19 PM Skalicky, Sam 
wrote:

> Hi Chai,
>
> If there is no one maintaining MXNet-ONNX support (or no one currently
> available to help debug issues), then we shouldn’t block forward progress
> because of failing ONNX tests.
>
> It would be great if someone wanted to work with Chai to debug the failing
> tests. But I do not see any forward plans/proposals to continue to develop
> or even just maintain the current ONNX support.
>
> Anirudh, if you can point those who are willing to maintain the ONNX
> support to the issue Chai mentioned that would be a good place to start.
> But if not, we should help Chai continue the great work he’s doing by
> disabling the failing tests (like we normally do for any failing/flaky
> tests already)
>
> Sam
>
> > On Oct 7, 2019, at 12:45 PM, Anirudh Acharya 
> wrote:
> >
> > Hi Chaitanya,
> >
> > The last I checked( a couple of months back) there are a few
> > customers/users of MXNet in Amazon who use ONNX in production.
> >
> > The last commit for ONNX module was on Aug 29th
> > - b7cca015553d707cd1c4ce292826d7311309419c
> >
> > So IMO disabling any of the tests is not a good idea.
> >
> >
> > Thanks
> > Anirudh
> >
> >
> > On Mon, Oct 7, 2019 at 12:27 PM Chaitanya Bapat 
> > wrote:
> >
> >> Hello MXNet community,
> >>
> >> I wanted to know if MXNet should continue support for ONNX. Is there
> anyone
> >> actively working on MXNet ONNX or maintaining it?
> >>
> >> If not, can we skip/disable the ONNX tests from the CI.
> >> Reason - Whilst working on a Transpose operator PR [1], I encountered
> >> failure for ONNX [2]. Given operator passes rest of the CI pipeline
> tests.
> >> I am able to reproduce the error. However, the root cause for ONNX model
> >> failure couldn't be found. Moreover, there seems to be near zero
> activity
> >> as far as PR check-ins are concerned.
> >>
> >> How does ONNX fit in for MXNet going forward?
> >> Thank you
> >> Chai
> >>
> >>
> >> [1] https://github.com/apache/incubator-mxnet/pull/16104
> >> [2]
> >>
> >>
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-16104/14/pipeline
> >>
> >> --
> >> *Chaitanya Prakash Bapat*
> >> *+1 (973) 953-6299*
> >>
> >> [image: https://www.linkedin.com//in/chaibapat25]
> >> <https://github.com/ChaiBapchya>[image:
> https://www.facebook.com/chaibapat
> >> ]
> >> <https://www.facebook.com/chaibapchya>[image:
> >> https://twitter.com/ChaiBapchya] <https://twitter.com/ChaiBapchya
> >[image:
> >> https://www.linkedin.com//in/chaibapat25]
> >> <https://www.linkedin.com//in/chaibapchya/>
> >>
>
>

Re: ONNX Support

[Anirudh Acharya]

Hi Chaitanya,

The last I checked( a couple of months back) there are a few
customers/users of MXNet in Amazon who use ONNX in production.

The last commit for ONNX module was on Aug 29th
- b7cca015553d707cd1c4ce292826d7311309419c

So IMO disabling any of the tests is not a good idea.


Thanks
Anirudh


On Mon, Oct 7, 2019 at 12:27 PM Chaitanya Bapat 
wrote:

> Hello MXNet community,
>
> I wanted to know if MXNet should continue support for ONNX. Is there anyone
> actively working on MXNet ONNX or maintaining it?
>
> If not, can we skip/disable the ONNX tests from the CI.
> Reason - Whilst working on a Transpose operator PR [1], I encountered
> failure for ONNX [2]. Given operator passes rest of the CI pipeline tests.
> I am able to reproduce the error. However, the root cause for ONNX model
> failure couldn't be found. Moreover, there seems to be near zero activity
> as far as PR check-ins are concerned.
>
> How does ONNX fit in for MXNet going forward?
> Thank you
> Chai
>
>
> [1] https://github.com/apache/incubator-mxnet/pull/16104
> [2]
>
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-16104/14/pipeline
>
> --
> *Chaitanya Prakash Bapat*
> *+1 (973) 953-6299*
>
> [image: https://www.linkedin.com//in/chaibapat25]
> [image: https://www.facebook.com/chaibapat
> ]
> [image:
> https://twitter.com/ChaiBapchya] [image:
> https://www.linkedin.com//in/chaibapat25]
> 
>

Re: [Announcement] New Committer - Anirudh Acharya

[Anirudh Acharya]

Thank you, everyone.

-
Anirudh

On Sun, Sep 29, 2019 at 4:27 AM Kshitij Kalambarkar <
kshitijkalambar...@gmail.com> wrote:

> Congrats Anirudh!
>
> On Sun, Sep 29, 2019, 11:13 Sheng Zha  wrote:
>
> > Congrats! Now Anirudh is officially the most popular name among the MXNet
> > committers :P
> >
> > -sz
> >
> > On 2019/09/27 22:57:22, Furkan KAMACI  wrote:
> > > Hi,
> > >
> > > Congrats Anirudh!
> > >
> > > Kind Regards,
> > > Furkan KAMCI
> > >
> > > 28 Eyl 2019 Cmt, saat 01:34 tarihinde Marco de Abreu <
> > > marco.g.ab...@gmail.com> şunu yazdı:
> > >
> > > > Welcome!
> > > >
> > > >
> > > > On Sat, Sep 28, 2019 at 12:06 AM Chaitanya Bapat <
> chai.ba...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Congratulations Anirudh! Well deserved!
> > > > >
> > > > > On Thu, 26 Sep 2019 at 10:10, Chris Olivier <
> cjolivie...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Please join me in welcoming Anirudh Acharya as a new committer of
> > > > Apache
> > > > > > MXNet (incubating)!
> > > > > >
> > > > > > Anirudh Acharya has been contributing to the MXNet project for a
> > year
> > > > and
> > > > > > half now and has made several improvements to the MXNet R project
> > and
> > > > > > continues to contribute by adding optimizers, fixing tests and
> > actively
> > > > > > providing feedback on the PRs and has good understanding of
> > building
> > > > > > operators in MXNet and architecture in general.
> > > > > >
> > > > > > Welcome, Anirudh!
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *Chaitanya Prakash Bapat*
> > > > > *+1 (973) 953-6299*
> > > > >
> > > > > [image: https://www.linkedin.com//in/chaibapat25]
> > > > > <https://github.com/ChaiBapchya>[image:
> > > > https://www.facebook.com/chaibapat
> > > > > ]
> > > > > <https://www.facebook.com/chaibapchya>[image:
> > > > > https://twitter.com/ChaiBapchya] <https://twitter.com/ChaiBapchya
> > > > >[image:
> > > > > https://www.linkedin.com//in/chaibapat25]
> > > > > <https://www.linkedin.com//in/chaibapchya/>
> > > > >
> > > >
> > >
> >
>

Re: new website, docs code freeze

[Anirudh Acharya]

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 4:23 PM Mu Li  wrote:
> > > >
> > > > > I think the reason is that the google tracker is not included in
> the
> > > new
> > > > > website.
> > > > >
> > > > > On Tue, Sep 24, 2019 at 4:17 PM Marco de Abreu <
> > > marco.g.ab...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hello,
> > > > >>
> > > > >> I checked the Google Analytics statistics and the launch of the
> new
> > > > >> website reduced the traffic by 

Re: [Discuss] MXNet Python 2 Support Deprecation

[Anirudh Acharya]

+1

On Thu, Jul 18, 2019 at 11:03 AM Marco de Abreu 
wrote:

> +1
>
> -Marco
>
> Sheng Zha  schrieb am Do., 18. Juli 2019, 19:59:
>
> > Dear MXNet community,
> >
> > I'd like to reopen the discussion on deprecating python2 support. This
> > would help modernize the design and engineering practice in MXNet to help
> > improve speed and quality.
> >
> > For this purpose, I reopened the issue on this here:
> > https://github.com/apache/incubator-mxnet/issues/8703
> >
> > If the consensus is towards the direction of dropping python2 support, I
> > suggest we announce our plan to drop python2 support in the next release,
> > and actually drop the support in the next major version. Thanks.
> >
> > -sz
> >
>

Re: assimilation of mshadow into the MXNet codebase

[Anirudh Acharya]

Hi Pedro,

mshadow is mostly used for tensor arithmetic. There have been discussions
about including it within mxnet. I think it is a good idea.

As a more long term solution using libraries like eigen to perform linear
algebra operations was also suggested by anirudh2290@. I think xtensor(
https://github.com/QuantStack/xtensor ) can also be a candidate here.

-
Anirudh


On Fri, Apr 5, 2019 at 7:03 PM Pedro Larroy 
wrote:

> Hi
>
> Some developers have noticed that working in mshadow is cumbersome as
> it's a 3rdparty subrepo.
>
> Since mshadow is a bunch of headers which don't have much of
> independent tests / library functionality, me and other developers
> believe that it would be good to assimilate this code in the
> repository for ease of contribution and changes without having to go
> trough contortions to test PRs that modify mshadow.
>
> Would anybody oppose this change?
>
> Thanks and have a nice weekend.
>
> Pedro.
>

Re: Include R-package

[Anirudh Acharya]

There was a conversation on this some time back here -
https://lists.apache.org/list.html?d...@mxnet.apache.org:2018-12:Rcpp%20licensing%20in%20Apache%20MXNet


-
Anirudh


On Mon, Apr 1, 2019 at 12:19 PM Zach Kimberg 
wrote:

> As part of the current MXNet release process, the R-package is removed from
> the source release [1]. If we are advertising that MXNet has an R package
> as an Apache project, it really should be part of the official Apache
> release process. I know there were a few missing license headers within the
> package as it is currently excluded from the license check [2]. If someone
> fixes those, are there any other reasons why it can't or shouldn't be
> released?
>
> Zach
>
>
>
> [1] - https://cwiki.apache.org/confluence/display/MXNET/Release+Process
> [2] -
>
> https://github.com/apache/incubator-mxnet/blob/master/tests/nightly/apache_rat_license_check/rat-excludes#L9
>

Re: R help

[Anirudh Acharya]

Yes, that is the error, need to dig deeper why that URL is not working.


Thanks
Anirudh


On Mon, Mar 25, 2019 at 10:40 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Is this the error?
> "test_model.R:129: error: Fine-tune
>
> cannot open URL
> 'http://data.dmlc.ml/models/imagenet/inception-bn/Inception-BN-0126.params
> '
> 1: GetInception() at R-package/tests/testthat/test_model.R:129
> 2: download.file("
> http://data.dmlc.ml/models/imagenet/inception-bn/Inception-BN-0126.params
> ",
>destfile = "model/Inception-BN-0126.params")"
>
> Looks like the
> http://data.dmlc.ml/models/imagenet/inception-bn/Inception-BN-0126.params
> is failing for me as well.
>
>
> On Mon, Mar 25, 2019 at 10:37 AM Anirudh Acharya 
> wrote:
>
> > Hi Per da Silva,
> >
> > Let me know if I can help, we can chat offline.
> >
> > From first glance it would seem
> >
> >- R:MKLDNN CPU is passing whereas R:CPU is failing
> >- R:GPU might have failed due to this "cannot open URL '
> >
> >
> http://data.dmlc.ml/models/imagenet/inception-bn/Inception-BN-0126.params
> >'"
> >
> >
> > Thanks
> > Anirudh
> >
> >
> > On Mon, Mar 25, 2019 at 7:34 AM Per da Silva 
> wrote:
> >
> > > Dear community,
> > >
> > > I'm working on a PR <
> > https://github.com/apache/incubator-mxnet/pull/14513>
> > > to update CI GPU jobs to be based on CUDA v10. However, for some
> reason,
> > > amongst other things, the R tests are failing
> > > <
> > >
> >
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-14513/4/pipeline
> > > >.
> > > I would really appreciate some help from the R experts to get it sorted
> > =D
> > >
> > > Thanks in advance,
> > >
> > > Per
> > >
> >
>

Re: R help

[Anirudh Acharya]

Hi Per da Silva,

Let me know if I can help, we can chat offline.

>From first glance it would seem

   - R:MKLDNN CPU is passing whereas R:CPU is failing
   - R:GPU might have failed due to this "cannot open URL '
   http://data.dmlc.ml/models/imagenet/inception-bn/Inception-BN-0126.params
   '"


Thanks
Anirudh


On Mon, Mar 25, 2019 at 7:34 AM Per da Silva  wrote:

> Dear community,
>
> I'm working on a PR 
> to update CI GPU jobs to be based on CUDA v10. However, for some reason,
> amongst other things, the R tests are failing
> <
> http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-14513/4/pipeline
> >.
> I would really appreciate some help from the R experts to get it sorted =D
>
> Thanks in advance,
>
> Per
>

Re: [DISCUSS] Rebrand Gluon to MXNet imperative or something MXNet.

[Anirudh Acharya]

I have also faced this problem, when talking to someone external( at
meetups etc.. ) using two names like gluon and mxnet gets confusing and
people usually have not heard of gluon.

I get around it by referring to gluon as "gluon-mxnet" while talking to
anyone outside the community.


-
Anirudh



On Fri, Mar 22, 2019 at 4:02 PM Pedro Larroy 
wrote:

> Hi dev@
>
> We heard feedback from users that the Gluon name is confusing. Some of
> them don't even know it's MXNet and it's unclear the relationship with
> MXNet
>
> Would it make sense to rebrand Gluon to just MXNet or MXNet
> imperative? Diluting brands and names is never a good idea.
>
> There's also gluonhq which is related to JavaFX which adds to the
> confusion, search engine friendliness is not high as well.
>
> Pedro.
>

HPO for MXNet models

[Anirudh Acharya]

Hi All,

I posted this earlier on the mxnet slack channel, based on a suggestion
there I am reposting it here for a wider audience -

I was searching for ways of performing HPO for models built with MXNet, and
I came across Sherpa, an open source distributed HPO library presented in
NeurIPS 2018 - https://openreview.net/pdf?id=HklSUMyJcQ.

I have been trying it out and it is very easy to use and extensible. It
already supports RandomSearch, Grid Search and BayesianOpt for performing
the search in the hyper-parameter space.

I have submitted a PR with an example gluon use-case -
https://github.com/sherpa-ai/sherpa/pull/27  But I am yet to try it with
large distributed training use cases. But the library does support it, we
can run it in distributed mode for running heavy workloads.

It also comes with a neat UI dashboard to monitor the jobs being run.

[image: Screen Shot 2019-03-13 at 8.08.48 AM.png]

I think we should explore this as an option for performing HPO with gluon.

What might integration entail -
1. I have not fully evaluated what changes might be necessary but I think
the integration can be fairly unobtrusive for both repositories. As
demonstrated above we can already use sherpa for performing HPO, but the
experience is a bit clunky. It can be made smooth by adding a few callback
functions that will track and log the metrics of the different experiment
runs( å la the keras callback function defined here -
https://github.com/sherpa-ai/sherpa/blob/master/sherpa/core.py#L368 )

2. The library is developed and maintained by folks in academia and is
published under GPL license. I was given to understand that GPL license
might be a problem for Apache products, but since we are not explicitly
using it within mxnet as a sub-component, I am thinking we might have some
wiggle room there.

MXNet needs HPO functionality and instead of building something from
scratch we could just use existing open source projects. Would like to hear
more from the community.

Thanks
Anirudh Acharya

Re: Call for Ideas and Approaches to Community Building

[Anirudh Acharya]

Having only non-organization PMC members nominate new committers could
un-level the playing field.
1. Many times contributions might not require a contributor to have direct
1:1 discussion with PMC members outside his org.
2. It would give inordinate power/responsibility to the few non-Amazon
active PMC members.

Just my 2 cents.


Thanks
Anirudh

On Wed, Mar 6, 2019 at 7:10 AM Isabel Drost-Fromm  wrote:

>
>
> Am 2. März 2019 15:13:23 MEZ schrieb Carin Meier :
> >I wanted to kickoff a discussion about community building. There was an
> >excellent blog post from the Apache Beam Community on this
> >https://blogs.apache.org/comdev/entry/an-approach-to-community-building
>
> Needless to say I really love that blog post.
>
> Other than that there are a couple of question you might ask yourself as a
> community:
>
> How easy is it to patriciate as an outsider, how much communication is
> happening outside of dev@?
>
> How explicit are you about how inclusive you want to be? See also
> https://youtu.be/LgB1s3buccI
>
> How explicit are you about where you need help (including and beyond
> coding)?
>
> How explicit are you with downstream users that some of the inner workings
> of Apache projects are build around a scratch your own itch casual
> contributions that ideally should be rewarded the same way as full-time
> contributions (
> https://blogs.apache.org/foundation/entry/success-at-apache-for-love )?
>
> I think you want to enable as many ppl as possible - typically only ten
> percent of your users turn into contributor, of those only ten percent
> trend to be repeat contributors... at least in my experience.
>
> Just some ideas,
> Isabel
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>

Re: [DISCUSS] Process to remove deprecated operators

[Anirudh Acharya]

Hi Lin,

This is a good idea. Here is an issue -
https://github.com/apache/incubator-mxnet/issues/9686 that is already
attempting to collate all the breaking changes that might be necessary for
v2.0. We could start by adding things to that issue.

I think eventually we will need a separate branch into which these breaking
changes get introduced, and this branch can later be merged into master
prior to v2.0 release.

Thanks
Anirudh


On Thu, Feb 28, 2019 at 1:35 PM Wen-Yang Chu  wrote:

> Hi,
>
> I have raised an issue:
>
> mx.nd.Crop does not support FP16 and decpreciated but no direct alternative
> with central crop
> I use this operator to implement Unet and I found other people too on the
> Internent. It is very inconvenient to remove this specific operator
> withoit clear alternative for me:
>
> https://github.com/apache/incubator-mxnet/issues/13750
>
> *Is it possible to review depreciated operators to make sure we have
> equivalent functionality?*
> Thanks
>
> Wen-Yang
>
> On Thu, Feb 28, 2019 at 2:07 PM Chaitanya Bapat 
> wrote:
>
> > This sounds good.
> > Going further, if we can maintain a list of deprecated operators - we can
> > create a "Good for first contribution" issue to improve log messaging of
> > Deprecated operators.
> > If it makes sense, I can go ahead and create that.
> >
> > Hope this helps.
> >
> > On Thu, 28 Feb 2019 at 01:54, Lin Yuan  wrote:
> >
> > > Agreed. When we deprecate an operator, we should add in the log message
> > > something like "This operator X is deprecate and will be removed in the
> > > next release. Please use operator Y instead."
> > >
> > > Lin
> > >
> > > On Wed, Feb 27, 2019 at 10:23 PM Junru Shao 
> > > wrote:
> > >
> > > > Hi Lin,
> > > >
> > > > I would love to share some immature ideas about deprecating
> operators.
> > > Not
> > > > only adopting semantic versioning, but also should we provide enough
> > > > informative error message for customers to understand how to replace
> > > > deprecated operators with new ones.
> > > >
> > > > Thanks,
> > > > Junru
> > > >
> > > > On Wed, Feb 27, 2019 at 9:30 PM Lin Yuan 
> wrote:
> > > >
> > > > > Sheng,
> > > > >
> > > > > Thanks for your quick response.
> > > > > If that's the case, we will wait till 2.0 release to remove the
> > > > deprecated
> > > > > operators from code.
> > > > >
> > > > > Best,
> > > > > Lin
> > > > >
> > > > > On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha 
> > wrote:
> > > > >
> > > > > > MXNet follows semantic versioning so we will be able to delete
> them
> > > in
> > > > > the
> > > > > > next major release.
> > > > > >
> > > > > > -sz
> > > > > >
> > > > > > On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan 
> > > wrote:
> > > > > >
> > > > > > > Dear Community,
> > > > > > >
> > > > > > > In MXNet there are many legacy operators such as this
> > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > > > > > > >
> > > > > > > that has been marked DEPRECATE for several releases. However,
> > these
> > > > > > > operators still exist in our code. This caused a few problems:
> > > > > > >
> > > > > > > 1) Make the codebase bloated and reduce readability
> > > > > > > 2) Increase unnecessary maintanence effort
> > > > > > > 3) Bug prone as some people will look up these legacy code as
> > > example
> > > > > > > 4) Cause confusion to end users and make documentation page
> > lengthy
> > > > > > >
> > > > > > > I would like to propose the following process (if there is no
> > > > existing
> > > > > > one)
> > > > > > > to remove deprecate operators from our code base.
> > > > > > >
> > > > > > > 1. Documnent the deprecate operators/environment variables in
> the
> > > > > release
> > > > > > > note as well as man pages.
> > > > > > > 2. Limit the life cycle of deprecate operators/argument to two
> > > minor
> > > > > > > release. For example, if one operator is marked deprecate in
> 1.4
> > > > > release,
> > > > > > > it will be removed in 1.6 release.
> > > > > > > 3. If there is some concern raised from customers during 1.4
> and
> > > 1.5
> > > > > > > release, we can convert the deprecated operator back to current
> > and
> > > > it
> > > > > > will
> > > > > > > be treated as new operator.
> > > > > > > 4. PRs that remove deprecate operators should contain [Cleanup]
> > in
> > > > > title.
> > > > > > >
> > > > > > > Any comment is appreciated.
> > > > > > >
> > > > > > > Lin
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > *Chaitanya Prakash Bapat*
> > *+1 (973) 953-6299*
> >
> > [image: https://www.linkedin.com//in/chaibapat25]
> > [image:
> https://www.facebook.com/chaibapat
> > ]
> > [image:
> > https://twitter.com/ChaiBapchya]  >[image:
> > https://www.linkedin.com//in/chaibapat25]
> > 

Re: [Announcement] New Committer -- Lin Yuan

[Anirudh Acharya]

Congratulations Lin

On Sat, Feb 2, 2019, 3:27 PM Tianqi Chen  Dear Community:
>
> Please join me to welcome Lin Yuan(@apeforest) as a new committer of
> Apache(incubating) MXNet!
>
> He has contributed to various improvements, including better compatibility
> of larger arrays across the codebase.
>
> Commits:
> https://github.com/apache/incubator-mxnet/commits?author=apeforest
>
> https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+author%3Aapeforest
>
>
> Reviews:
> https://github.com/apache/incubator-mxnet/pulls?utf8=%
> E2%9C%93=reviewed-by%3Aapeforest
>
> dev@ activitivity
> https://lists.apache.org/list.html?*@mxnet.apache.org:lte=6M:Lin%20Yuan
>
> Tianqi
>

Re: [DISCUSS] About the PR merging policy

[Anirudh Acharya]

Thanks Qing for bringing this up. I think the cwiki can contain pointers to
apache guidelines -

   - https://www.apache.org/dev/committers.html
   - https://www.apache.org/dev/new-committers-guide.html
   - And a few thumb rules( not hard and fast rules, we should trust the
   committers to act in good faith in most cases) on how many approvals to
   wait for before merging would be good.

And having these in one place in the cwiki would be convenient.


Thanks
Anirudh



On Fri, Dec 14, 2018 at 11:59 AM Carin Meier  wrote:

> Thanks Steffen,
>
> I had remembered reading that but couldn't find it again :)
>
> So yes - maybe we can duplicate that section and/or provide a link to a new
> committers guide.
>
> I'm thinking it should go on the community page here
> https://cwiki.apache.org/confluence/display/MXNET/Community
>
> Eventually, some of information collected there could migrate out the
> webpage as well.
>
> - Carin
>
> On Thu, Dec 13, 2018 at 7:30 AM Steffen Rochel 
> wrote:
>
> > We do have already a guide which covers the issue:
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Development+Process#DevelopmentProcess-GuidelinesforReviewers/Committers
> > <
> >
> https://cwiki.apache.org/confluence/display/MXNET/Development+Process#DevelopmentProcess-GuidelinesforReviewers/Committers
> > >,
> > but it probably needs to become more prominent. Any suggestion for a good
> > place?
> > Steffen
> >
> > On Wed, Dec 12, 2018 at 5:23 PM Carin Meier 
> wrote:
> >
> > > Qing - thanks for bringing this up.
> > >
> > > I think it would be a good thing to have a document on the wiki to help
> > > with these sorts of questions.
> > >
> > > In fact, since the project is growing with more new committers, maybe
> we
> > > could use a "New Committer Guide" with the process of how to get going
> > and
> > > any FAQ like this one ...
> > >
> > > Would you be interested in getting a rough draft going of your recent
> > > experience? Then others can help collaborate on it.
> > >
> > > It would be nice to make the path smoother for other new committers to
> > the
> > > project.
> > >
> > > Best,
> > > Carin
> > >
> > > On Tue, Dec 11, 2018 at 7:18 PM Qing Lan  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Recently I self-merged my PR without getting approvals from other
> > > > committers https://github.com/apache/incubator-mxnet/pull/13617 and
> > only
> > > > contributors approval. I apologize to the community and thank Marco
> for
> > > > pointing out the problem. I took a lesson that we should at least
> have
> > > one
> > > > committer’s approval to merge the code. However, I just found this
> > > section
> > > > is missing in the CWiki
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
> > > .
> > > > So I would like to discuss in here:
> > > >
> > > > How to conduct the PR reviewing/merging. How many approvals
> (Committers
> > > > and Contributors) we should get in order to merge?
> > > >
> > > > How to deal with disagreement in the discussion (e.g a
> > > > contributor/committer request a change)?
> > > >
> > > > Please don’t hesitate to share your thoughts!
> > > >
> > > > Thanks,
> > > > Qing
> > > >
> > >
> >
>

Re: Rcpp licensing in Apache MXNet

[Anirudh Acharya]

Hi Steffen,

We had a similar discussion with a legal team in Amazon, and we made this
PR - https://github.com/apache/incubator-mxnet/pull/12559 to fix the
licensing issues in the R-package.

I think the R-package should be good to include in the release, but we
should try to get a confirmation once again before we do include it.


Thanks
Anirudh



On Sun, Dec 2, 2018 at 3:22 PM Steffen Rochel 
wrote:

> Hi KK - I'm going through the release checklist
> <
> https://cwiki.apache.org/confluence/display/MXNET/Release+Process#ReleaseProcess-Step1.10.Createartefactsforthereleaseandpushtothedistfolder
> >
> for upcoming v1.4.x release and found the note to remove R-package before
> creating release artifacts. Did we ever get resolution from legal and can
> now include the R-package in the release?
> Appreciate your advice.
>
> Regards,
> Steffen
>
> On Tue, Jul 11, 2017 at 11:49 PM Qiang Kou  wrote:
>
> > Hi, Naveen,
> >
> > I am totally fine if we skip the R pkg for release.
> >
> > Thanks,
> >
> > KK
> >
> > On Tue, Jul 11, 2017 at 8:21 PM, Naveen Swamy 
> wrote:
> >
> > > Ly,
> > >  Can we skip R pkg for the proposed release as KK mentioned and add
> > > it/alter based on the advice we get from ASF legal?
> > >
> > > ---KK Says---
> > > As I understand, if we skip the R pkg when releasing the a new version
> of
> > > MXNet, everything is OK. This is can be done by adding a .gitattribute.
> > > ---
> > >
> > > others,
> > >  thoughts/concerns?
> > >
> > > Thanks, Naveen
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Jul 11, 2017 at 3:56 PM, Ly Nguyen 
> wrote:
> > >
> > > > Hey KK,
> > > >
> > > > I know we're planning a release end of this week/beginning of next
> > week.
> > > It
> > > > may be critical to get this cleared if it is an issue. Eager to hear
> > > back.
> > > > :)
> > > >
> > > > On Tue, Jul 11, 2017 at 3:35 PM, Qiang Kou 
> wrote:
> > > >
> > > > > Hi, Ly,
> > > > >
> > > > > I will let you know when I have the answer.
> > > > >
> > > > > Best,
> > > > >
> > > > > KK
> > > > >
> > > > > On Tue, Jul 11, 2017 at 10:50 AM, Ly Nguyen 
> > > wrote:
> > > > >
> > > > > > Hi @KK, any updates from legal on whether excluding the R pkg is
> a
> > > > > solution
> > > > > > for our next release?
> > > > > >
> > > > > > On Mon, Jul 10, 2017 at 10:49 AM, Qiang Kou 
> > > wrote:
> > > > > >
> > > > > > > Thank you for the info.
> > > > > > >
> > > > > > > As I understand, if we skip the R pkg when releasing the a new
> > > > version
> > > > > of
> > > > > > > MXNet, everything is OK. This is can be done by adding a
> > > > .gitattribute.
> > > > > > >
> > > > > > > I will ask on legal-discuss@ for more info and confirmation.
> > > > > > >
> > > > > > > Really thank you for all the info! It is super helpful.
> > > > > > >
> > > > > > > Best,
> > > > > > >
> > > > > > > KK
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jul 7, 2017 at 8:47 AM, Felix Cheung <
> > > > > felixcheun...@hotmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I was only referring to string_hash_code.c - it's not being
> > built
> > > > and
> > > > > > > it's
> > > > > > > > not part of the binaries release.
> > > > > > > >
> > > > > > > > There are two parts to it.
> > > > > > > >
> > > > > > > > For Spark binaries release, R package is built and the output
> > is
> > > > > > packaged
> > > > > > > > along with the rest of all jars  and python stuff.
> > > > > > > >
> > > > > > > > There is also a source-only R package that we want to publish
> > to
> > > > > CRAN.
> > > > > > > > This contains only R source (no java stuff). CRAN will then
> > build
> > > > > cross
> > > > > > > > platform from that source - but again the part with
> > > > > string_hash_code.c
> > > > > > is
> > > > > > > > disabled.
> > > > > > > >
> > > > > > > > I guess we should have removed string_hash_code.c from source
> > but
> > > > we
> > > > > > are
> > > > > > > > secretly hoping we could sort that out at some point in the
> > > > future..
> > > > > > (ie.
> > > > > > > > building cross platform)
> > > > > > > >
> > > > > > > >
> > > > > > > > _
> > > > > > > > From: Qiang Kou mailto:q...@umail.iu.edu
> >>
> > > > > > > > Sent: Friday, July 7, 2017 8:34 AM
> > > > > > > > Subject: Re: Rcpp licensing in Apache MXNet
> > > > > > > > To: mailto:dev@mxnet.
> > > > > > > incubator.apache.org
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > > Really thank you for the info.
> > > > > > > >
> > > > > > > > Can you tell us a little more on how Spark handles the R
> > package?
> > > > > > > >
> > > > > > > > The building of R package is skipped when releasing, right?
> > > > > > > >
> > > > > > > > Best wishes,
> > > > > > > >
> > > > > > > > KK
> > > > > > > >
> > > > > > > > On Fri, Jul 7, 2017 at 7:41 AM, Felix Cheung <
> > > > > > felixcheun...@hotmail.com<
> > > > > > > > mailto:felixcheun...@hotmail.com>>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Re this
> > > > > > > > >
> > > > > 

Re: A New API for creating .rec files

[Anirudh Acharya]

Hi All,

Sorry for the delay, but here is the design spec for the API -
https://cwiki.apache.org/confluence/display/MXNET/Image+Transforms+and+RecordIO+file+Creation

Look forward to feedback from the community.


Regards
Anirudh


On Tue, Sep 25, 2018 at 2:15 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> This makes a lot of sense to me Anirudh.
>
> On Tue, Sep 25, 2018 at 11:38 AM Anirudh Acharya 
> wrote:
>
> > Hi,
> >
> > During some recent MXNet user surveys, one of the user requests was to
> have
> > a im2rec API that will have similar functionality as the im2rec tool(
> > https://mxnet.incubator.apache.org/faq/recordio.html?highlight=im2rec).
> > The
> > advantage with the API would be that the user can access this
> functionality
> > from the PyPi package itself, instead of cloning the repo.
> >
> > I was thinking of converting the tool into an API call under the mx.io
> > package. I will send the API design shortly. I wanted to know what the
> > community thinks of this change.
> >
> >
> > Thanks
> > Anirudh Acharya
> >
>

Re: [Question] Difference between "Feature" and "Feature request" labels in Github

[Anirudh Acharya]

This issue was raised before here -
https://lists.apache.org/thread.html/3e988e6bd82cb2d69ba20c21bf763952ed22a5732e61f6fba1f89ac8@%3Cdev.mxnet.apache.org%3E

We need someone with committer privileges to fix it.


Thanks
Anirudh



On Tue, Nov 13, 2018 at 4:36 PM Lin Yuan  wrote:

> Dear Community,
>
> I often see there are "Feature" and "Feature request" labels in Github
> issues. May I know the difference? If they are meant to be the same thing,
> can we only keep one of them?
>
> Thanks,
>
> Lin
>

Re: Nightly/Weekly tests for examples

[Anirudh Acharya]

Hi Ankit,

I have a few concerns about testing examples. Before writing tests for
examples,

   - you will need to first decide what constitutes a test for an example,
   because examples are not API calls, which will have return statements and
   the test can just call the API and assert for certain values. Just testing
   if an example is a compilable python script will not add much value in my
   opinion.
   - And testing for example output and results will require a re-write of
   many of the examples, because many of them currently just have print
   statements as outputs and does not return any value as such. I am not sure
   if it is worth the dev-effort.
   - the current set of examples in the mxnet repo are very diverse - some
   are written as python notebooks, some are just python scripts with paper
   implementations, and some are just illustrations of certain mxnet features.
   I am curious to know how you will write tests for these things.


Looking forward to seeing the design of this test bed/framework.


Thanks
Anirudh Acharya

On Fri, Nov 9, 2018 at 2:39 PM Marco de Abreu
 wrote:

> Hello Ankit,
>
> that's a great idea! Using the tutorial tests as reference is a great
> starting point. If you are interested, please don't hesitate to attend the
> Berlin user group in case you would like to discuss your first thoughts
> in-person before drafting a design.
>
> -Marco
>
>
> Am Fr., 9. Nov. 2018, 23:23 hat khedia.an...@gmail.com <
> khedia.an...@gmail.com> geschrieben:
>
> > Hi MXNet community,
> >
> > Recently, I and a few other contributors focussed on fixing examples in
> > our repository which were not working out of the box as expected.
> > https://github.com/apache/incubator-mxnet/issues/12800
> > https://github.com/apache/incubator-mxnet/issues/11895
> > https://github.com/apache/incubator-mxnet/pull/13196
> >
> > Some of the examples failed after API changes and remained uncaught until
> > a user reported the issue. While the community is actively working on
> > fixing it, it might re-occur after few days if we don’t have a proper
> > mechanism to catch regressions.
> >
> > So, I would like to propose to enable nightly/weekly tests for the
> > examples similar to what we have for tutorials to catch any such
> > regressions. The test could check only basic functionalities/working of
> the
> > examples. It can run small examples completely whereas it can run long
> > training examples for only few epochs.
> >
> > Any thoughts from the community? Any other suggestions for fixing the
> same?
> >
> > Regards,
> > Ankit Khedia
> >
>

Re: Run Sphinx checks on MXNet CI

[Anirudh Acharya]

Thanks for the reply Aaron. Once the existing Sphinx errors are fixed and
codebase is cleaned up, lets definitely revisit this and try to add a
Sphinx build into the CI pipeline so that we can prevent MXNet
documentation from breaking.

Thanks
Anirudh

On Thu, Nov 8, 2018 at 5:16 PM Aaron Markham 
wrote:

> Hi Anirudh,
>
> Once the existing errors in docs building are cleaned up, I'm all for
> having CI bubble up a build break when docs are broken by a PR. That
> way we're keeping things up to date and not letting a minor bug turn
> into a serious issue for the entire API documentation. One break
> causes a ripple effect that can go unnoticed and then trying to find
> it is like a needle in a haystack when there are already thousands of
> warnings or errors that are being ignored.
>
> We now have several docs troubleshooting tips in a documentation guide
> thanks to the contributions of @frankfliu, @Roshrini, @vandanavk,
> @vdantu, @vrakesh, and @zachgk.
>
> This documentation guide is published on the developer cwiki:
> https://cwiki.apache.org/confluence/display/MXNET/Documentation+Guide
>
> I plan to continue to add to this guide as more PRs come in that
> exhibit new ways of handling errors or warnings. That way, creating
> docs and troubleshooting any build issues will be much easier.
>
> Please let me know if you have any questions or feedback. You can
> always add that directly to the wiki too.
>
> Cheers,
> Aaron
>
>
> On Thu, Nov 8, 2018 at 11:21 AM Anirudh Acharya 
> wrote:
> >
> > Hi,
> >
> > Recently there was a barrage of issues related to documentation that was
> > raised here -
> > https://github.com/apache/incubator-mxnet/issues/created_by/aaronmarkham
> > All the issues are related to Sphinx errors and warnings. These errors
> > often lead to broken documentation. Ideally such errors should be caught
> > before a PR gets merged, on the CI.
> >
> > Since we use Sphinx to generate the documentation for MXNet, can we have
> > the CI run Sphinx tests on every PR so that we can preempt the problem of
> > broken documentation.
> >
> > Any thoughts from the community? What might be involved to make this
> change
> > to the CI?
> >
> >
> > Regards
> > Anirudh Acharya
>

Run Sphinx checks on MXNet CI

[Anirudh Acharya]

Hi,

Recently there was a barrage of issues related to documentation that was
raised here -
https://github.com/apache/incubator-mxnet/issues/created_by/aaronmarkham
All the issues are related to Sphinx errors and warnings. These errors
often lead to broken documentation. Ideally such errors should be caught
before a PR gets merged, on the CI.

Since we use Sphinx to generate the documentation for MXNet, can we have
the CI run Sphinx tests on every PR so that we can preempt the problem of
broken documentation.

Any thoughts from the community? What might be involved to make this change
to the CI?


Regards
Anirudh Acharya

Re: MXNet - Label Bot functionality

[Anirudh Acharya]

Hi Harsh,

Thanks for working on this. This will be very helpful for people who triage
issues and reviews PRs regularly.

Few concerns from this design document -
https://cwiki.apache.org/confluence/display/MXNET/Machine+Learning+Based+GitHub+Bot
and
the conversation in the comment section

   1. As the scope of the label bot increases, the need for a safety checks
   on who the label bot listens to becomes important. Currently the bot just
   adds labels. You have proposed that the bot also be allowed to remove and
   update labels. And I think allowing the bot to close issues( with a command
   like @mxnet-label-bot close) is in discussion in the comments section. This
   opens up a serious security flaw - anyone who wishes to abuse this system,
   can randomly start closing issues or removing labels. You need to come up
   with a solution so that the bot does not listen to random strangers on the
   internet.
   2. Also you seem to have linked a document that goes to an internal
   amazon website, please remove that.
   [image: Screen Shot 2018-11-01 at 2.31.13 PM.png]


Thanks
Anirudh


On Thu, Oct 18, 2018 at 1:51 PM Harsh Patel 
wrote:

> Hey,
> After having my PR vetted and reviewed by some contributors, I would like
> to move forward into the stage of putting this into production. I am asking
> for MXNet committers to take a look at my PR regarding the Label Bot.
> https://github.com/MXNetEdge/mxnet-infrastructure/pull/15. This will also
> require access for a webhook - let's set this into motion. Thanks.
>
> Best,
> -Harsh
>
> On Mon, Oct 15, 2018 at 4:05 PM Piyush Ghai  wrote:
>
> > Hi Harsh,
> >
> > Good job! This is super cool! Especially bringing down the response time
> > to under 20 seconds.
> >
> > Thanks,
> > Piyush
> >
> >
> > > On Oct 15, 2018, at 3:49 PM, Qing Lan  wrote:
> > >
> > > Hi Harsh,
> > >
> > > This new label bot design looks great! I would like to encourage people
> > to review it and move forward to benefit the MXNet community.
> > > Since this new design needs webhook support from Apache, let's go
> > through the following steps to get this done:
> > >
> > > 1. Demo and contributors review stage: all contributors are encouraged
> > to review the PR here:
> > > https://github.com/MXNetEdge/mxnet-infrastructure/pull/15 and leave
> > your thoughts so Harsh can apply them in his design.
> > > 2. Committers review stage: Once all contributors think the design is
> > good to go, let's get committers involved to get a review.
> > > 3. Committers send request to Apache Infra to get the webhook setup.
> > > 4. Harsh finally deploy the model and all of us can use it in
> > incubator-mxnet repo!
> > >
> > > Some fun fact I would like to share:
> > > 1. This new bot can recommend labels and reply to people who file it!
> > > 2. It response time from 5mins -> less than 20 seconds
> > >
> > > Thanks,
> > > Qing
> > >
> > > On 10/15/18, 11:11 AM, "Harsh Patel" 
> > wrote:
> > >
> > >Hey,
> > >I have a demo available that users and developers can play around
> > with --
> > >this is in regards to the post I had made regarding the updated
> label
> > bot
> > >functionality. This is available on my fork (
> > >https://github.com/harshp8l/incubator-mxnet) if the developers
> would
> > be
> > >able to provide feedback that would be great.
> > >The updated usage of this label bot:
> > >To add labels: @mxnet-label-bot, add ['label1', 'label2']
> > >To remove labels: @mxnet-label-bot, remove ['label1', 'label2']
> > >To update labels: @mxnet-label-bot, update ['label3', 'label4']
> > >(warning: with update - this will remove all other labels for a
> > specific
> > >issue and update only with the labels the user specifies). Thanks.
> > >
> > >My PR for reference:
> > >https://github.com/MXNetEdge/mxnet-infrastructure/pull/15
> > >
> > >My Design:
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Machine+Learning+Based+GitHub+Bot
> > >
> > >Best,
> > >-Harsh
> > >
> > >On Mon, Oct 15, 2018 at 12:54 AM Hagay Lupesko 
> > wrote:
> > >
> > >> +1
> > >> Thanks for the contribution!
> > >>
> > >> On Fri, Oct 12, 2018 at 1:41 AM kellen sunderland <
> > >> kellen.sunderl...@gmail.com> wrote:
> > >>
> > >>> Awesome work!  Many thanks.
> > >>>
> > >>> On Fri, Oct 12, 2018, 1:19 AM Harsh Patel <
> harshpatel081...@gmail.com>
> > >>> wrote:
> > >>>
> >  Hey,
> >  I am looking to contribute to MXNet. I have a working implementation
> > >>> based
> >  on my proposed design structure according to this wiki page (
> > 
> > 
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/MXNET/Machine+Learning+Based+GitHub+Bot
> >  )
> >  - under 7.
> >  I have provided users with functionality allowing for adding,
> > updating,
> > >>> and
> >  deleting labels for our issues. The response time with the bot to
> > >> provide
> >  the aforementioned functionality has been reduced as well. 

A New API for creating .rec files

[Anirudh Acharya]

Hi,

During some recent MXNet user surveys, one of the user requests was to have
a im2rec API that will have similar functionality as the im2rec tool(
https://mxnet.incubator.apache.org/faq/recordio.html?highlight=im2rec). The
advantage with the API would be that the user can access this functionality
from the PyPi package itself, instead of cloning the repo.

I was thinking of converting the tool into an API call under the mx.io
package. I will send the API design shortly. I wanted to know what the
community thinks of this change.


Thanks
Anirudh Acharya

Re: Propose to discontinue supporting Apache MXNet on Windows 7

[Anirudh Acharya]

+1 for discontinuing.

On Tue, Aug 28, 2018 at 4:11 PM Naveen Swamy  wrote:

> +1 to stop supporting Win7
>
> On Tue, Aug 28, 2018 at 3:54 PM Lin Yuan  wrote:
>
> > Dear Community,
> >
> >
> >
> > Currently, our MXNet installation guide for Windows does not work for
> > Windows 7. e.g. Microsoft Visual Studio 2015 is not supported on Windows
> 7
> > <
> >
> https://visualstudio.microsoft.com/vs/support/vs2015/received-error-specified-program-requires-newer-version-windows/
> > >.
> > In addition, MSFT ended “Mainstream” support for Windows 7 in 2015 (
> >
> https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
> > ).
> > Therefore, it is not possible for developers to build MXNet and verify
> the
> > fix on Windows 7 platform. Given that there have been several issues
> about
> > MXNet error on Windows 7 (issue#9271
> > , issue #8921
> > , issue #11163
> > ), it will even
> > add
> > more burden on developers in the future if we were to continue supporting
> > Windows 7.
> >
> >
> >
> > I therefore would like to propose that we discontinue the support of
> MXNet
> > on Windows 7 in the next release.
> >
> >
> > Specifically, this means the following required actions:
> >
> > 1) state the discontinuation of Windows 7 support in the release note
> >
> > 2) update the MXNet webpage if Windows version is mentioned.
> >
> > 3) update the open Github issues related to Windows 7
> >
> >
> > Please share your thoughts about this proposal and/or suggest if there is
> > any other missing action item from the above.
> >
> >
> > Best Regards,
> >
> >
> > Lin
> >
>

Re: Duplication of Operators for sampling from random distributions

[Anirudh Acharya]

Thank for the reply and the clarification, Haibin.

On Tue, Jul 24, 2018 at 2:31 PM Haibin Lin  wrote:

> Hi Anirudh,
>
> Thanks for asking this on dev@. I looked at the doc for sample_uniform and
> random_uniform, and found that the API is different. For sample_uniform,
> the type of arguments `low` and `high` is NDArray, while that of
> random_uniform's is float. I don't think they're going to be deprecated.
>
> The recommended API to generate a random number is via the ndarray.random.*
> or symbol.random.*, which accept both float and NDArray, and under the hood
> invoke either sample_xxx or random_xxx correspondingly.
>
> Best,
> Haibin
>
> On Mon, Jul 23, 2018 at 1:42 PM, Anirudh Acharya 
> wrote:
>
> > Hi All,
> >
> > I had earlier filed an issue with functionality-duplication/code-refactor
> > here - https://github.com/apache/incubator-mxnet/issues/11811
> >
> > As per the suggestion in the github issue I would like to bring it to the
> > attention of the wider community -
> >
> > The operators defined in sample_op.cc and multisample_op.cc are seemingly
> > performing the same tasks. Both these files define the following
> operators
> > respectively
> >
> > sample_op.cc
> > ---
> > random_uniform
> > random_normal
> > random_gamma
> > random_exponential
> > random_poisson
> > random_negative_binomial
> > random_generalized_negative_binomial
> >
> > multisample_op.cc
> > --
> > sample_uniform
> > sample_normal
> > sample_gamma
> > sample_exponential
> > sample_poisson
> > sample_negative_binomial
> > sample_generalized_negative_binomial
> >
> > The only difference that I can glean from the documentation is that
> > operators in multisample_op.ccperforms concurrent sampling from multiple
> > distributions, but the behavior of the operators is not different.
> >
> > Is sample_op.cc being retained for legacy reasons or backward
> > compatibility? Can it be deprecated or EOLed? Correct me if I am wrong
> > here.
> >
> >
> > Thanks
> >
> > Anirudh
> >
>

Re: Publish MXNet images to DockerHub

[Anirudh Acharya]

Yes that would be good. Also I just noticed that in the Installation
instructions page only python has docker image installation instruction
here -
http://mxnet.incubator.apache.org/install/index.html?platform=Linux=Python=CPU
Similar instructions need to be there for other bindings too.

On Tue, Jul 24, 2018 at 4:04 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> I was actually interested in pushing a version of MXNet with TensorRT
> enabled some time in the next few weeks just so that people can experiment
> with the feature without worrying about installing the right protoc and
> onnx versions.  If people here think it's a good idea I can open a PR with
> a runtime-docker folder with the intent that this work could be a template
> for others who want to contribute runtime Dockerfiles?  If a few
> contributors do put together an Dockerfile with TensorRT enabled, would it
> be possible to get that image pushed to the MXNet Dockerhub repo by a
> committer?
>
> On Sun, Jul 22, 2018 at 3:57 PM Anirudh Acharya 
> wrote:
>
> > @Naveen No, I meant in general, for all bindings. Irrespective of whether
> > we use a package management repository, being able to pull an image from
> > docker hub would be convenient for anyone wanting to get started on MXNet
> > or run services( as Kellen said).
> >
> >
> > On Sun, Jul 22, 2018 at 11:20 AM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > I think it's a good idea Anirudh.  It should help users easily get
> MXNet
> > up
> > > and running whether they're running services, following tutorials, etc.
> > >
> > > On Sun, Jul 22, 2018 at 8:10 AM Naveen Swamy 
> wrote:
> > >
> > > > I don't think we need for JVM languages, they have a good dependency
> > > > management through Maven Central. We weren't publishing regularly to
> > > Maven,
> > > > now we do.
> > > >
> > > > Anirudh, I am guessing you are interested docker for R language, If
> > the R
> > > > packages were published to CRAN do you still see a need for docker ?
> > > Could
> > > > you elaborate how this would be helpful and easy if they were to use
> > > other
> > > > packages in CRAN?
> > > >
> > > > On Sat, Jul 21, 2018 at 10:51 PM, Anirudh Acharya <
> > anirudhk...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Yes, correct cu90 is indeed there, thanks for pointing it.
> > > > >
> > > > > So the question, should we be publishing to Docker Hub as part of
> the
> > > > > release process so that bindings other than python are also
> published
> > > and
> > > > > there is a policy on what cuda versions we publish?
> > > > >
> > > > >
> > > > > Thanks
> > > > > ANirudh
> > > > >
> > > > > On Sat, Jul 21, 2018 at 9:56 PM Mu Li  wrote:
> > > > >
> > > > > > cu90 and cu90mkl are also available, see
> > > > > > https://hub.docker.com/r/mxnet/python/tags/
> > > > > >
> > > > > > On Sat, Jul 21, 2018 at 9:51 PM, Anirudh Acharya <
> > > > anirudhk...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > The python binding that is actively maintained is
> > > > > > >
> > > > > > > mxnet-mkl  1.2.1
> > > > > > >
> > > > > > >
> > > > > > > Other versions that use CUDA like mxnet-cu and
> > mxnet-cumkl
> > > > are
> > > > > > not
> > > > > > > actively maintained.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -
> > > > > > >
> > > > > > > Anirudh
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Jul 21, 2018 at 9:09 PM Mu Li 
> > wrote:
> > > > > > >
> > > > > > > > Surprisingly only the python binding is actively maintained.
> I
> > > > > remember
> > > > > > > we
> > > > > > > > can easily push all bindings into docker hub through the
> script
> > > in
> > > > > > > > https://github.com/apache/incubator-mxnet/tree/master/docker
> .
> > > > > > > >
> > > > > > > > On Sat, Jul 21, 2018 at 5:03 PM, Anirudh Acharya <
> > > > > > anirudhk...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Docker Hub( https://hub.docker.com/u/mxnet/ ) currently
> > hosts
> > > > > images
> > > > > > > of
> > > > > > > > > MXNet and its various bindings but it is not actively
> > > maintained.
> > > > > > > Should
> > > > > > > > we
> > > > > > > > > publish MXNet images to Docker Hub as part of the release
> > > process
> > > > > and
> > > > > > > > > actively maintain it?
> > > > > > > > >
> > > > > > > > > The pros of publishing docker images would be ease of use
> and
> > > > > access
> > > > > > to
> > > > > > > > our
> > > > > > > > > users. Is this something that should be included as part of
> > the
> > > > > > release
> > > > > > > > > process? What does the community think?
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Anirudh Acharya
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Duplication of Operators for sampling from random distributions

[Anirudh Acharya]

Hi All,

I had earlier filed an issue with functionality-duplication/code-refactor
here - https://github.com/apache/incubator-mxnet/issues/11811

As per the suggestion in the github issue I would like to bring it to the
attention of the wider community -

The operators defined in sample_op.cc and multisample_op.cc are seemingly
performing the same tasks. Both these files define the following operators
respectively

sample_op.cc
---
random_uniform
random_normal
random_gamma
random_exponential
random_poisson
random_negative_binomial
random_generalized_negative_binomial

multisample_op.cc
--
sample_uniform
sample_normal
sample_gamma
sample_exponential
sample_poisson
sample_negative_binomial
sample_generalized_negative_binomial

The only difference that I can glean from the documentation is that
operators in multisample_op.ccperforms concurrent sampling from multiple
distributions, but the behavior of the operators is not different.

Is sample_op.cc being retained for legacy reasons or backward
compatibility? Can it be deprecated or EOLed? Correct me if I am wrong here.


Thanks

Anirudh

Re: Publish MXNet images to DockerHub

[Anirudh Acharya]

@Naveen No, I meant in general, for all bindings. Irrespective of whether
we use a package management repository, being able to pull an image from
docker hub would be convenient for anyone wanting to get started on MXNet
or run services( as Kellen said).


On Sun, Jul 22, 2018 at 11:20 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> I think it's a good idea Anirudh.  It should help users easily get MXNet up
> and running whether they're running services, following tutorials, etc.
>
> On Sun, Jul 22, 2018 at 8:10 AM Naveen Swamy  wrote:
>
> > I don't think we need for JVM languages, they have a good dependency
> > management through Maven Central. We weren't publishing regularly to
> Maven,
> > now we do.
> >
> > Anirudh, I am guessing you are interested docker for R language, If the R
> > packages were published to CRAN do you still see a need for docker ?
> Could
> > you elaborate how this would be helpful and easy if they were to use
> other
> > packages in CRAN?
> >
> > On Sat, Jul 21, 2018 at 10:51 PM, Anirudh Acharya  >
> > wrote:
> >
> > > Yes, correct cu90 is indeed there, thanks for pointing it.
> > >
> > > So the question, should we be publishing to Docker Hub as part of the
> > > release process so that bindings other than python are also published
> and
> > > there is a policy on what cuda versions we publish?
> > >
> > >
> > > Thanks
> > > ANirudh
> > >
> > > On Sat, Jul 21, 2018 at 9:56 PM Mu Li  wrote:
> > >
> > > > cu90 and cu90mkl are also available, see
> > > > https://hub.docker.com/r/mxnet/python/tags/
> > > >
> > > > On Sat, Jul 21, 2018 at 9:51 PM, Anirudh Acharya <
> > anirudhk...@gmail.com>
> > > > wrote:
> > > >
> > > > > The python binding that is actively maintained is
> > > > >
> > > > > mxnet-mkl  1.2.1
> > > > >
> > > > >
> > > > > Other versions that use CUDA like mxnet-cu and mxnet-cumkl
> > are
> > > > not
> > > > > actively maintained.
> > > > >
> > > > >
> > > > >
> > > > > -
> > > > >
> > > > > Anirudh
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Jul 21, 2018 at 9:09 PM Mu Li  wrote:
> > > > >
> > > > > > Surprisingly only the python binding is actively maintained. I
> > > remember
> > > > > we
> > > > > > can easily push all bindings into docker hub through the script
> in
> > > > > > https://github.com/apache/incubator-mxnet/tree/master/docker.
> > > > > >
> > > > > > On Sat, Jul 21, 2018 at 5:03 PM, Anirudh Acharya <
> > > > anirudhk...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Docker Hub( https://hub.docker.com/u/mxnet/ ) currently hosts
> > > images
> > > > > of
> > > > > > > MXNet and its various bindings but it is not actively
> maintained.
> > > > > Should
> > > > > > we
> > > > > > > publish MXNet images to Docker Hub as part of the release
> process
> > > and
> > > > > > > actively maintain it?
> > > > > > >
> > > > > > > The pros of publishing docker images would be ease of use and
> > > access
> > > > to
> > > > > > our
> > > > > > > users. Is this something that should be included as part of the
> > > > release
> > > > > > > process? What does the community think?
> > > > > > >
> > > > > > > Thanks
> > > > > > > Anirudh Acharya
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Publish MXNet images to DockerHub

[Anirudh Acharya]

Yes, correct cu90 is indeed there, thanks for pointing it.

So the question, should we be publishing to Docker Hub as part of the
release process so that bindings other than python are also published and
there is a policy on what cuda versions we publish?


Thanks
ANirudh

On Sat, Jul 21, 2018 at 9:56 PM Mu Li  wrote:

> cu90 and cu90mkl are also available, see
> https://hub.docker.com/r/mxnet/python/tags/
>
> On Sat, Jul 21, 2018 at 9:51 PM, Anirudh Acharya 
> wrote:
>
> > The python binding that is actively maintained is
> >
> > mxnet-mkl  1.2.1
> >
> >
> > Other versions that use CUDA like mxnet-cu and mxnet-cumkl are
> not
> > actively maintained.
> >
> >
> >
> > -
> >
> > Anirudh
> >
> >
> >
> >
> >
> > On Sat, Jul 21, 2018 at 9:09 PM Mu Li  wrote:
> >
> > > Surprisingly only the python binding is actively maintained. I remember
> > we
> > > can easily push all bindings into docker hub through the script in
> > > https://github.com/apache/incubator-mxnet/tree/master/docker.
> > >
> > > On Sat, Jul 21, 2018 at 5:03 PM, Anirudh Acharya <
> anirudhk...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Docker Hub( https://hub.docker.com/u/mxnet/ ) currently hosts images
> > of
> > > > MXNet and its various bindings but it is not actively maintained.
> > Should
> > > we
> > > > publish MXNet images to Docker Hub as part of the release process and
> > > > actively maintain it?
> > > >
> > > > The pros of publishing docker images would be ease of use and access
> to
> > > our
> > > > users. Is this something that should be included as part of the
> release
> > > > process? What does the community think?
> > > >
> > > > Thanks
> > > > Anirudh Acharya
> > > >
> > >
> >
>

Re: Publish MXNet images to DockerHub

[Anirudh Acharya]

The python binding that is actively maintained is

mxnet-mkl  1.2.1


Other versions that use CUDA like mxnet-cu and mxnet-cumkl are not
actively maintained.



-

Anirudh





On Sat, Jul 21, 2018 at 9:09 PM Mu Li  wrote:

> Surprisingly only the python binding is actively maintained. I remember we
> can easily push all bindings into docker hub through the script in
> https://github.com/apache/incubator-mxnet/tree/master/docker.
>
> On Sat, Jul 21, 2018 at 5:03 PM, Anirudh Acharya 
> wrote:
>
> > Hi,
> >
> > Docker Hub( https://hub.docker.com/u/mxnet/ ) currently hosts images of
> > MXNet and its various bindings but it is not actively maintained. Should
> we
> > publish MXNet images to Docker Hub as part of the release process and
> > actively maintain it?
> >
> > The pros of publishing docker images would be ease of use and access to
> our
> > users. Is this something that should be included as part of the release
> > process? What does the community think?
> >
> > Thanks
> > Anirudh Acharya
> >
>

Publish MXNet images to DockerHub

[Anirudh Acharya]

Hi,

Docker Hub( https://hub.docker.com/u/mxnet/ ) currently hosts images of
MXNet and its various bindings but it is not actively maintained. Should we
publish MXNet images to Docker Hub as part of the release process and
actively maintain it?

The pros of publishing docker images would be ease of use and access to our
users. Is this something that should be included as part of the release
process? What does the community think?

Thanks
Anirudh Acharya

Re: Release plan - MXNET 1.3

[Anirudh Acharya]

@sandeep krishnamurthy  the bug fixes in the
R-package is something we have just begun, there will not be anything
significant to announce before the v1.3 code freeze.

On Wed, Jul 18, 2018 at 10:08 PM Steffen Rochel 
wrote:

> To make it easier to find the discussions related to project proposals I
> added a column with a link to the thread on dev@ for most projects.
> Appreciate for the project owners to fill in the blanks and to check that I
> got the right threads.
>
> Regards,
> Steffen
>
> On Wed, Jul 18, 2018 at 7:11 PM Roshani Nagmote  >
> wrote:
>
> > Hi Kellen,
> >
> > Sure. I will update the notes with the information.
> >
> > Thanks,
> > Roshani
> >
> > On Wed, Jul 18, 2018 at 3:01 PM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > Hey Roshani,
> > >
> > > Would you be able to add 'TensorRT Runtime Integration' to the list of
> > > upcoming features?  We'll target getting the release in and polished by
> > the
> > > 23rd.  Design proposal is here:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Runtime+Integration+with+TensorRT
> > > and the lead contributor is Marek Kolodziej.
> > >
> > > -Kellen
> > >
> > > On Wed, Jul 18, 2018 at 8:32 PM Roshani Nagmote <
> > roshaninagmo...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > I am starting the process to prepare for Apache MXNet (incubating)
> 1.3
> > > > Release. Please find project proposal draft for this release here:
> > > > <*
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
> > > > >*
> > > > >
> > > >
> > > > Target feature freeze date is July 23rd. A release candidate will be
> > cut
> > > > around Monday, August 6th and voting will commence from then until
> > > > Thursday, August 9th. If you have any additional features in progress
> > and
> > > > would like to include it in this release, please make sure to comment
> > so
> > > I
> > > > can update the release notes.
> > > >
> > > > Feel free to add any other comments/suggestions.
> > > >
> > > > Thanks,
> > > > Roshani
> > > >
> > >
> >
>

Re: [VOTE] Subscribe dev@ to Github Activities

[Anirudh Acharya]

+1

On Tue, Jul 17, 2018 at 9:58 AM Anirudh  wrote:

> Its not foregoing transparency since people can easily subscribe to the
> github activities individually. dev@ has been used till now for design
> discussions, other project discussions,
> votes etc. After we subscribe dev@ to all activities, I am afraid dev@
> will
> be reduced to a forwarded mail box and it is redundant for most purposes.
>
> Anirudh
>
> On Tue, Jul 17, 2018 at 9:26 AM, 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
> > > > > <
> https://lists.apache.org/thread.html/3d883f6a3cbc8e81e810962e0c0fe7
> > > > > bfd01f0b78d3cb44034f566442@%3Cdev.mxnet.apache.org%3E>
> > > > > .
> > > > >
> > > > > The vote lasts for three days and ends on 7/18/2018 at 9pm pst.
> > > > >
> > > > > -sz
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Anirudh Acharya]

For concerns regarding signal and noise, I think we can get around that by
setting up the right kind of filters in the mail client.
Signal and Noise can be different for different people.


Regards,
Anirudh

On Thu, Jul 12, 2018 at 3:34 PM Haibin Lin  wrote:

> Agree. +1 for more transparency
>
> On Thu, Jul 12, 2018 at 3:27 PM, Zha, Sheng 
> wrote:
>
> > My intention is really just to bridge the gap between so much happening
> on
> > github v.s. "whatever didn't happen on dev list didn't happen".
> >
> > Also, since dev@ is intended to be an asynchronous way for community to
> > follow technical conversations, there wasn't really a requirement for
> > anyone to read all of them in the first place.
> >
> > Best regards,
> > -sz
> >
> > On 7/12/18, 3:20 PM, "Timur Shenkao"  wrote:
> >
> > Flink - yes
> > Spark - it was previously but not now
> >
> > Yeah, amount of messages would be tripled at least: Jira + Github
> > issue + PR
> >
> > On Thu, Jul 12, 2018 at 11:13 PM, Haibin Lin <
> haibin.lin@gmail.com
> > >
> > wrote:
> >
> > > I'm a bit concerned with the amount of emails flooding in. In the
> > past week
> > > there're 32 new issues and 35 new pull requests. This means on avg
> > 10 email
> > > per day and I doubt I'll read all of them.. Does the Spark
> community
> > > subscribe dev@ to github?
> > >
> > > Best,
> > > Haibin
> > >
> > > On Thu, Jul 12, 2018 at 3:08 PM, Pedro Larroy <
> > > pedro.larroy.li...@gmail.com>
> > > wrote:
> > >
> > > > -1   It's a lot of traffic, whomever wants to subscribe can do it
> > in
> > > > github. I'm afraid it will decrease signal to noise ratio in the
> > list.
> > > >
> > > > On Thu, Jul 12, 2018 at 11:32 PM Lin Yuan 
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya <
> > > anirudhk...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai <
> > ghai.piy...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > > > On Jul 12, 2018, at 11:50 AM, Tianqi Chen <
> > > > tqc...@cs.washington.edu>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha <
> > szha@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi all,
> > > > > > > >>
> > > > > > > >> Should we subscribe dev list to github updates on mxnet
> > repo?
> > > Both
> > > > > > > github
> > > > > > > >> issues/PRs and the dev list are intended for technical
> > > discussions
> > > > > and
> > > > > > > in
> > > > > > > >> that aspect largely share the same goal. Since MXNet has
> > most
> > > > > activity
> > > > > > > >> github, this could help dev@ to become more active.
> Some
> > pros
> > > and
> > > > > > cons:
> > > > > > > >>
> > > > > > > >> Pros:
> > > > > > > >> - There have been many high quality discussions that
> > happen on
> > > > > github
> > > > > > to
> > > > > > > >> which the dev list can benefit.
> > > > > > > >> - Replies on update emails are reflected on the specific
> > > issue/PR.
> > > > > > > >> - Users can also choose to click on the link and go to
> > github to
> > > > > > > >> participate in discussion.
> > > > > > > >> - We still have the ability to carry out dev@ only
> > > conversation.
> > > > > > > >>
> > > > > > > >> Cons:
> > > > > > > >> - Higher volume on dev list.
> > > > > > > >> - Some discussions might not be suitable for dev@.
> > (though I
> > > > can't
> > > > > > > think
> > > > > > > >> of
> > > > > > > >> why such conversation should happen on github either)
> > > > > > > >>
> > > > > > > >> -sz
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
>

Re: [DISCUSS] Subscribe dev@ to Github Activities?

[Anirudh Acharya]

+1

On Thu, Jul 12, 2018 at 11:51 AM Piyush Ghai  wrote:

> +1
> > On Jul 12, 2018, at 11:50 AM, Tianqi Chen 
> wrote:
> >
> > +1
> >
> > On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha  wrote:
> >
> >> Hi all,
> >>
> >> Should we subscribe dev list to github updates on mxnet repo? Both
> github
> >> issues/PRs and the dev list are intended for technical discussions and
> in
> >> that aspect largely share the same goal. Since MXNet has most activity
> >> github, this could help dev@ to become more active. Some pros and cons:
> >>
> >> Pros:
> >> - There have been many high quality discussions that happen on github to
> >> which the dev list can benefit.
> >> - Replies on update emails are reflected on the specific issue/PR.
> >> - Users can also choose to click on the link and go to github to
> >> participate in discussion.
> >> - We still have the ability to carry out dev@ only conversation.
> >>
> >> Cons:
> >> - Higher volume on dev list.
> >> - Some discussions might not be suitable for dev@. (though I can't
> think
> >> of
> >> why such conversation should happen on github either)
> >>
> >> -sz
> >>
>
>

Re: C++ api issue labeling

[Anirudh Acharya]

There is another instance of label duplication - We have labels "Feature" (
https://github.com/apache/incubator-mxnet/labels/Feature ) and "Feature
Request" (
https://github.com/apache/incubator-mxnet/labels/Feature%20request ). I
don't think there is much difference between these two labels.

It would make sense to merge the "Feature" label into "Feature Request".


Thanks
Anirudh


On Wed, Jun 27, 2018 at 3:50 PM Hagay Lupesko  wrote:

> Thank you everyone for your suggestions.
> I will work with a committer to get this updated ASAP.
>
> On Mon, Jun 25, 2018 at 8:55 AM Marco de Abreu
>  wrote:
>
> > +1 to renaming to Backend
> >
> > On Mon, Jun 25, 2018 at 10:13 AM Hagay Lupesko 
> wrote:
> >
> > > Thanks Lin for your feedback.
> > > Bumping again to get more feedback before concluding.
> > >
> > > On Fri, Jun 22, 2018 at 8:53 AM Lin Yuan  wrote:
> > >
> > > > I agree with Hagay. Using "Backend" as label makes it much easier to
> > > track.
> > > >  "C++" label only describes the language used in implementation,
> > > "Backend"
> > > > better describes the nature of the work (let's assume we change the
> > > backend
> > > > implementation from C++ to other languages in the future).
> > > >
> > > > Lin
> > > >
> > > > On Fri, Jun 22, 2018 at 1:09 AM Hagay Lupesko 
> > wrote:
> > > >
> > > > > Thanks everyone for chiming in and clarifying.
> > > > > It seems that the "C++" label name is confusing for our community
> > since
> > > > it
> > > > > can be interpreted as both the CPP API and the backend...
> > > > > As an anecdote, this issue [1
> > > > > ] is
> labeled
> > > as
> > > > > "C++" but is about the CPP API, not the backend.
> > > > >
> > > > > Should we just rename "C++" to "Backend" to avoid confusion?
> > > > >
> > > > > [1] https://github.com/apache/incubator-mxnet/issues/10937
> > > > >
> > > > > On Thu, Jun 21, 2018 at 12:39 PM Pedro Larroy <
> > > > > pedro.larroy.li...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Agree with Anirudh, they are different things. Maybe change the
> > "C++"
> > > > > label
> > > > > > to "backend" would be more informative?
> > > > > >
> > > > > > On Thu, Jun 21, 2018 at 12:11 PM Anirudh 
> > > > wrote:
> > > > > >
> > > > > > > Hi Hagay,
> > > > > > >
> > > > > > > I think we should keep these two labels seperate since they
> mean
> > > > > > different
> > > > > > > things.
> > > > > > > The C++ label refers to the issue for MXNet backend and the CPP
> > > > package
> > > > > > > refers to the CPP language binding for mxnet.
> > > > > > > We can still make C++ API great again irrespective by filtering
> > out
> > > > CPP
> > > > > > > package issues :).
> > > > > > >
> > > > > > > Anirudh
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 21, 2018 at 11:56 AM, Hagay Lupesko <
> > lupe...@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hey community,
> > > > > > > >
> > > > > > > > I was going over the open GitHub issues for MXNet, and
> noticed
> > > that
> > > > > we
> > > > > > > have
> > > > > > > > two labels for the CPP API: "CPP package", "C++"
> > > > > > > >
> > > > > > > > Wanted to suggest we remove "CPP package" and just stick to
> > "C++"
> > > > > > > > This will make it easier for the community to classify issues
> > and
> > > > > focus
> > > > > > > on
> > > > > > > > making the C++ API great again ;)
> > > > > > > >
> > > > > > > > Let me know if someone has any concerns, otherwise I will
> find
> > a
> > > > > > > committer
> > > > > > > > that I can work with to make this change.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > > Hagay
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Release process for R

[Anirudh Acharya]

Hi Marco,

A release process for the R-package would probably involve publishing the
package to CRAN. Currently it is not done and the r-package would need
considerable changes/improvements before it can get published to CRAN.

So at present accessing the package from the S3 bucket is the surest way to
access the R API.


Thanks
Anirudh


On Tue, Jul 3, 2018 at 2:48 AM Marco de Abreu
 wrote:

> Hello,
>
> do we have a release process for our R frontend? I noticed the issue at [1]
> and it seems like we're only publishing to an S3 bucket which is not under
> Apache. Is there another channel for our users to retrieve that package or
> is this our only supported official way?
>
> Best regards,
> Marco
>
> [1] https://github.com/apache/incubator-mxnet/issues/10791
>

Proposed Change to Reshape Operator

[Anirudh Acharya]

Hi All,

With the current Reshape operator in MXNet, it is not possible to reshape
an input array when the shape is generated at runtime. I have created a
github issue describing the problem with examples -
https://github.com/apache/incubator-mxnet/issues/10789

Briefly stated, MXNet should support the usecase where both the input array
and the shape tuple are fed to the "reshape" operator as input arguments.

The proposed solution is to modify the existing reshape_like operator to
accept another boolean parameter called infer_shape. And based on this
parameter we can either infer the shape of second input( as it is done now)
or take the second input as the shape array itself.

Please let me know your comments and feedback.


Regards
Anirudh Acharya

Re: [VOTE] Release Apache MXNet (incubating) version 1.2.0.RC0

[Anirudh Acharya]

/apache/mxnet/KVStoreServer.
> scala:24:
> >> > error: not found: value LoggerFactory
> >> >   private val logger: Logger = LoggerFactory.getLogger(
> >> > classOf[KVStoreServer])
> >> >^
> >> > ./core/src/main/scala/org/apache/mxnet/KVStoreServer.
> scala:49:
> >> > error: not found: type Logger
> >> >   private val logger: Logger = LoggerFactory.getLogger(
> >> > classOf[KVStoreServer])
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/KVStoreServer.
> scala:49:
> >> > error: not found: value LoggerFactory
> >> >   private val logger: Logger = LoggerFactory.getLogger(
> >> > classOf[KVStoreServer])
> >> >^
> >> > ./core/src/main/scala/org/apache/mxnet/Symbol.scala:22:
> error:
> >> > object slf4j is not a member of package org
> >> > import org.slf4j.{Logger, LoggerFactory}
> >> >^
> >> > ./core/src/main/scala/org/apache/mxnet/Symbol.scala:33:
> error:
> >> > not found: type Logger
> >> >   private val logger: Logger = LoggerFactory.getLogger(
> >> > classOf[Symbol])
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/Symbol.scala:33:
> error:
> >> > not found: value LoggerFactory
> >> >   private val logger: Logger = LoggerFactory.getLogger(
> >> > classOf[Symbol])
> >> >^
> >> > ./core/src/main/scala/org/apache/mxnet/Symbol.scala:826:
> error:
> >> > not found: type AddSymbolFunctions
> >> > @AddSymbolFunctions(false)
> >> >  ^
> >> > ./core/src/main/scala/org/apache/mxnet/Symbol.scala:829:
> error:
> >> > not found: value LoggerFactory
> >> >   private val logger = LoggerFactory.getLogger(
> classOf[Symbol])
> >> >^
> >> > ./core/src/main/scala/org/apache/mxnet/IO.scala:23: error:
> >> object
> >> > slf4j is not a member of package org
> >> > import org.slf4j.LoggerFactory
> >> >^
> >> > warning: there was one deprecation warning; re-run with
> >> > -deprecation for details
> >> >     warning: there were 11 feature warnings; re-run with -feature
> for
> >> > details
> >> > model contains 119 documentable templates
> >> > ./core/src/main/scala/org/apache/mxnet/RecordIO.scala:99:
> >> > warning: Tag '@param' must be followed by a symbol name
> >> >   /**
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/RecordIO.scala:99:
> >> > warning: Tag '@param' is not recognised
> >> >   /**
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/module/
> >> BaseModule.scala:365:
> >> > warning: Could not find any member to link for "IOException".
> >> >   /**
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/module/
> >> BaseModule.scala:506:
> >> > warning: Could not find any member to link for "grad1_dev1,".
> >> >   /**
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/module/
> >> BaseModule.scala:488:
> >> > warning: Could not find any member to link for "out1_dev1,".
> >> >   /**
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/module/
> >> BaseModule.scala:204:
> >> > warning: Could not find any member to link for "out1_batch1,".
> >> >   /**
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/module/
> >> > DataParallelExecutorGroup.scala:533: warning: Could not find any
> member
> >> > to link for "grad1_dev1,".
> >> >   /**
> >> >   ^
> >> > ./core/src/main/scala/org/apache/mxnet/module/
> >> > DataParallelExecutorGroup.scala:511: warning: Could not find any
> member
> >> > to link for "out1_dev1,".
> >> >

Re: [VOTE] Release Apache MXNet (incubating) version 1.2.0.RC0

[Anirudh Acharya]

@ThomasDelteil Sorry for the late reply. Yes, it should indeed work when
compiled with mkldnn and cuda.

On Sat, Apr 21, 2018 at 5:15 PM, Thomas DELTEIL <thomas.delte...@gmail.com>
wrote:

> @Anirudh, thanks for looking into it! However I do not understand what you
> mean by 'set as CPU and not GPU'? MXNet compiled with mkldnn and cuda is
> supposed to be able to work with both context no? There are other tutorials
> that are running successfully on both CPU and GPU context.
>
> @Da to reproduce:
>
> Download the source of 1.2.0.rc0 and extract it, cd into it.
>
> make docs
> make clean
> make -j $(nproc) USE_OPENCV=1 USE_BLAS=openblas USE_CUDA=1
> USE_CUDA_PATH=/usr/local/cuda USE_CUDNN=1 USE_MKLDNN=1
> export PYTHONPATH=$(pwd)/python
> cd tests/nightly
> python test_tutorial.py --tutorial onnx/super_resolution
>
> you can also start a jupyter notebook server and try to run
> docs/_build/html/tutorials/onnx/super_resolution.ipynb
>
>
>
> 2018-04-21 15:08 GMT-07:00 Zheng, Da <dzz...@amazon.com>:
>
> > @ThomasDelteil could you show me how to reproduce the problem? I'll take
> > it a look as well.
> >
> > Best,
> > Da
> >
> > Sent from my iPhone
> >
> > On Apr 21, 2018, at 1:12 PM, Anirudh Acharya <anirudhk...@gmail.com
> > <mailto:anirudhk...@gmail.com>> wrote:
> >
> > @ThomasDelteil that might be due to the fact that in the example, the
> > context is being set as CPU and not GPU.
> > But I will still take a look as soon as possible.
> >
> >
> > Regards
> > Anirudh
> >
> > On Sat, Apr 21, 2018 at 11:10 AM, Thomas DELTEIL <
> > thomas.delte...@gmail.com<mailto:thomas.delte...@gmail.com>>
> > wrote:
> >
> > *-0*
> >
> > compiled from source on GPU CUDA/CUDNN, tutorials run fine.
> >
> > However:
> > Compiled from source and adding USE_MKLDNN=1, the onnx/super_resolution
> > tutorial is crashing on this line:
> >
> > ```
> > from collections import namedtuple
> > Batch = namedtuple('Batch', ['data'])
> >
> > # forward on the provided data batch
> > mod.forward(Batch([mx.nd.array(test_image)]))
> > ```
> >
> > Stack trace returned 8 entries:
> > [bt] (0)
> > /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> > mxnet/../../lib/libmxnet.so(dmlc::StackTrace[abi:cxx11]()+0x5b)
> > [0x7feef615721b]
> > [bt] (1)
> > /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> > mxnet/../../lib/libmxnet.so(dmlc::LogMessageFatal::~
> > LogMessageFatal()+0x28)
> > [0x7feef6158258]
> > [bt] (2)
> > /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> > mxnet/../../lib/libmxnet.so(mxnet::engine::ThreadedEngine:
> > :ExecuteOprBlock(mxnet::RunContext,
> > mxnet::engine::OprBlock*)+0xfa9) [0x7feef8b1ad49]
> > [bt] (3)
> > /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> > mxnet/../../lib/libmxnet.so(std::_Function_handler > (std::shared_ptr),
> > mxnet::engine::ThreadedEnginePerDevice::PushToExecute(mxnet::engine::
> > OprBlock*,
> > bool)::{lambda()#1}::operator()()
> > const::{lambda(std::shared_ptr)#1}>::_
> > M_invoke(std::_Any_data
> > const&, std::shared_ptr&&)+0xe2) [0x7feef8b30d82]
> > [bt] (4)
> > /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> > mxnet/../../lib/libmxnet.so(std::thread::_Impl > simple<std::function > (std::shared_ptr)> (std::shared_ptr > ManualEvent>)>
> > ::_M_run()+0x4a) [0x7feef8b2af1a]
> > [bt] (5) /home/ubuntu/anaconda3/bin/../lib/libstdc++.so.6(+0xafc5c)
> > [0x7fef7cc79c5c]
> > [bt] (6) /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fef7dec36ba]
> > [bt] (7) /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fef7dbf941d]
> >
> > Depending on how experimental we consider MKLDNN, that could be a *-1
> *for
> > me.
> >
> > 2018-04-21 9:01 GMT-07:00 Jun Wu <wujun@gmail.com<mailto:wu
> > jun@gmail.com>>:
> >
> > +1
> >
> > Compiled from source. Ran the model quantization example. Both quantized
> > model generation and inference can run successfully.
> >
> > On Fri, Apr 20, 2018 at 5:14 PM, Indhu <indhubhara...@gmail.com > indhubhara...@gmail.com>> wrote:
> >
> > +1
> >
> > Compiled from source on P3 instance. Tested the SSD example and some
> > Gluon
> > examples.
> >
> > On Wed, Apr 18, 2018, 7:40 PM Anirudh <anirudh2...@gmail.com > anirudh2...@gmail.com>> wrote:
> >
> > Hi everyone,
> >
> >

Re: [VOTE] Release Apache MXNet (incubating) version 1.2.0.RC0

[Anirudh Acharya]

@ThomasDelteil that might be due to the fact that in the example, the
context is being set as CPU and not GPU.
But I will still take a look as soon as possible.


Regards
Anirudh

On Sat, Apr 21, 2018 at 11:10 AM, Thomas DELTEIL 
wrote:

> *-0*
>
> compiled from source on GPU CUDA/CUDNN, tutorials run fine.
>
> However:
> Compiled from source and adding USE_MKLDNN=1, the onnx/super_resolution
> tutorial is crashing on this line:
>
> ```
> from collections import namedtuple
> Batch = namedtuple('Batch', ['data'])
>
> # forward on the provided data batch
> mod.forward(Batch([mx.nd.array(test_image)]))
> ```
>
> Stack trace returned 8 entries:
> [bt] (0)
> /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> mxnet/../../lib/libmxnet.so(dmlc::StackTrace[abi:cxx11]()+0x5b)
> [0x7feef615721b]
> [bt] (1)
> /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> mxnet/../../lib/libmxnet.so(dmlc::LogMessageFatal::~
> LogMessageFatal()+0x28)
> [0x7feef6158258]
> [bt] (2)
> /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> mxnet/../../lib/libmxnet.so(mxnet::engine::ThreadedEngine:
> :ExecuteOprBlock(mxnet::RunContext,
> mxnet::engine::OprBlock*)+0xfa9) [0x7feef8b1ad49]
> [bt] (3)
> /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> mxnet/../../lib/libmxnet.so(std::_Function_handler (std::shared_ptr),
> mxnet::engine::ThreadedEnginePerDevice::PushToExecute(mxnet::engine::
> OprBlock*,
> bool)::{lambda()#1}::operator()()
> const::{lambda(std::shared_ptr)#1}>::_
> M_invoke(std::_Any_data
> const&, std::shared_ptr&&)+0xe2) [0x7feef8b30d82]
> [bt] (4)
> /home/ubuntu/apache-mxnet-src-1.2.0.rc0-incubating/python/
> mxnet/../../lib/libmxnet.so(std::thread::_Impl simple (std::shared_ptr ManualEvent>)>
> >::_M_run()+0x4a) [0x7feef8b2af1a]
> [bt] (5) /home/ubuntu/anaconda3/bin/../lib/libstdc++.so.6(+0xafc5c)
> [0x7fef7cc79c5c]
> [bt] (6) /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fef7dec36ba]
> [bt] (7) /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fef7dbf941d]
>
> Depending on how experimental we consider MKLDNN, that could be a *-1 *for
> me.
>
> 2018-04-21 9:01 GMT-07:00 Jun Wu :
>
> > +1
> >
> > Compiled from source. Ran the model quantization example. Both quantized
> > model generation and inference can run successfully.
> >
> > On Fri, Apr 20, 2018 at 5:14 PM, Indhu  wrote:
> >
> > > +1
> > >
> > > Compiled from source on P3 instance. Tested the SSD example and some
> > Gluon
> > > examples.
> > >
> > > On Wed, Apr 18, 2018, 7:40 PM Anirudh  wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > This is a vote to release Apache MXNet (incubating) version 1.2.0.
> > Voting
> > > > will start now (Wednesday, April 18th) and end at 7:40 PM PDT,
> > Saturday,
> > > > April 21st.
> > > >
> > > > Link to the release notes:
> > > >
> > > >
> > > > https://cwiki.apache.org/confluence/display/MXNET/
> > > Apache+MXNet+%28incubating%29+1.2.0+Release+Notes
> > > >
> > > > Link to the release candidate 1.2.0.rc0:
> > > > https://github.com/apache/incubator-mxnet/releases/tag/1.2.0.rc0
> > > >
> > > > View this page, click on “Build from Source”, and use the source code
> > > > obtained from the 1.2.0.rc0 tag:
> > > > https://mxnet.incubator.apache.org/install/index.html
> > > >
> > > > (Note: The README.md points to the 1.2.0 tag and does not work at the
> > > > moment.)
> > > >
> > > > Please remember to TEST first before voting accordingly:
> > > > +1 = approve
> > > > +0 = no opinion
> > > > -1 = disapprove (provide reason)
> > > >
> > > > Thanks,
> > > >
> > > > Anirudh
> > > >
> > >
> >
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.2.0.RC0

[Anirudh Acharya]

+1

Checked the following -

   - source compiles
   - the tests for the onnx import API passes.


Regards
Anirudh


On Thu, Apr 19, 2018 at 1:11 PM, Meghna Baijal 
wrote:

> +1 (non-binding)
>
>
> I Checked the following:
>
> 1. Signatures are ok
>
> 2. Source compiles
>
> 3. mnist test passes
>
>
> Regards,
>
> Meghna
>
> On Thu, Apr 19, 2018 at 10:12 AM, Anirudh  wrote:
>
> > Hi all,
> >
> > Given the weekend, I am extending the vote deadline to Sunday evening,
> > April 22nd 7:40 PM PDT, considering Saturday and Sunday as half days(as
> > done before).
> >
> > Anirudh
> >
> > On Wed, Apr 18, 2018 at 7:40 PM, Anirudh  wrote:
> >
> > > Hi everyone,
> > >
> > > This is a vote to release Apache MXNet (incubating) version 1.2.0.
> Voting
> > > will start now (Wednesday, April 18th) and end at 7:40 PM PDT,
> Saturday,
> > > April 21st.
> > >
> > > Link to the release notes:
> > >
> > > https://cwiki.apache.org/confluence/display/MXNET/
> > > Apache+MXNet+%28incubating%29+1.2.0+Release+Notes
> > >
> > > Link to the release candidate 1.2.0.rc0:
> > > https://github.com/apache/incubator-mxnet/releases/tag/1.2.0.rc0
> > >
> > > View this page, click on “Build from Source”, and use the source code
> > > obtained from the 1.2.0.rc0 tag:
> > > https://mxnet.incubator.apache.org/install/index.html
> > >
> > > (Note: The README.md points to the 1.2.0 tag and does not work at the
> > > moment.)
> > >
> > > Please remember to TEST first before voting accordingly:
> > > +1 = approve
> > > +0 = no opinion
> > > -1 = disapprove (provide reason)
> > >
> > > Thanks,
> > >
> > > Anirudh
> > >
> >
>

Re: blog for MXNet

[Anirudh Acharya]

There is already an AWS Evangelist, Julien Simon, who has quite a few posts
about mxnet/gluon on medium - https://medium.com/@julsimon


Regards
Anirudh

On Wed, Apr 11, 2018 at 3:27 PM, Sebastian Gutierrez <
sebast...@aiworkbox.com> wrote:

> Aaron and Thomas
>
> Great ideas!
>
> One thing worth also considering is something like
>
> https://www.r-bloggers.com/
>
> What it does is serve as a blog aggregation service for all of the people
> who have blogged about r topics. Because of the central repository nature,
> it serves as a natural gathering point and allows people not using RSS (or
> similar technologies) to keep up to date with what is happening.
>
> Another thing worth considering is a job board / site for MXNet full time /
> part time / remote jobs.  The data vis community has this free email list
> service
> https://groups.google.com/forum/m/#!forum/data-vis-jobs that's very
> community friendly and is a good place for people to gather to see job
> needs.
>
> All the best
> Sebastian Gutierrez
>
>
> On Wed, Apr 11, 2018 at 6:10 PM Thomas DELTEIL 
> wrote:
>
> > Thanks Aaron, I like medium, a lot of projects seems to be posting their
> > articles there, as you mentioned.
> >
> > Note that there is a newly created Chinese MXNet blog here:
> > https://zh.mxnet.io/blog/
> >
> > I would be happy to contribute to the blogs, if you want to add me to the
> > writer/editor list.
> >
> >
> >
> > Also, there is a mxnet subreddit r/mxnet which was created by Sebastian
> > (thanks!) and I am now a moderator as well. Feel free to cross-post any
> > interesting content there! https://www.reddit.com/r/mxnet/  Please
> > subscribe!
> >
> >
> > I will try to post one link a day at least, until I run out of links ☺ We
> > will also improve the look of it this week and add links to relevant
> > resources on the side bar, etc.
> >
> >
> >
> > All the best,
> >
> >
> > Thomas
> >
> >
> > 2018-04-11 14:45 GMT-07:00 Aaron Markham :
> >
> > > Having a blog for MXNet would be very useful for conveying news,
> > > talking about features, demoing applications, and building awareness.
> > >
> > > Does anyone have particular preferences or recommendations on blog
> > > hosting or platform?
> > >
> > > I currently have editor access for an MXNet branded account on Medium.
> > > https://medium.com/mxnet
> > >
> > > There's nothing there at the moment, but at least with Medium we all
> > > could get started right away, and have a built-in syndication
> > > platform. Also, note that this is where the TensorFlow blog resides:
> > > https://medium.com/tensorflow
> > >
> > > Please make it known if you'd like to contribute, so you can get
> > > writer/editor access (to whichever platform we settle on.)
> > >
> > > Cheers,
> > > Aaron
> > >
> >
>