Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 JVM Language development (#17783)

2020-07-29 Thread Yuan Tang
This is great discussion. Thanks @lanking520 for initiating this. Perhaps we 
can define some key metrics here so we can compare the solutions later? 

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

Re: Kubeflow support for MXNet deployment

2020-04-06 Thread Yuan Tang
I just added an initial list of adopters of MXNet Operator here:
https://github.com/kubeflow/mxnet-operator/pull/63

*Commnity - If your company uses MXNet Operator, please let me know in the
PR*.

On Mon, Apr 6, 2020 at 9:08 AM Yuan Tang  wrote:

> Definitely. Thanks for asking and I am happy to provide more background.
>
> The MXNet Operator has v1 controller. However, there has no formal release
> on GitHub and it has not been included in Kubeflow by default yet. Though
> users are welcome to use it as a standalone k8s operator. This will
> hopefully be something the community will help drive forward as the initial
> authors are not active. I don't have a good idea of who's using it yet
> externally but I'll start by adding an ADOPTERS.md. *If your company uses
> MXNet Operator, please let me know*. I will post the link to the PR once
> it's ready.
>
> Another easy-to-use option on k8s would be using Horovod + MXNet with 
> *Kubeflow
> MPI Operator* [0] (I just added a section in MXNet's doc on this [1]),
> which already has wide range of industry adopters [2] even though it's
> still in v1alpha2.
>
> I would strongly encourage the community to contribute since the
> ease-of-use on distributed Kubernetes cluster is one perspective to compete
> with and learn from other frameworks. Kubeflow also has tf-operator and
> pytorch-operator which are being used by many companies.
>
> [0] https://github.com/kubeflow/mpi-operator
> [1] https://github.com/apache/incubator-mxnet/pull/17974
> [2]
> https://medium.com/kubeflow/introduction-to-kubeflow-mpi-operator-and-industry-adoption-296d5f2e6edc
>
> On Sun, Apr 5, 2020 at 3:10 PM sandeep krishnamurthy <
> sandeep.krishn...@gmail.com> wrote:
>
>> Thanks for bringing this here to MXNet community Yuan and thank you and
>> other contributors to bring MXNet operator in K8s.
>>
>> It would be very helpful if you can help us to by giving some details
>> about
>> current users of mxnet-operator in K8s or any users experimenting with it.
>> This info about userbase would help me and other committers to prioritize
>> this feature versus other feature requests in MXNet when we get proposals
>> by new members to contribute.
>>
>> Best,
>> Sandeep
>>
>> On Thu, 2 Apr 2020, 7:50 am Yuan Tang,  wrote:
>>
>> > Hi community,
>> >
>> > We are currently looking into adding support for Kubeflow deployment of
>> > MXNet via the existing kubeflow/mxnet-operator:
>> > https://github.com/kubeflow/mxnet-operator. If you are interested in
>> > helping out and getting involved, please let us know in this issue:
>> > https://github.com/kubeflow/kubeflow/issues/4805.
>> >
>> > Cheers,
>> > Yuan
>> >
>> > --
>> > Yuan Tang
>> > https://terrytangyuan.github.io/about/
>> > <https://terrytangyuan.github.io/about/>
>> >
>>
>
>
> --
> Yuan Tang
> https://terrytangyuan.github.io/about/
> <https://terrytangyuan.github.io/about/>
>


-- 
Yuan Tang
https://terrytangyuan.github.io/about/
<https://terrytangyuan.github.io/about/>


Re: Kubeflow support for MXNet deployment

2020-04-06 Thread Yuan Tang
Definitely. Thanks for asking and I am happy to provide more background.

The MXNet Operator has v1 controller. However, there has no formal release
on GitHub and it has not been included in Kubeflow by default yet. Though
users are welcome to use it as a standalone k8s operator. This will
hopefully be something the community will help drive forward as the initial
authors are not active. I don't have a good idea of who's using it yet
externally but I'll start by adding an ADOPTERS.md. *If your company uses
MXNet Operator, please let me know*. I will post the link to the PR once
it's ready.

Another easy-to-use option on k8s would be using Horovod + MXNet with *Kubeflow
MPI Operator* [0] (I just added a section in MXNet's doc on this [1]),
which already has wide range of industry adopters [2] even though it's
still in v1alpha2.

I would strongly encourage the community to contribute since the
ease-of-use on distributed Kubernetes cluster is one perspective to compete
with and learn from other frameworks. Kubeflow also has tf-operator and
pytorch-operator which are being used by many companies.

[0] https://github.com/kubeflow/mpi-operator
[1] https://github.com/apache/incubator-mxnet/pull/17974
[2]
https://medium.com/kubeflow/introduction-to-kubeflow-mpi-operator-and-industry-adoption-296d5f2e6edc

On Sun, Apr 5, 2020 at 3:10 PM sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> Thanks for bringing this here to MXNet community Yuan and thank you and
> other contributors to bring MXNet operator in K8s.
>
> It would be very helpful if you can help us to by giving some details about
> current users of mxnet-operator in K8s or any users experimenting with it.
> This info about userbase would help me and other committers to prioritize
> this feature versus other feature requests in MXNet when we get proposals
> by new members to contribute.
>
> Best,
> Sandeep
>
> On Thu, 2 Apr 2020, 7:50 am Yuan Tang,  wrote:
>
> > Hi community,
> >
> > We are currently looking into adding support for Kubeflow deployment of
> > MXNet via the existing kubeflow/mxnet-operator:
> > https://github.com/kubeflow/mxnet-operator. If you are interested in
> > helping out and getting involved, please let us know in this issue:
> > https://github.com/kubeflow/kubeflow/issues/4805.
> >
> > Cheers,
> > Yuan
> >
> > --
> > Yuan Tang
> > https://terrytangyuan.github.io/about/
> > <https://terrytangyuan.github.io/about/>
> >
>


-- 
Yuan Tang
https://terrytangyuan.github.io/about/
<https://terrytangyuan.github.io/about/>


Kubeflow support for MXNet deployment

2020-04-02 Thread Yuan Tang
Hi community,

We are currently looking into adding support for Kubeflow deployment of
MXNet via the existing kubeflow/mxnet-operator:
https://github.com/kubeflow/mxnet-operator. If you are interested in
helping out and getting involved, please let us know in this issue:
https://github.com/kubeflow/kubeflow/issues/4805.

Cheers,
Yuan

-- 
Yuan Tang
https://terrytangyuan.github.io/about/
<https://terrytangyuan.github.io/about/>


Re: Workflow proposal

2020-03-11 Thread Yuan Tang
Second to not introduce a dev branch. We should try to improve our release
process instead and avoid another branch that may introduce confusion
around the source of truth.

On Wed, Mar 11, 2020 at 8:39 PM Tianqi Chen 
wrote:

> While the idea of staging seems to be reasonable.
> Most OSS projects choose not to do so because having a complicated staging
> will likely confuse the contributors, and increase the change of
> divergence(between dev and master).
>
> Given that we have a release model, so in some sense the release itself
> serves as a staging pt.
> A good approach would simply setup the nightly if necessary strive to fix
> regressions and make sure the formal release addresses the issues.
>
> TQ
>
> On Wed, Mar 11, 2020 at 5:32 PM Pedro Larroy  >
> wrote:
>
> > Hi
> >
> > I talk to some people about this and they thought it would be a good
> idea,
> > so sharing it here:
> >
> > I would propose to use a staging or "dev" branch into which nightly &
> > performance tests are done periodically and then this branch is merged to
> > master. The goal of this workflow would be to avoid having regressions
> and
> > nightly failures creeping into master. PRs would get merged into dev and
> > dev promoted periodically / nightly into master.
> >
> > The names can be swapped as well, between dev and master, so PRS get
> merged
> > into master and it doesn't change the workflow, and staging is the branch
> > where nightly changes are merged to.
> >
> > Have this been considered?
> >
> > Pedro.
> >
>


-- 
Yuan Tang
https://terrytangyuan.github.io/about/ <http://twitter.com/TerryTangYuan>
<https://terrytangyuan.github.io/about/>


Re: [apache/incubator-mxnet] [RFC] MXNet 2.0 JVM Language development (#17783)

2020-03-06 Thread Yuan Tang
I propose option 1 and 2 since it took us a lot of efforts to bring MXNet to 
Scala originally and there are already adopters of Scala API in industries 
(some may not have been disclosed yet). But I am open to other options. Not 
familiar with DJL though but I assume @frankfliu  and @lanking520 are the 
masters behind DJL.

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

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

2020-03-06 Thread Yuan Tang
+1 for "upgrade/rewrite Scala API and bring up MXNet 2.0 features" as it took 
us a lot of efforts to bring MXNet to Scala originally and there are already 
adopters of Scala API in industries.

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

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

2020-03-06 Thread Yuan Tang
I vote for "upgrade/rewrite Scala API and bring up MXNet 2.0 features" as
it took us a lot of efforts to bring MXNet to Scala originally and there
are already adopters of Scala API in industries.

On Fri, Mar 6, 2020 at 11:02 AM Wang Jiajun 
wrote:

> > We may also drop ONNX in MXNet 2. I'm not aware of anyone working on
> ONNX in MXNet and TVM can be used as a replacement.
>
> +1 for keeping ONNX support. Although it has a lot of small problems, but
> I've converted a lot of pytorch models to mxnet for deploying with the
> following pipeline:
>
> https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-onnx-pytorch-mxnet.html
>
> --
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub:
>
> https://github.com/apache/incubator-mxnet/issues/17676#issuecomment-595835658



-- 
Yuan Tang
https://terrytangyuan.github.io/about/ <http://twitter.com/TerryTangYuan>
<https://terrytangyuan.github.io/about/>


List of Adopters of MPI Operator

2020-01-30 Thread Yuan Tang
Hi Apache MXNet community,

We've just added an initial list of adopters of Kubeflow's MPI Operator
here: https://github.com/kubeflow/mpi-operator/blob/master/ADOPTERS.md

I know some of you might be using Horovod + Apache MXNet via MPI Operator
(check out the examples here
) so if your
company would like to be included, please let send us a pull request!

Also feel free to retweet this to help spread the word:
https://twitter.com/TerryTangYuan/status/1222975254420652032:

Best,
Yuan


Re: Stop redistributing source code of 3rdparty dependencies to avoid licensing issues

2020-01-17 Thread Yuan Tang
+1

On Fri, Jan 17, 2020 at 1:59 PM Chris Olivier  wrote:

> +1
>
> On Fri, Jan 17, 2020 at 10:19 AM Lausen, Leonard  >
> wrote:
>
> > Dear MXNet community,
> >
> > as per recent mail on gene...@incubator.apache.org [1] there are a
> number
> > of
> > licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I believe
> > there
> > has been no release so far without any licensing issues, which is a
> > blocker to
> > MXNet graduating from it's incubating status. One contributing factor is
> > that we
> > bundle 3rdparty source code in our releases [2].
> >
> > One key factor is that 3rdparty projects don't always enforce licensing
> > best
> > practice in the way we do. For example, 3rdparty/ps-lite doesn't enforce
> > license
> > headers in the source files and there has been confusion about the
> license
> > of
> > recent contributions by ByteDance (See [1]).
> >
> > To avoid such licensing issues in MXNet releases a simple solution is to
> > stop
> > distributing the 3rdparty code in our source releases. Instead, we can
> > adapt our
> > buildsystem to download 3rdparty code as part of the build configuration
> > process. CMake makes this very easy with the FetchContent module [3].
> >
> > For development purpose involving changes to the 3rdparty source or build
> > systems that can't access the internet, there are easy means for
> > specifying the
> > location of local sources (instead of downloading), via the
> > FETCHCONTENT_SOURCE_DIR_ variable [4].
> >
> > Would there be any concerns about such approach? Obviously it can only be
> > fully
> > implemented as soon as the CMake build system is feature complete and the
> > Makefile build can be dropped. (Note that the Makefile build is being
> > deprecated
> > and removed as part of MXNet 2 roadmap [5])
> >
> > Best regards
> > Leonard
> >
> > [1]:
> >
> >
> https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E
> > [2]: See the .tar.gz files at
> > https://incubator.apache.org/clutch/mxnet.html
> > [3]: https://cmake.org/cmake/help/latest/module/FetchContent.html
> > [4]: https://cmake.org/pipermail/cmake/2019-June/069709.html
> > [5]: https://github.com/apache/incubator-mxnet/issues/16167
> >
>


Re: MXNet 1.6 as last release with Python 2 support?

2020-01-17 Thread Yuan Tang
+1. It's interesting to see that you framed Python 2 and Python 3 as 2
languages.

On Fri, Jan 17, 2020 at 12:43 PM Chaitanya Bapat 
wrote:

> +1
> Taking the advantages into consideration, it makes sense to call off py2
> support from next release onwards.
>
> On Fri, Jan 17, 2020, 9:37 AM Lausen, Leonard 
> wrote:
>
> > Dear MXNet community,
> >
> > as effective January 1, 2020, no new bug reports, fixes, or changes will
> > be made
> > to Python 2, and as MXNet 1.6 will be released after January 1, 2020, I
> > suggest
> > to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last
> > release
> > supporting Python 2.
> >
> > We have previously reached consensus on announcing that Python 2 is
> > dropped in
> > the next major release (ie. MXNet 2), however, given the delay in 1.6
> > release,
> > the plan to release 1.7 in the future and that Python 2 is dead already I
> > think
> > we can revisit this assumption.
> >
> > Advantages are
> > - Time savings for developers, as Python 3 standard library contains more
> >   features than Python 2, and it is more efficient to target only 1
> > language
> >   (Python 3) instead of 2 languages (Python 2 & 3)
> > - Simplification and cost savings for CI
> >
> > I thus suggest 72h lazy consensus for announcing dropping of Python 2 as
> > described above. If you disagree, please veto (send "-1") and we can
> > continue
> > supporting Python 2 in all 1.x releases as per previous consensus. Note
> > that at
> > the time of previous consensus, no 1.7 release was planned.
> >
> > Best regards
> > Leonard
> >
>


Re: new website

2019-08-29 Thread Yuan Tang
I think for now PDF would still be used by a good amount of users since R
users are used to read PDF manual for packages that don't have websites.

Nowadays Github pages + pkgdown combination is getting more and more
popular so we would see a trend soon towards web hosted docs for R
packages.

On Thu, Aug 29, 2019 at 8:58 PM Aaron Markham 
wrote:

> pkgdown makes some nice looking R microsites. Good idea. Do you know
> if many R users would still want the pdf or have things moved to use
> websites for reference like this?
> One of the nice things about the new pipelines for docs is that
> they're not wrapped by Sphinx, so our R contributors will have an
> easier time testing and adding this kind of feature.
>
> On Thu, Aug 29, 2019 at 5:34 PM Yuan Tang  wrote:
> >
> > Thanks for the update, Aaron.
> >
> > Regarding the R docs, one suggestion I have is to use pkgdown package (
> > https://pkgdown.r-lib.org/index.html) to automatically generated the
> > documentation pages (tutorials, API reference, etc.). I've seen huge
> > adoption of this package being used for documentations in the R
> community.
> >
> >
> > On Thu, Aug 29, 2019 at 8:26 PM Aaron Markham  >
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I'm very excited to share a preview and the pull requests for a new
> > > website and new documentation pipelines.
> > >
> > > The following link is using Apache's new staging site setup. It is
> > > built from the new docs publishing pipelines in CI where a Jekyll
> > > website is built, and documentation artifacts from Clojure, CPP, Java,
> > > Julia, Python, R, and Scala are combined into one website.
> > >
> > > https://mxnet-beta.staged.apache.org
> > >
> > > It is the culmination of a lot of effort of several MXNet contributors.
> > >
> > > * A huge shout out goes to Thomas Delteil for the work on the new
> > > Jekyll-backend and beautiful-looking website, and for helping me out
> > > whenever I'd get stuck on revamping the 7 different API docs systems
> > > in CI.
> > > * Soji Adeshina and Vishaal Kapoor both helping me with the system
> > > design for the new docs pipelines.
> > > * Per Goncalves da Silva and Marco de Abreu both helped me with
> > > figuring out CI issues.
> > > * We also ported over Mu Li's beta site for the Python & R APIs which
> > > had many contributors there. Thanks goes to Mu, Ivy Bazan, Jonas
> > > Mueller, Aston Zhang, and Zhi Zhang for their help & contributions. I
> > > apologize in advance if I missed anyone.
> > >
> > > Highlights:
> > >
> > > * R docs are now generated as part of CI. There were issues with R
> > > docs coming from beta repo. They were not reproducible. So I began the
> > > process of creating the pdf doc that is expected by R users as an
> > > alternative. Thomas fixed a CPP bug that was blocking 90% of the docs
> > > from appearing. The R docs are 10x in length compared to the pdf we're
> > > hosting now!
> > >
> > > * Each other API is built in a micro-site fashion. You will notice
> > > that the reference API links will open up the site that is generated
> > > by that language's docs tools. We tried to keep the navigation common
> > > and do this for the Python API. This is something that can be expanded
> > > on for the other APIs in later updates to the website.
> > >
> > > * Each doc set can be generated separately with functions that will
> > > run in Docker and generate the docs artifacts. This means you can now
> > > focus on your preferred API and not have to deal with anything else.
> > >
> > > * Website changes are now much easier. You can serve Jekyll locally,
> > > and have it do incremental updates, so you can see your changes live
> > > without having to build MXNet or anything else. It's a pure front-end
> > > setup.
> > >
> > > * For website publishing, the MXNet binary is built once and then
> > > shared with the other docs generation pipelines.
> > >
> > > * For individual docs runs, you can run a "lite" binary build, then
> > > follow it up with the docs run you want.
> > >
> > > ---
> > >
> > > For example to build MXNet:
> > >
> > > ci/build.py --docker-registry mxnetcidev --platform ubuntu_cpu_lite
> > > /work/runtime_functions.sh build_ubuntu_cpu_docs
> > >
> > > Then to build the R docs:
> > >
> > >

Re: new website

2019-08-29 Thread Yuan Tang
Thanks for the update, Aaron.

Regarding the R docs, one suggestion I have is to use pkgdown package (
https://pkgdown.r-lib.org/index.html) to automatically generated the
documentation pages (tutorials, API reference, etc.). I've seen huge
adoption of this package being used for documentations in the R community.


On Thu, Aug 29, 2019 at 8:26 PM Aaron Markham 
wrote:

> Hi everyone,
>
> I'm very excited to share a preview and the pull requests for a new
> website and new documentation pipelines.
>
> The following link is using Apache's new staging site setup. It is
> built from the new docs publishing pipelines in CI where a Jekyll
> website is built, and documentation artifacts from Clojure, CPP, Java,
> Julia, Python, R, and Scala are combined into one website.
>
> https://mxnet-beta.staged.apache.org
>
> It is the culmination of a lot of effort of several MXNet contributors.
>
> * A huge shout out goes to Thomas Delteil for the work on the new
> Jekyll-backend and beautiful-looking website, and for helping me out
> whenever I'd get stuck on revamping the 7 different API docs systems
> in CI.
> * Soji Adeshina and Vishaal Kapoor both helping me with the system
> design for the new docs pipelines.
> * Per Goncalves da Silva and Marco de Abreu both helped me with
> figuring out CI issues.
> * We also ported over Mu Li's beta site for the Python & R APIs which
> had many contributors there. Thanks goes to Mu, Ivy Bazan, Jonas
> Mueller, Aston Zhang, and Zhi Zhang for their help & contributions. I
> apologize in advance if I missed anyone.
>
> Highlights:
>
> * R docs are now generated as part of CI. There were issues with R
> docs coming from beta repo. They were not reproducible. So I began the
> process of creating the pdf doc that is expected by R users as an
> alternative. Thomas fixed a CPP bug that was blocking 90% of the docs
> from appearing. The R docs are 10x in length compared to the pdf we're
> hosting now!
>
> * Each other API is built in a micro-site fashion. You will notice
> that the reference API links will open up the site that is generated
> by that language's docs tools. We tried to keep the navigation common
> and do this for the Python API. This is something that can be expanded
> on for the other APIs in later updates to the website.
>
> * Each doc set can be generated separately with functions that will
> run in Docker and generate the docs artifacts. This means you can now
> focus on your preferred API and not have to deal with anything else.
>
> * Website changes are now much easier. You can serve Jekyll locally,
> and have it do incremental updates, so you can see your changes live
> without having to build MXNet or anything else. It's a pure front-end
> setup.
>
> * For website publishing, the MXNet binary is built once and then
> shared with the other docs generation pipelines.
>
> * For individual docs runs, you can run a "lite" binary build, then
> follow it up with the docs run you want.
>
> ---
>
> For example to build MXNet:
>
> ci/build.py --docker-registry mxnetcidev --platform ubuntu_cpu_lite
> /work/runtime_functions.sh build_ubuntu_cpu_docs
>
> Then to build the R docs:
>
> ci/build.py --docker-registry mxnetcidev --platform ubuntu_cpu_r
> /work/runtime_functions.sh build_r_docs
>
> There is now a Docker image and a runtime_function for each API
> (except Perl which is built offsite). Python is like this:
>
> ci/build.py --docker-registry mxnetcidev --platform ubuntu_cpu_python
> /work/runtime_functions.sh build_python_docs
>
> The pattern for platform is ubuntu_cpu_{api} and runtime_functions.sh
> is build_{api}_docs.
>
> Further information is on the developer wiki:
> https://cwiki.apache.org/confluence/display/MXNET/Building+the+New+Website
> 
>
> Ok, now this is where YOU come in. We need reviewers and testers.
>
> There are a lot of changes. My original PR was over 1,000 files with
> 83k additions and 55k deletions. So, Thomas broke this up into three
> pull requests that stack.
>
> Step 1 New Content https://github.com/apache/incubator-mxnet/pull/15884
> Step 2 Remove Old Content
> https://github.com/apache/incubator-mxnet/pull/15885
> Step 3 Setup New Jenkins
> https://github.com/apache/incubator-mxnet/pull/15886
>
> For reviewing purposes, start with the new content - what's easily
> visible on the preview website. This is mostly happening in the first
> PR:
> https://github.com/apache/incubator-mxnet/pull/15884
> You can also look at these helper PRs that show you the differences so
> it is easier to review what's happening in Steps 2 and 3. You can
> review these now as well.
> Step 1->2: https://github.com/ThomasDelteil/incubator-mxnet/pull/5
> Step 2->3: https://github.com/ThomasDelteil/incubator-mxnet/pull/6
>
> I really appreciate everyone's support on this effort.
>
> Cheers,
> Aaron
>


Re: [Discuss] MXNet Python < 3.6 Support Deprecation

2019-08-22 Thread Yuan Tang
> > > > >
> > > > > > Seems 3.6 is a reasonable choice.
> > > > > >
> > > > > > On Thu, Jul 18, 2019 at 2:15 PM Marco de Abreu <
> > > > marco.g.ab...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Looking at EOL is certainly a good idea! I think once we
> get closer
> > > > to
> > > > > > > deprecation, we can check adoption statistics to make a
> > > well-informed
> > > > > > > decision that gives us the most advantages without
> dropping the
> > > ball
> > > > > on a
> > > > > > > majority of users (or supporting a branch that is going
> EOL soon).
> > > A
> > > > > > survey
> > > > > > > from 2018 [1] determined the following distribution:
> > > > > > > 3.5: 11%
> > > > > > > 3.6: 54%
> > > > > > > 3.7: 30%
> > > > > > >
> > > > > > > Deprecation for 3.5 is scheduled for 2020-09-13 [2].
> Deprecation
> > > for
> > > > > 3.6
> > > > > > is
> > > > > > > scheduled for 2021-12-23 [2].Deprecation for 3.7 is
> scheduled
> > > > > > > for 2023-06-27 [2].
> > > > > > >
> > > > > > > Following the trend, I'd say that it would be a decision
> between
> > > > Python
> > > > > > 3.6
> > > > > > > and 3.7. Later on, I'd propose to check recent surveys and
> also
> > > have
> > > > a
> > > > > > > separate thread to determine if there's anything we're
> missing
> > > (e.g.
> > > > a
> > > > > > big
> > > > > > > company being unable to use Python 3.7). What do you think?
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Marco
> > > > > > >
> > > > > > > [1]:
> > > >
> https://www.jetbrains.com/research/python-developers-survey-2018/
> > > > > > > [2]:
> https://devguide.python.org/#status-of-python-branches
> > > > > > >
> > > > > > > On Thu, Jul 18, 2019 at 9:42 PM Yuan Tang <
> terrytangy...@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > I would suggest supporting Python 3.5+ since the earlier
> versions
> > > > > have
> > > > > > > > reached end-of-life status:
> > > > > > > >
> https://devguide.python.org/devcycle/#end-of-life-branches
> > > > > > > >
> > > > > > > > On Thu, Jul 18, 2019 at 3:36 PM Pedro Larroy <
> > > > > > pedro.larroy.li...@gmail.com
> > > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > This would simplify CI, reduce costs and more. I think
> a
> > > followup
> > > > > > > > > question is what would be the mininum Python3 version
> > > supported?
> > > > > > > > > Depending on that we might be able to use type
> annotations for
> > > > > > example
> > > > > > > > > or other features.
> > > > > > > > >
> > > > > > > > > Pedro.
> > > > > > > > >
> > > > > > > > > On Thu, Jul 18, 2019 at 12:07 PM Yuan Tang <
> > > > > terrytangy...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > +1
> > > > > > > > > >
> > > > > > > > > > On Thu, Jul 18, 2019 at 2:51 PM Yuxi Hu <
> > > darreny...@gmail.com>
> > > > > > wrote:
> > > > > > > > > >

Re: [Discuss] MXNet Python 2 Support Deprecation

2019-07-18 Thread Yuan Tang
I would suggest supporting Python 3.5+ since the earlier versions have
reached end-of-life status:
https://devguide.python.org/devcycle/#end-of-life-branches

On Thu, Jul 18, 2019 at 3:36 PM Pedro Larroy 
wrote:

> +1
>
> This would simplify CI, reduce costs and more. I think a followup
> question is what would be the mininum Python3 version supported?
> Depending on that we might be able to use type annotations for example
> or other features.
>
> Pedro.
>
> On Thu, Jul 18, 2019 at 12:07 PM Yuan Tang 
> wrote:
> >
> > +1
> >
> > On Thu, Jul 18, 2019 at 2:51 PM Yuxi Hu  wrote:
> >
> > > +1
> > >
> > > On Thu, Jul 18, 2019 at 11:31 AM Tong He  wrote:
> > >
> > > > +1
> > > >
> > > > Best regards,
> > > >
> > > > Tong He
> > > >
> > > >
> > > > Jake Lee  于2019年7月18日周四 上午11:29写道:
> > > >
> > > > > +1
> > > > >
> > > > > On Thu, Jul 18, 2019 at 11:27 AM Junru Shao <
> junrushao1...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Thu, Jul 18, 2019 at 11:12 AM Anirudh Acharya <
> > > > anirudhk...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > On Thu, Jul 18, 2019 at 11:03 AM Marco de Abreu <
> > > > > marco.g.ab...@gmail.com
> > > > > > >
> > > > > > > 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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Yuxi(Darren) Hu, Ph.D.
> > > Software Development Engineer
> > > Amazon Web Services
> > >
>


Re: [Discuss] MXNet Python 2 Support Deprecation

2019-07-18 Thread Yuan Tang
+1

On Thu, Jul 18, 2019 at 2:51 PM Yuxi Hu  wrote:

> +1
>
> On Thu, Jul 18, 2019 at 11:31 AM Tong He  wrote:
>
> > +1
> >
> > Best regards,
> >
> > Tong He
> >
> >
> > Jake Lee  于2019年7月18日周四 上午11:29写道:
> >
> > > +1
> > >
> > > On Thu, Jul 18, 2019 at 11:27 AM Junru Shao 
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Thu, Jul 18, 2019 at 11:12 AM Anirudh Acharya <
> > anirudhk...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Thu, Jul 18, 2019 at 11:03 AM Marco de Abreu <
> > > marco.g.ab...@gmail.com
> > > > >
> > > > > 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Yuxi(Darren) Hu, Ph.D.
> Software Development Engineer
> Amazon Web Services
>


Re: Python2 End of Life

2019-05-13 Thread Yuan Tang
+1

On Mon, May 13, 2019 at 4:37 PM Junru Shao  wrote:

> +1
>
> On Mon, May 13, 2019 at 1:34 PM Aaron Markham 
> wrote:
>
> > +1 for the pledge and to start moving things to Python 3.
> > I think our installation instructions and tutorials can be updated to
> > default to Python3 and we should update Python2-only tutorials. I know
> > we have a handful of those, and when I spot them, I'll create an
> > issue.
> > I can also look at migrating the docs build to Python 3.
> > Should we add a new label for issues relating to migrating to Python3?
> > Cheers,
> > Aaron
> >
> > On Mon, May 13, 2019 at 12:04 PM Zach Kimberg  >
> > wrote:
> > >
> > > Right now, the official date for ending support for Python 2.7 (and all
> > of
> > > python2) is set to January 1 [1]. As part of it, a number of projects
> > have
> > > pledged to drop support for Python2 in or before 2020 including
> > Tensorflow,
> > > requests, pandas, ipython, numpy, pillow, and Cython [2]. I believe we
> > > should also join in this pledge on python3statement.org [2] because it
> > > would help clean up our project and it would be difficult to continue
> > > supporting Python2 anyway when some of our dependencies are dropping
> > > support.
> > >
> > > As a concrete step, we should decide on a date to remove all usages of
> > > Python2 from our CI and consider that officially dropping support.
> > > Following that, we can expect PRs will end up breaking support for
> > Python2.
> > > I suggest just using the same date that Python is dropping support of
> > > January 1. We may also need to update some examples or scripts that
> were
> > > written only for python2 that are around the project. Any thoughts?
> > >
> > > Zach
> > >
> > >
> > > [1] - https://www.python.org/dev/peps/pep-0373/
> > > [2] - https://python3statement.org/
> >
>


Re: [Announcement] New Committer - Zach Kimberg

2019-05-09 Thread Yuan Tang
Welcome!

On Thu, May 9, 2019 at 1:36 PM Marco de Abreu 
wrote:

> Welcome!
>
> Hagay Lupesko  schrieb am Do., 9. Mai 2019, 19:33:
>
> > Congratulations Zach - well deserved!
> >
> > On Thu, May 9, 2019, 13:26 Qing Lan  wrote:
> >
> > > Hi All,
> > >
> > > Please join me in welcoming Zach Kimberg (https://github.com/zachgk)
> as
> > a
> > > new committer.
> > >
> > > He has been solving some important bugs in MXNet JVM with respect to
> > usage
> > > improvement, build issues and a lot more. He also created the Jenkins
> > based
> > > publish pipeline for us to have standard way to build and test
> > > static-linked package conveniently for everyone in the community.
> > Moreover,
> > > he solved a bunch of License problems we have in MXNet and brought
> > several
> > > fixes to let us get 1.4.0 release on time.
> > >
> > > Thanks,
> > > Qing
> > >
> >
>


Re: [Announcement] New Committer - Wang Jiajun

2019-04-25 Thread Yuan Tang
Welcome!

On Thu, Apr 25, 2019 at 2:09 PM Pedro Larroy 
wrote:

> Welcome!
>
> On Tue, Apr 16, 2019 at 6:34 PM kellen sunderland
>  wrote:
> >
> > Welcome!  Very impressed with the work fixing memory leaks so far.
> >
> > On Tue, Apr 16, 2019 at 9:14 AM Carin Meier 
> wrote:
> >
> > > Congrats!
> > >
> > > On Tue, Apr 16, 2019 at 11:58 AM Anirudh Subramanian <
> > > anirudh2...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Please join me to welcome Wang Jiajun (https://github.com/arcadiaphy
> )
> > > as a
> > > > new committer of Apache (incubating) MXNet!
> > > >
> > > > Wang has been solving some tough bugs with respect to memory leaks,
> > > process
> > > > fork handling, dependency engine issues and custom op exception
> handling.
> > > >
> > > > Issue Involvement:
> > > >
> > > >
> > >
> https://github.com/apache/incubator-mxnet/issues?utf8=%E2%9C%93=is%3Aissue+involves%3Aarcadiaphy
> > > >
> > > > PRs authored:
> > > >
> > > >
> > >
> https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+author%3Aarcadiaphy+
> > > >
> > > > Anirudh
> > > >
> > >
>


Re: Changes to MPI-operator

2019-04-15 Thread Yuan Tang
I am cc’ing MXNet dev mailing list here.

Thanks for the note Roshani. Look forward to seeing your contribution!
Though let’s also discuss this in MXNet dev mailing list since other people
(e.g. Carl and Lin) might be working on this as well to avoid duplicate
work.

Best,
Yuan

On Mon, Apr 15, 2019 at 5:51 PM Rong Ou  wrote:

> Sounds great! Yes it would be nice to have some examples for MXNet.
>
> On Mon, Apr 15, 2019 at 3:36 PM Roshani Nagmote 
> wrote:
>
>> Hi,
>>
>> I work on Apache MXNet and recently I used MPI-Operator to run
>> distributed training with MXNet and horovod on Kubernetes.
>> I with few other folks tried to adjust the capacity for a training job
>> based on the available workers and restart the training job from where it
>> left off if any worker goes away in between.
>>
>> To do this, we had to do a few modifications to MPI-operator. For
>> example, updating workerReplicas and launcherRole. Currently, changes are
>> in my repo and I will be making a PR on MPI-operator with these changes.
>> Also, planning to contribute few examples. I wanted to reach out to you
>> first before creating a PR.
>>
>> Please let me know what your thoughts are on this.
>>
>> Thanks,
>> Roshani
>>
>


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

2019-03-22 Thread Yuan Tang
+1

On Fri, Mar 22, 2019 at 7:29 PM Lin Yuan  wrote:

> +1.
>
> Just to give some of my real experience:
> 1) I advertised a recent GluonNLP blog and many responses are "This seems
> nice. So is Gluon a new library to replace MXNet?"
> 2) We visited customers in a unicorn company who showed interests in MXNet
> but none of the engineers knew the relationship between GluonNLP/GluonCV
> and MXNet
> 3) When integrating MXNet to Horovod and adding examples, I received
> comments like "What is Gluon? Is it a new library in addition to MXNet?"
>
> Everyone is talking about PyTorch nowadays, but not Caffe2 anymore although
> the latter is still serving as a backend component. Maybe we should also
> doubledown on one brand?
>
> Lin
>
> 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.
> >
>


Re: [Announcement] New Committer -- Steffen Rochel

2019-02-05 Thread Yuan Tang
Welcome!

On Tue, Feb 5, 2019 at 1:46 PM Gavin M. Bell 
wrote:

> Great news!
>
>
> On Tue, Feb 5, 2019 at 6:16 PM Lin Yuan  wrote:
>
> > Welcome Steffen!
> >
> > Lin
> >
> > On Mon, Feb 4, 2019 at 7:53 PM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > Great news.  Congrats Steffen.
> > >
> > > On Mon, Feb 4, 2019, 5:29 PM Thomas DELTEIL  > > wrote:
> > >
> > > > Welcome Steffen!
> > > >
> > > > On Mon, Feb 4, 2019, 15:55 Marco de Abreu  > > wrote:
> > > >
> > > > > Welcome!
> > > > >
> > > > > Am Di., 5. Feb. 2019, 00:45 hat Chris Olivier <
> > cjolivie...@apache.org>
> > > > > geschrieben:
> > > > >
> > > > > > Dear Community:
> > > > > >
> > > > > > Please join me to welcome Steffen Rochel (
> steffenroc...@gmail.com)
> > > as
> > > > a
> > > > > > new
> > > > > > committer of Apache (incubating) MXNet!
> > > > > >
> > > > > > Steffen has played a role in nearly every MXNet release in the
> past
> > > 18
> > > > > > months, managed several of the wiki pages and has contributed in
> > > > > expanding
> > > > > > the community by managing and hosting meetups in different parts
> of
> > > the
> > > > > > world.
> > > > > >
> > > > > > -Chris
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Sincerely,
> Gavin M. Bell
>
>  "Never mistake a clear view for a short distance."
>   -Paul Saffo
>


Re: [Announcement] New Committer -- Lin Yuan

2019-02-02 Thread Yuan Tang
Welcome Lin!

On Sat, Feb 2, 2019 at 6:27 PM Tianqi Chen  wrote:

> 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: Horovod-MXNet Integration

2019-01-30 Thread Yuan Tang
Hi,

It's great to see MXNet-Horovod integration got merged:
https://github.com/uber/horovod/pull/542

Is there any future plan for this? I've been working on Kubeflow's
MPI-Operator (https://github.com/kubeflow/mpi-operator) lately and it would
be interesting to see an example of using Horovod + MXNet + Kubeflow using
MPI Operator. Feel free to reach out (@terrytangyuan
) if you encounter any issues.

Best,
Yuan


On Fri, Nov 2, 2018 at 6:51 PM Lin Yuan  wrote:

> Hi Mu,
>
> Darren (@yuxihu ) and I have been working on
> releasing MXNet-Horovod integration in production. We have made some
> changes on both MXNet and Horovod sides. The changes on MXNet side have
> mostly been merged and we are working to merge code to horovod repo. We
> will send a design doc to you for review again next week.
>
> Thanks for your feedback,
>
> Lin
>
> On Wed, Oct 31, 2018 at 12:03 PM Mu Li  wrote:
>
> > Thanks for your contribution, Carl.
> >
> > I remember I left a comment on the proposal, but today I found it was
> > disappeared. My suggestion is trying best to not change the existing API.
> > The reason is that we need to change all trainers on the frontend that
> uses
> > the existing kvstore APIs, which may cause confusion to users.
> >
> > The current proposal wants add the following 4 APIs into kvstore:
> >
> >
> >-
> >
> >kv.pushpull
> >-
> >
> >kv.broadcast
> >-
> >
> >kv.local_rank
> >-
> >
> >kv.num_local_workers
> >
> >
> > Pushpull can be done with a sequential push and pull, you can do nothing
> in
> > push and put all workloads into pushpull. Broadcast can be implemented by
> > pull.
> >
> > What's local workers? GPUs in the single machine? If so, we can query it
> > directly.
> >
> >
> > On Fri, Sep 14, 2018 at 4:46 PM Carl Yang  wrote:
> >
> > > Hi,
> > >
> > > Currently, MXNet distributed can only be done using parameter server.
> > > Horovod is an open-source distributed training framework that has
> > > shown 2x speedup compared to TensorFlow using Parameter Server. We
> > > propose to add Horovod support to MXNet. This will help our users
> > > achieve goal of linear scalability to 256 GPUs and beyond. Design
> > > proposal on cwiki:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Horovod-MXNet+Integration
> > >
> > > Please feel free to let me know if you have any suggestions or
> feedback.
> > >
> > > Regards,
> > > Carl
> > >
> >
>


Re: [VOTE] Separating PMC and Committership

2018-11-05 Thread Yuan Tang
+1 (binding)

On Mon, Nov 5, 2018 at 2:05 PM Haibin Lin  wrote:

> Hi Carin,
>
> Thank you very much for driving this forward!
>
> +1
>
> Best,
> Haibin
>
> On Mon, Nov 5, 2018 at 9:54 AM Sebastian  wrote:
>
> > +1 (binding)
> >
> > On 05.11.18 11:29, Carin Meier wrote:
> > > This is a procedural vote on whether to separate the committer and PPMC
> > > levels in the project. The current state is that a user is considered
> as
> > > both a committer and a PPMC member at the same time. This vote is to
> > change
> > > that to be able to invite a person in as a committer separately from a
> > PPMC
> > > member.
> > >
> > > Document reference:
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
> > >
> > > Discussion thread:
> > >
> >
> https://lists.apache.org/thread.html/9c6ecda02e081aa6b689c92badc9dcf05ced6fb3691fd370471773d1@%3Cdev.mxnet.apache.org%3E
> > >
> > > The vote will be a procedural issue vote as defined
> > > https://www.apache.org/foundation/voting.html
> > >
> > > Votes on procedural issues follow the common format of majority rule
> > unless
> > > otherwise stated. That is, if there are more favourable votes than
> > > unfavourable ones, the issue is considered to have passed -- regardless
> > of
> > > the number of votes in each category. (If the number of votes seems too
> > > small to be representative of a community consensus, the issue is
> > typically
> > > not pursued. However, see the description of lazy consensus
> > >  for a
> > > modifying factor.)
> > >
> > > The vote will run until Friday Nov 9th at 6:00 am EST
> > >
> > > Thanks,
> > > Carin
> > >
> >
>


Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

2018-10-29 Thread Yuan Tang
+1

On Mon, Oct 29, 2018 at 7:28 PM Tianqi Chen 
wrote:

> +1
>
> Tianqi
>
> On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:
>
> > This vote is to adopt the document
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > to replace the current document
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> >
> > The dev discussion thread is here
> >
> >
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
> >
> > The vote will be a procedural issue vote as defined
> > https://www.apache.org/foundation/voting.html
> >
> > Votes on procedural issues follow the common format of majority rule
> unless
> > otherwise stated. That is, if there are more favourable votes than
> > unfavourable ones, the issue is considered to have passed -- regardless
> of
> > the number of votes in each category. (If the number of votes seems too
> > small to be representative of a community consensus, the issue is
> typically
> > not pursued. However, see the description of lazy consensus
> >  for a
> > modifying factor.)
> >
> > The vote will run until Friday Nov 2nd at 6:00 am EST
> >
> > Thanks,
> > Carin
> >
>


Re: [DISCUSS] - Revisions to Committer Criteria

2018-10-29 Thread Yuan Tang
On Sun, Oct 28, 2018 at 11:12 PM Naveen Swamy  wrote:

> I added clarifying sections to explicitly call out committers/PMC
> privileges. Please review.
>
> Pasting here for convenience
> Committer Privileges
>
>- Committers have write access to the code repository.
>- Committers have an @apache.org email address.
>- Committers can make short-term decisions for the project, approving
>and merging pull requests.
>- Committer Vote is *NOT* considered *binding* thus the vote you cast do
>not have *Veto* on issues that require consensus.
>- Committer's can request changes on Pull Requests but it does not
>constitute Veto, PMC can agree to approve or reject requested changes.
>
> PMC Privileges
>
>- PMC makes the long-term decisions with regard to the project.
>- PMC members have write access to the code repository.
>- PMC members have @apache.org email address.
>- PMC has access to private@ email list
>- PMC has the right to vote for the community-related decisions, PMC
>Votes are *binding*.
>- PMC has the right to propose active users for committership.
>- PMC must vote on any formal release of the project's software product.
>
Could you clarify on this (I don't think you meant "PMC *must* vote")? How
many votes are required by PMCs before the formal release can happen? Is
this considered community-related decision as well, e.g. PMC vetos are
binding?


>
>
> All, I suggest you review the proposal and if there is any concern please
> voice it here before this goes out for voting.
>
>
> On Sun, Oct 28, 2018 at 8:04 AM Carin Meier  wrote:
>
> > I plan to start a vote on the adopting
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > to
> > replace our current document
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > tomorrow
> > (Monday).
> >
> > - Carin
> >
> > On Thu, Oct 25, 2018 at 8:32 AM Carin Meier 
> wrote:
> >
> > > Thanks for publishing the notes and also thanks everyone for providing
> > > valuable feedback and discussion.
> > >
> > > I encourage everyone that has ideas for improvement to the document to
> > > feel free to edit and revise. If you need a login to the wiki, please
> > just
> > > ask.
> > >
> > > Also, while editing, please keep in mind that the intent is to have a
> > vote
> > > on adopting the new
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > to replace our current document
> > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > > before a vote on separating levels of committer and PPMC as a process.
> > So,
> > > if possible, adopting wording that would work in either outcome of that
> > > vote.
> > >
> > > On the subject of voting, I was thinking of starting a vote on Friday,
> > but
> > > will delay that until the active discussions and revisions are
> complete.
> > >
> > > Best,
> > > Carin
> > >
> > > On Thu, Oct 25, 2018 at 6:39 AM Pedro Larroy <
> > pedro.larroy.li...@gmail.com>
> > > wrote:
> > >
> > >> This is the first hangout that I was able to attend, I liked the
> format
> > >> and
> > >> found them valuable. Thanks for organizing and publishing the notes.
> > >> Looking forward to the next one.
> > >>
> > >> Pedro
> > >>
> > >> On Thu, Oct 25, 2018 at 6:44 AM Steffen Rochel <
> steffenroc...@gmail.com
> > >
> > >> wrote:
> > >>
> > >> > Carin - please see
> > >> >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/MXNET/Hangout+October+24th+2018+8am+and+5pm+PDT
> > >> > :
> > >> > Discussion about committer proposal:
> > >> >
> > >> >- Proposal default should be to have separation between committer
> > and
> > >> >PPMC election
> > >> >- Criteria are vague, should we add some example persona?
> > >> >- Spell out privileges of committer and PPMC member
> > >> >
> > >> >
> > >> > Note: I update the project proposal to address first bullet.
> > >> >
> > >> > Steffen
> > >> >
> > >> >
> > >> > On Wed, Oct 24, 2018 at 11:29 AM Carin Meier 
> > >> wrote:
> > >> >
> > >> > > A request to whoever is taking notes at the MXNet Hangouts that
> are
> > >> > > occurring today. Could you please recap feedback from the meeting
> in
> > >> > > regards to document revisions here for everyone? I would like to
> > >> attend
> > >> > the
> > >> > > session later today, but may not due to family obligations.
> > >> > >
> > >> > > Thanks!
> > >> > > Carin
> > >> > >
> > >> > > On Tue, Oct 23, 2018 at 2:24 PM Steffen Rochel <
> > >> steffenroc...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Carin - I got feedback on my proposal and made changes. I
> > >> incorporated
> > >> > > > Tianqi's suggesiton that we should strive to nominate
> > committer/PPMC
> > >> > > > candidates from outside ones own organization. It should not be
> > >> > > considered
> > >> > 

Re: Request for comments - Keras-MXNet as submodule in MXNet

2018-03-23 Thread Yuan Tang
-1 I don't think this has significant difference. The adoption from
existing Keras users will only come once it's landed in Keras repo. I doubt
that many people will use it unless it's more stable and backward
compatibility is guaranteed.

On Fri, Mar 23, 2018 at 2:54 PM, Naveen Swamy  wrote:

> The proposal is about bringing a forked version of Keras(that works only
> with MXNet) into Apache MXNet repo submodule that way MXNet gets more
> eyeballs from existing Keras users and eventually Gluon, etc., , like
> Sandeep mentioned Keras has a large user base which MXNet could tap into.
>
> On Fri, Mar 23, 2018 at 11:50 AM, Yao Wang 
> wrote:
>
> > -1 Creating Keras as submodule of MXNet will provide users a feeling that
> > MXNet depends on Keras. Keras is a frontend library which can be
> supported
> > by various different backend framework. It would be better to add backend
> > framework as Keras's submodule(Keras depends on MXNet) rather than
> > opposite.
> >
> > Best,
> > Yao
> >
> > 2018-03-23 11:44 GMT-07:00 Xingjian SHI :
> >
> > > -1. I think we should wait until it's merged into keras-team/keras. The
> > > repo is still not mature enough.
> > >
> > >
> > > Best,
> > >
> > > Xingjian
> > >
> > >
> > > 
> > > From: sandeep krishnamurthy 
> > > Sent: Friday, March 23, 2018 1:49 PM
> > > To: dev@mxnet.incubator.apache.org
> > > Subject: Request for comments - Keras-MXNet as submodule in MXNet
> > >
> > > Hello MXNet Community,
> > >
> > > Along with Lai, Karan and other MXNet contributors, I am working on
> > adding
> > > MXNet backend for Keras. Currently supporting around ~70% of Keras APIs
> > > across CNNs and RNNs.
> > > https://github.com/deep-learning-tools/keras/tree/keras2_mxnet_backend
> > > [https://avatars0.githubusercontent.com/u/32447491?s=400=4] > > github.com/deep-learning-tools/keras/tree/keras2_mxnet_backend>
> > >
> > > deep-learning-tools/keras > > tools/keras/tree/keras2_mxnet_backend>
> > > github.com
> > > keras - Deep Learning library for Python. Runs on TensorFlow, Theano,
> or
> > > CNTK.
> > >
> > >
> > >
> > >
> > > We wanted to gather the community feedback on the proposal for
> including
> > > this keras-mxnet package as a submodule in Apache MXNet. This will
> enable
> > > providing the Keras interface for MXNet users. MXNet users can choose
> > Keras
> > > interface for building their Neural Networks in Symbolic Mode (Ex:
> > > mx.keras).
> > >
> > > *Advantages:*
> > >
> > > 1. Keras is widely popular interface that many DL practitioners are
> > > familiar. By including keras interface within MXNet natively, we enable
> > > many users to use MXNet with 0 learning curve.
> > >
> > > 2.  Adding as submodule and exposing natively within MXNet pip package,
> > > would greatly enhance user experience and get more users as compared to
> > > releasing a fork repository independently.
> > >
> > > 3. Why submodule? - Helps in easily managing with patching the latest
> > > parent keras-team/keras developments and releases. Thereby helping us
> > > provide users the core keras experience. Operational management.
> > >
> > > 4. Other minor advantages - Operational maintenance, pip, CI and
> quality
> > > control.
> > >
> > > Please do share your comments on the proposal.
> > >
> > > Best,
> > > Sandeep
> > >
> > > *Note: *We tried merging with keras-team/keras and we created a PR
> > >  as well. However, due
> to
> > > multiple design incompatibility challenges, we need significant re-work
> > on
> > > MXNet Module, KVStore, Optimizers to address keras-team design
> concerns.
> > > Since, we are adhering to keras API interface exposed to users, we are
> > > planning release on the forked repo for now. More details on the design
> > > challenges and workaround tried -
> > > https://docs.google.com/document/d/1Vn5ip5MzCKcN29KCCnwjB2d59y-
> > > VevdLrdn_eNd3nE4/edit?usp=sharing
> > >
> >
>


Re: [VOTE] Disconnect all non-C API's from mxnet versioning

2018-03-12 Thread Yuan Tang
+1

On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> +1
>
> Tianqi Chen  schrieb am Mo., 12. März 2018,
> 17:33:
>
> > +1
> >
> > On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier 
> > wrote:
> >
> > > It has been proposed that all Non-C API's follow separate versioning
> from
> > > the main mxnet C API/releases.
> > >
> > > A +1 vote is in *favor of* using a different versioning for all
> > > non-C-API's, with each API (Scala, R, Julia, C++, etc.) having its own
> > > version.
> > >
> > > A -1 vote is *against* using a different versioning for all
> non-C-API's,
> > > with all API's (Scala, R, Julia, C++, etc.) sharing the mxnet version.
> > >
> > > This vote will conclude on Monday, March 19, 2018.
> > >
> > > Thanks,
> > > -Chris
> > >
> >
>


Re: JIRA notifications on dev@

2018-02-06 Thread Yuan Tang
+1 please disable the notifications

On Tue, Feb 6, 2018 at 8:09 PM Haibin Lin  wrote:

> +1 to disable automatic notifications to dev@.
>
> On Tue, Feb 6, 2018 at 5:05 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com
> > wrote:
>
> > Haha, we need to have a discussion here first before we can make the
> > change. I'd like the opinion of the community on this one.
> >
> > -Marco
> >
> > On Tue, Feb 6, 2018 at 5:04 PM, Chris Olivier 
> > wrote:
> >
> > > Please feel free to submit a ticket to Infra to get the emails
> disabled.
> > >
> > > Oh yeah...  If we do that, they send us nasty emails...
> > >
> > > Waiting for Sebastian to file a ticket (I pinged on Slack).
> > >
> > >
> > > On Tue, Feb 6, 2018 at 5:00 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com
> > > > wrote:
> > >
> > > > Hello,
> > > >
> > > > while I highly appreciate the usage of JIRA within MXNet, I guess
> that
> > > I'm
> > > > not the only one bothered by the high number of JIRA notifications on
> > > dev@
> > > > .
> > > > While everybody has the chance to create a filter for these message,
> > I'm
> > > > afraid that new developers and people viewing the archive are getting
> > > > pretty frustrated as actual conversations are pushed to the side by
> all
> > > the
> > > > communication happening on the JIRA tickets (see [1]). Therefor, I'd
> > > > propose one of the following solutions:
> > > >
> > > > 1. Disable JIRA notifications to dev@ entirely, leading to only the
> > > people
> > > > subscribed to a ticket being notified directly.
> > > > 2. Create a separate email list for JIRA in the same way as [2].
> > > >
> > > > Best regards,
> > > > Marco
> > > >
> > > > [1]: https://lists.apache.org/list.html?d...@mxnet.apache.org
> > > > [2]: https://lists.apache.org/list.html?comm...@mxnet.apache.org
> > > >
> > >
> >
>


Re: Proposal for treating warnings as errors in Linux & Clang builds (-Werror)

2018-01-15 Thread Yuan Tang
+1

On Mon, Jan 15, 2018 at 8:02 PM Ziyue Huang  wrote:

> +1 since warnings might be potential errors. In my perspective, an
> excellent project is better to have 0 warnings.
>
> Chris Olivier 于2018年1月16日 周二上午2:27写道:
>
> > If enabled, it should only cause errors in Release builds, since having
> > warnings in WIP code is not unusual.
> >
> > In addition, different developers use different gcc/clang versions. Some
> > gcc versions, for instance, generate warnings where others do not.  It
> > would not be fair to render unbuildable a developer who is using a newer
> > (or older) gcc version is different from CI.  Can this argument be tied
> to
> > a particular compiler/platform/version?
> >
> > On Mon, Jan 15, 2018 at 9:43 AM, Marco de Abreu <
> > marco.g.ab...@googlemail.com> wrote:
> >
> > > +1
> > >
> > > On Mon, Jan 15, 2018 at 6:27 PM, Pedro Larroy <
> > > pedro.larroy.li...@gmail.com>
> > > wrote:
> > >
> > > > Hi
> > > >
> > > > I would like to propose to compile in CI with warnings as errors for
> > > > increased code quality. This has a dual purpose:
> > > >
> > > > 1. Enforce a clean compilation output. Warnings often indicate
> > > > deficiencies in the code and hide new warnings which can be an
> > > > indicator of problems.
> > > >
> > > > 2. Warnings can surface bugs as has happened before.
> > > >
> > > > While this might be impractical in all architectures, I would propose
> > > > having the Linux and Clang build run without warnings in CI.
> > > >
> > > > I think we are very close to this as I personally have been fixing
> > > > warnings in Linux and OSX / Clang.
> > > >
> > > > References:
> > > >
> > > > https://github.com/apache/incubator-mxnet/pull/9398
> > > >
> > > > http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/
> > > > incubator-mxnet/detail/PR-9398/1/pipeline
> > > >
> > > > Pedro.
> > > >
> > >
> >
>


Re: Join the slack channel

2018-01-05 Thread Yuan Tang
Apologize. Please ignore my last email that I replied to dev email instead
of individual.

Rand - let’s chat offline.

On Fri, Jan 5, 2018 at 7:25 PM Yuan Tang <terrytangy...@gmail.com> wrote:

> Hey there! Does Uptake uses MXNet nowadays?
>
> On Fri, Jan 5, 2018 at 7:05 PM Rand Xie <randxiexy...@gmail.com> wrote:
>
>> Hi,
>>
>> I would like to join the slack channel and contribute my knowledge to the
>> mxnet project. Please let me know how to get the invitation link.
>>
>> Best regards,
>> Yuyang Xie
>>
>


Re: Join the slack channel

2018-01-05 Thread Yuan Tang
Hey there! Does Uptake uses MXNet nowadays?

On Fri, Jan 5, 2018 at 7:05 PM Rand Xie  wrote:

> Hi,
>
> I would like to join the slack channel and contribute my knowledge to the
> mxnet project. Please let me know how to get the invitation link.
>
> Best regards,
> Yuyang Xie
>


Re: Stop automated message from Apache Git Service

2017-07-28 Thread Yuan Tang
This is quite annoying. Could anyone please change this?

On Fri, Jul 28, 2017 at 4:25 PM Dom Divakaruni 
wrote:

> Can we please do this?
>
> @Lnx2
>
>
> > On Jul 28, 2017, at 12:53 PM, Daniel Pono Takamori 
> wrote:
> >
> > We just transferred the mxnet repo to the Apache Organization, that's
> > what's causing the increased mail to dev@mxnet.  There needs to be a
> > log for all events on Github, and as such these are sent to the dev@
> > list.  If there is consensus in moving the mail to another list
> > (creating another is possible by the PMC [0]) then please file an
> > Infra JIRA ticket [1].
> >
> > Cheers,
> > Pono from Infra
> >
> > [0] - https://whimsy.apache.org/officers/mlreq
> > [1] - https://issues.apache.org/jira/projects/INFRA/summary
> >
> >> On Fri, Jul 28, 2017 at 12:46 PM, Yutian Li 
> wrote:
> >> I noticed the emails are sent to a mailing list. So it can't be turned
> >> off for a single person unless I quit the mailing list?
> >>
> >>> On Fri, Jul 28, 2017 at 12:38 PM, Yutian Li 
> wrote:
> >>> Hi,
> >>>
> >>> Is it possible to stop automated message for every pull request or
> >>> issue to a repo that is linked on GitHub?
> >>>
> >>> I'm receiving these emails from g...@git.apache.org
> >>>
> >>> Thanks,
> >>> Yutian
>


Re: [Vote] New MXNet Logo

2017-03-04 Thread Yuan Tang
+1

On Sat, Mar 4, 2017 at 11:38 PM, Nan Zhu  wrote:

> +1
>
> Get Outlook for iOS 
>
> --
> *From:* Joseph Spisak 
> *Sent:* Saturday, March 4, 2017 9:07:54 PM
> *To:* d...@mxnet.apache.org
> *Subject:* [Vote] New MXNet Logo
>
>
> Let's vote on a new MXNet logo.  Thoughts on this one?
>
>  [ ] +1; Yep, love it!
>
>  [ ] -1; Hate it, because 
>
>
>