Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Sergio Fernández]

Happy to help.

On Fri, Jun 22, 2018, 21:40 Chris Olivier  wrote:

> thank you for the explanation
>
> On Fri, Jun 22, 2018 at 9:25 PM Sergio Fernández 
> wrote:
>
> > No, the result at dev@ it's fine. You just need 3 binding votes together
> > in
> > the two votes (dev@mxnet and general@incubator).
> >
> > (sorry fot the other email I sent by mistake)
> >
> > On Fri, Jun 22, 2018, 21:21 Anirudh  wrote:
> >
> > > Does PMC in this page mean IPMC :
> > > https://www.apache.org/foundation/voting.html#ReleaseVotes ?
> > > Also, does this mean we need three IPMC votes to pass this release on
> dev
> > > list ?
> > >
> > > Anirudh
> > >
> > > On Fri, Jun 22, 2018 at 9:15 PM, Sergio Fernández 
> > > wrote:
> > >
> > > > Just wanted to refresh what
> > > > https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes
> > > says:
> > > > "The only time when a PPMC member’s vote is binding is for the
> addition
> > > of
> > > > new PPMC members and committers. Release votes are only binding to
> IPMC
> > > > members.".
> > > >
> > > > So it's incorrect to mark as binding those votes at the RESULT email.
> > > >
> > > >
> > > > On Fri, Jun 22, 2018, 17:38 Chris Olivier 
> > wrote:
> > > >
> > > > > what do you mean? just curious.
> > > > >
> > > > > On Fri, Jun 22, 2018 at 4:44 PM Sergio Fernández <
> wik...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Please, notice PPMC votes are not binding.
> > > > > >
> > > > > > On Fri, Jun 22, 2018, 09:35 Anirudh 
> wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Apologies for replying instead of sending out a new email.
> > > > > > >
> > > > > > > This vote has passed with 6 +1s:
> > > > > > >
> > > > > > > Binding:
> > > > > > > Sandeep
> > > > > > > Haibin
> > > > > > > Indhu
> > > > > > >
> > > > > > > Non Binding:
> > > > > > > Carin
> > > > > > > Pedro
> > > > > > > Lai
> > > > > > >
> > > > > > > I will proceed with the vote on general@.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Anirudh
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Chris Olivier]

thank you for the explanation

On Fri, Jun 22, 2018 at 9:25 PM Sergio Fernández  wrote:

> No, the result at dev@ it's fine. You just need 3 binding votes together
> in
> the two votes (dev@mxnet and general@incubator).
>
> (sorry fot the other email I sent by mistake)
>
> On Fri, Jun 22, 2018, 21:21 Anirudh  wrote:
>
> > Does PMC in this page mean IPMC :
> > https://www.apache.org/foundation/voting.html#ReleaseVotes ?
> > Also, does this mean we need three IPMC votes to pass this release on dev
> > list ?
> >
> > Anirudh
> >
> > On Fri, Jun 22, 2018 at 9:15 PM, Sergio Fernández 
> > wrote:
> >
> > > Just wanted to refresh what
> > > https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes
> > says:
> > > "The only time when a PPMC member’s vote is binding is for the addition
> > of
> > > new PPMC members and committers. Release votes are only binding to IPMC
> > > members.".
> > >
> > > So it's incorrect to mark as binding those votes at the RESULT email.
> > >
> > >
> > > On Fri, Jun 22, 2018, 17:38 Chris Olivier 
> wrote:
> > >
> > > > what do you mean? just curious.
> > > >
> > > > On Fri, Jun 22, 2018 at 4:44 PM Sergio Fernández 
> > > > wrote:
> > > >
> > > > > Please, notice PPMC votes are not binding.
> > > > >
> > > > > On Fri, Jun 22, 2018, 09:35 Anirudh  wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Apologies for replying instead of sending out a new email.
> > > > > >
> > > > > > This vote has passed with 6 +1s:
> > > > > >
> > > > > > Binding:
> > > > > > Sandeep
> > > > > > Haibin
> > > > > > Indhu
> > > > > >
> > > > > > Non Binding:
> > > > > > Carin
> > > > > > Pedro
> > > > > > Lai
> > > > > >
> > > > > > I will proceed with the vote on general@.
> > > > > >
> > > > > > Thanks,
> > > > > > Anirudh
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Sergio Fernández]

No, the result at dev@ it's fine. You just need 3 binding votes together in
the two votes (dev@mxnet and general@incubator).

(sorry fot the other email I sent by mistake)

On Fri, Jun 22, 2018, 21:21 Anirudh  wrote:

> Does PMC in this page mean IPMC :
> https://www.apache.org/foundation/voting.html#ReleaseVotes ?
> Also, does this mean we need three IPMC votes to pass this release on dev
> list ?
>
> Anirudh
>
> On Fri, Jun 22, 2018 at 9:15 PM, Sergio Fernández 
> wrote:
>
> > Just wanted to refresh what
> > https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes
> says:
> > "The only time when a PPMC member’s vote is binding is for the addition
> of
> > new PPMC members and committers. Release votes are only binding to IPMC
> > members.".
> >
> > So it's incorrect to mark as binding those votes at the RESULT email.
> >
> >
> > On Fri, Jun 22, 2018, 17:38 Chris Olivier  wrote:
> >
> > > what do you mean? just curious.
> > >
> > > On Fri, Jun 22, 2018 at 4:44 PM Sergio Fernández 
> > > wrote:
> > >
> > > > Please, notice PPMC votes are not binding.
> > > >
> > > > On Fri, Jun 22, 2018, 09:35 Anirudh  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Apologies for replying instead of sending out a new email.
> > > > >
> > > > > This vote has passed with 6 +1s:
> > > > >
> > > > > Binding:
> > > > > Sandeep
> > > > > Haibin
> > > > > Indhu
> > > > >
> > > > > Non Binding:
> > > > > Carin
> > > > > Pedro
> > > > > Lai
> > > > >
> > > > > I will proceed with the vote on general@.
> > > > >
> > > > > Thanks,
> > > > > Anirudh
> > > > >
> > > >
> > >
> >
>

Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Sergio Fernández]

I've replied in another thread to

On Fri, Jun 22, 2018, 21:21 Anirudh  wrote:

> Does PMC in this page mean IPMC :
> https://www.apache.org/foundation/voting.html#ReleaseVotes ?
> Also, does this mean we need three IPMC votes to pass this release on dev
> list ?
>
> Anirudh
>
> On Fri, Jun 22, 2018 at 9:15 PM, Sergio Fernández 
> wrote:
>
> > Just wanted to refresh what
> > https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes
> says:
> > "The only time when a PPMC member’s vote is binding is for the addition
> of
> > new PPMC members and committers. Release votes are only binding to IPMC
> > members.".
> >
> > So it's incorrect to mark as binding those votes at the RESULT email.
> >
> >
> > On Fri, Jun 22, 2018, 17:38 Chris Olivier  wrote:
> >
> > > what do you mean? just curious.
> > >
> > > On Fri, Jun 22, 2018 at 4:44 PM Sergio Fernández 
> > > wrote:
> > >
> > > > Please, notice PPMC votes are not binding.
> > > >
> > > > On Fri, Jun 22, 2018, 09:35 Anirudh  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Apologies for replying instead of sending out a new email.
> > > > >
> > > > > This vote has passed with 6 +1s:
> > > > >
> > > > > Binding:
> > > > > Sandeep
> > > > > Haibin
> > > > > Indhu
> > > > >
> > > > > Non Binding:
> > > > > Carin
> > > > > Pedro
> > > > > Lai
> > > > >
> > > > > I will proceed with the vote on general@.
> > > > >
> > > > > Thanks,
> > > > > Anirudh
> > > > >
> > > >
> > >
> >I
>

Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Anirudh]

Does PMC in this page mean IPMC :
https://www.apache.org/foundation/voting.html#ReleaseVotes ?
Also, does this mean we need three IPMC votes to pass this release on dev
list ?

Anirudh

On Fri, Jun 22, 2018 at 9:15 PM, Sergio Fernández  wrote:

> Just wanted to refresh what
> https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes says:
> "The only time when a PPMC member’s vote is binding is for the addition of
> new PPMC members and committers. Release votes are only binding to IPMC
> members.".
>
> So it's incorrect to mark as binding those votes at the RESULT email.
>
>
> On Fri, Jun 22, 2018, 17:38 Chris Olivier  wrote:
>
> > what do you mean? just curious.
> >
> > On Fri, Jun 22, 2018 at 4:44 PM Sergio Fernández 
> > wrote:
> >
> > > Please, notice PPMC votes are not binding.
> > >
> > > On Fri, Jun 22, 2018, 09:35 Anirudh  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Apologies for replying instead of sending out a new email.
> > > >
> > > > This vote has passed with 6 +1s:
> > > >
> > > > Binding:
> > > > Sandeep
> > > > Haibin
> > > > Indhu
> > > >
> > > > Non Binding:
> > > > Carin
> > > > Pedro
> > > > Lai
> > > >
> > > > I will proceed with the vote on general@.
> > > >
> > > > Thanks,
> > > > Anirudh
> > > >
> > >
> >
>

Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Chris Olivier]

what does “binding” mean in this context?

On Fri, Jun 22, 2018 at 9:15 PM Sergio Fernández  wrote:

> Just wanted to refresh what
> https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes says:
> "The only time when a PPMC member’s vote is binding is for the addition of
> new PPMC members and committers. Release votes are only binding to IPMC
> members.".
>
> So it's incorrect to mark as binding those votes at the RESULT email.
>
>
> On Fri, Jun 22, 2018, 17:38 Chris Olivier  wrote:
>
> > what do you mean? just curious.
> >
> > On Fri, Jun 22, 2018 at 4:44 PM Sergio Fernández 
> > wrote:
> >
> > > Please, notice PPMC votes are not binding.
> > >
> > > On Fri, Jun 22, 2018, 09:35 Anirudh  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Apologies for replying instead of sending out a new email.
> > > >
> > > > This vote has passed with 6 +1s:
> > > >
> > > > Binding:
> > > > Sandeep
> > > > Haibin
> > > > Indhu
> > > >
> > > > Non Binding:
> > > > Carin
> > > > Pedro
> > > > Lai
> > > >
> > > > I will proceed with the vote on general@.
> > > >
> > > > Thanks,
> > > > Anirudh
> > > >
> > >
> >
>

Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Sergio Fernández]

Just wanted to refresh what
https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes says:
"The only time when a PPMC member’s vote is binding is for the addition of
new PPMC members and committers. Release votes are only binding to IPMC
members.".

So it's incorrect to mark as binding those votes at the RESULT email.


On Fri, Jun 22, 2018, 17:38 Chris Olivier  wrote:

> what do you mean? just curious.
>
> On Fri, Jun 22, 2018 at 4:44 PM Sergio Fernández 
> wrote:
>
> > Please, notice PPMC votes are not binding.
> >
> > On Fri, Jun 22, 2018, 09:35 Anirudh  wrote:
> >
> > > Hi all,
> > >
> > > Apologies for replying instead of sending out a new email.
> > >
> > > This vote has passed with 6 +1s:
> > >
> > > Binding:
> > > Sandeep
> > > Haibin
> > > Indhu
> > >
> > > Non Binding:
> > > Carin
> > > Pedro
> > > Lai
> > >
> > > I will proceed with the vote on general@.
> > >
> > > Thanks,
> > > Anirudh
> > >
> >
>

RE: Project Proposal for fused CPU RNN OPs to the release 1.3

[Zhao, Patric]

Hello Steffen,

Really thanks to look into our proposal. I totally understand your concern that 
the quality is the most important thing.
We will pay much attention on it.

Regarding RNN Ops, the new OP provides about 2-3X performance boost (the 
performance section of proposal).
Most importantly, it makes the gluon RNN/NLP model can be hybridized to 
symbolic models in both CPU and GPU
(previously it only works on GPU w/o the fused CPU Ops).
For the correctness, the unit tests was added w/ the PR and we also tested the 
accuracy with the real cases. 
I will update the doc with more information about the correctness and our 
experiment results.

Regarding MKL-DNN integration,  the issues (bugs and some corner cases) has 
gradually emerged along with more users switching to it. 
Absolutely, it is really important to make it stable and we really care about 
this.
Zheng Da, Alex and our team are working on the known issues and have already 
fixed lots of them. 
Furthermore, a bunch of unit test, including gluon, symbolic, CPP cases, are 
added to cover more situations.
Obviously, the MKL-DNN backend trends to more complete and robust. We hope to 
upgrade it to GA in the 1.3.

Finally, I think we need some patience for the new features and incubate it to 
the mature.

Thanks for your suggestions again.

--Patric

> -Original Message-
> From: Steffen Rochel [mailto:steffenroc...@gmail.com]
> Sent: Friday, June 22, 2018 10:45 PM
> To: dev@mxnet.incubator.apache.org
> Cc: Lv, Tao A ; Li, Hao H ; Ye,
> Jason Y ; Emani, Ashok 
> Subject: Re: Project Proposal for fused CPU RNN OPs to the release 1.3
> 
> Thanks Patric, appreciate  your contributions. I looked at your design
> proposal. I'm missing any statements about validation of correctness and
> performance of the integrated solution. I would suggest to pay more
> attention to this aspect as we struggled in previously releases with the
> quality of the integration. As you know, we still have too many issues on
> MKL-DNN integration to move from experimental to GA stage.
> Regards,
> Steffen
> 
> On Thu, Jun 21, 2018 at 12:09 AM Zhao, Patric 
> wrote:
> 
> > Hi MXNET owner,
> >
> > Recently, we (Intel engineers) have implemented the fused RNN
> > operations
> > (LSTM/GRU/vRNN) for the CPU, including bidirectional, multiple layers,
> > inference/training.
> > The LSTM and GRU PR was merged and vRNN code will be PR soon.
> >
> > The new APIs make the gluon and symbolic models much faster :)
> >
> > Thus, I have added a new row in the 1.3 proposal table and hope the
> > end user can leverage the new feature easily.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+fo
> > r+next+MXNet+Release
> >
> > Feel free to let me know for any feedbacks and suggestions.
> >
> > BR,
> >
> > Thanks,
> >
> > --Patric
> >
> >

Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Chris Olivier]

what do you mean? just curious.

On Fri, Jun 22, 2018 at 4:44 PM Sergio Fernández  wrote:

> Please, notice PPMC votes are not binding.
>
> On Fri, Jun 22, 2018, 09:35 Anirudh  wrote:
>
> > Hi all,
> >
> > Apologies for replying instead of sending out a new email.
> >
> > This vote has passed with 6 +1s:
> >
> > Binding:
> > Sandeep
> > Haibin
> > Indhu
> >
> > Non Binding:
> > Carin
> > Pedro
> > Lai
> >
> > I will proceed with the vote on general@.
> >
> > Thanks,
> > Anirudh
> >
>

Re: [RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Sergio Fernández]

Please, notice PPMC votes are not binding.

On Fri, Jun 22, 2018, 09:35 Anirudh  wrote:

> Hi all,
>
> Apologies for replying instead of sending out a new email.
>
> This vote has passed with 6 +1s:
>
> Binding:
> Sandeep
> Haibin
> Indhu
>
> Non Binding:
> Carin
> Pedro
> Lai
>
> I will proceed with the vote on general@.
>
> Thanks,
> Anirudh
>

Re: landing pages for the website

[Steffen Rochel]

Hi Aaron - support Mu's suggestion to add an ecosystems page to add links
to MXNet related projects (gluon toolkits, mxnet model server, keras, onnx,
sockeye etc) to promote the solutions in the MXNet ecosystem. What do you
suggest as next steps?
Steffen

On Mon, Jun 11, 2018 at 5:19 PM Mu Li  wrote:

> Thanks for the proposal, Aaron. The landing page idea is great. I feel we
> should group MXNet topics into landing pages, such as Gluon you mentioned,
> also performance, and deployment. But I'm less sure if we want to add too
> many contents from 3rd party projects into MXNet, otherwise, it may make
> the MXnet docs have too many dependencies and hard to maintain. We may just
> create an "ecosystem" page to add links to all high-quality 3rd party
> libraries.
>
> On Mon, Jun 11, 2018 at 5:11 PM, Aaron Markham 
> wrote:
>
> > Hi dev@,
> > We've had a lot of great expansions to MXNet's functionality and family
> of
> > tools in recent months. I would like to gauge the temp on what would be
> > good to highlight, and what would be good as navigation items with actual
> > landing pages.
> >
> > For example, when ONNX was added, being in a contrib package, it was
> going
> > to totally buried, so it has a navigation item under Docs and a landing
> > page with some usage details. This page could certainly be enhanced, or
> > there could also be a landing page for it in the docs folder.
> > https://mxnet.incubator.apache.org/api/python/contrib/onnx.html
> >
> > Gluon needs a new landing page, and could probably be folded into the
> Docs
> > navigation. Why landing pages? We shouldn't have navigation items that
> take
> > you off of the site without warning. Github would be an exception. But
> for
> > books and tutorials suites that are off-deck, I think it would be a good
> > habit to describe what it is and indicate where it goes. The tutorials
> page
> > has this notion with little icons now.
> >
> > The new Scala infer package will be buried once it rolls off of the new
> > highlights section of the home page. Maybe we should have navigation
> items
> > for things like model serving and inference along with landing pages for
> > each?
> >
> > Then we have a couple of projects outside MXNet, but directly add value,
> > and could be highlighted with a landing page to describe what it does,
> how
> > to install it, plus links to the projects and some examples:
> >
> > * MXNet Model Server
> > * Keras-MXNet
> >
> > I'm sure there's more. Let's discuss and promote all these good things.
> >
> > Cheers,
> > Aaron
> >
>

[RELEASE][VOTE] Release MXNet version 1.2.1.RC0

[Anirudh]

Hi all,

Apologies for replying instead of sending out a new email.

This vote has passed with 6 +1s:

Binding:
Sandeep
Haibin
Indhu

Non Binding:
Carin
Pedro
Lai

I will proceed with the vote on general@.

Thanks,
Anirudh

Re: [VOTE] Release MXNet version 1.2.1.RC0 (Patch Release)

[Anirudh]

Hi all,

Thanks a lot for checking the release. This vote has passed with:

6 +1s

Binding:
Sandeep
Haibin
Indhu

Non Binding:
Carin
Pedro
Lai

Anirudh


On Fri, Jun 22, 2018 at 8:00 AM, sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> +1
>
> Lai (https://github.com/roywei) and myself tested with Keras-MXNet for CNN
> and RNN standard use cases, things are working as expected on CPU and GPU.
>
> Best,
> Sandeep
>
> On Thu, Jun 21, 2018 at 11:06 PM Anirudh  wrote:
>
> > Hi all,
> >
> > Thanks for checking the release. We need one more binding +1. I would
> > request committers to help out here so that we can get the vote started
> on
> > general@.
> >
> > Anirudh
> >
> > On Thu, Jun 21, 2018 at 3:06 PM, Pedro Larroy <
> > pedro.larroy.li...@gmail.com>
> > wrote:
> >
> > > I already changed my vote to +1   I don't think this a big issue, just
> a
> > > pixel difference of 1 when loading an image.
> > >
> > >
> > >
> > > On Thu, Jun 21, 2018 at 2:20 PM Marco de Abreu
> > >  wrote:
> > >
> > > > We had 868 successful runs and no failures for that test so far,
> Pedro.
> > > >
> > > > On Thu, Jun 21, 2018 at 11:17 PM Pedro Larroy <
> > > > pedro.larroy.li...@gmail.com>
> > > > wrote:
> > > >
> > > > > Observed just one failure in OSX in test_imdecode:
> > > > >
> > > > >
> > > > >
> > ==
> > > > > FAIL: test_imdecode (test_image.TestImage)
> > > > >
> > --
> > > > > Traceback (most recent call last):
> > > > >   File
> > > > >
> > > > >
> > > > "/Users/pllarroy/devel/mxnet/mxnet_release/tests/python/
> > > unittest/test_image.py",
> > > > > line 94, in test_imdecode
> > > > > assert_almost_equal(image.asnumpy(), cv_image)
> > > > >   File
> > > > > "/Users/pllarroy/devel/mxnet/mxnet_release/python/mxnet/
> > > test_utils.py",
> > > > > line 493, in assert_almost_equal
> > > > > raise AssertionError(msg)
> > > > > AssertionError:
> > > > > Items are not equal:
> > > > > Error 980.392157 exceeds tolerance rtol=0.10, atol=0.00.
> > > > Location
> > > > > of maximum error:(100, 457, 1), a=103.00, b=102.00
> > > > >  a: array([[[  0,  10,  20],
> > > > > [  0,  11,  19],
> > > > > [  2,  12,  19],...
> > > > >  b: array([[[  0,  10,  20],
> > > > > [  0,  11,  19],
> > > > > [  2,  12,  19],...
> > > > >
> > > > >
> > --
> > > > > Ran 505 tests in 2018.430s
> > > > >
> > > > >
> > > > > Is this one known?
> > > > >
> > > > > The other unit tests passed.
> > > > >
> > > > > On Thu, Jun 21, 2018 at 2:09 PM Haibin Lin <
> haibin.lin@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Built from source with CUDA on Ubuntu.
> > > > > >
> > > > > > Ran example/gluon/word_language_model/train.py
> > > > > >
> > > > > > Best,
> > > > > > Haibin
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 21, 2018 at 11:08 AM, Anirudh  >
> > > > wrote:
> > > > > >
> > > > > > > Hi Pedro,
> > > > > > >
> > > > > > > I think you raised this issue in 1.2.0 release here:
> > > > > > > https://lists.apache.org/thread.html/
> > > ddc088a21aac179144350ea97353a7
> > > > > > > ea885b2765ccb98db08a03ba2d@%3Cdev.mxnet.apache.org%3E
> > > > > > > .
> > > > > > > I actually forgot about this issue during this release. Having
> > said
> > > > > > that, I
> > > > > > > think since this works with make and the customers using cmake
> > with
> > > > > > > USE_OPENMP=OFF should be considerably small we should not block
> > the
> > > > > > release
> > > > > > > for this.
> > > > > > > The main reason we are doing this release is for this issue
> > > > > > >  . Now
> > > > pulling
> > > > > > > this
> > > > > > > change for the cmake fix would be also mean we need to pull 8
> > more
> > > > > > commits
> > > > > > > from dmlc-core and its considerable risk to introduce for the
> > patch
> > > > > > > release.
> > > > > > > This would also mean cutting another rc. I think in the
> interest
> > of
> > > > our
> > > > > > > customers who are eagerly waiting for the patch release to fix
> > the
> > > > main
> > > > > > > issue, we should move ahead here.
> > > > > > > I missed reviewing all the known issue of 1.2.0 and add it to
> > 1.2.1
> > > > > > release
> > > > > > > notes. I will do that now.
> > > > > > >
> > > > > > > Anirudh
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 21, 2018 at 10:42 AM, Pedro Larroy <
> > > > > > > pedro.larroy.li...@gmail.com
> > > > > > > > wrote:
> > > > > > >
> > > > > > > > I think I have fixed this before, I will check if the patch
> > > didn't
> > > > > make
> > > > > > > it
> > > > > > > > to the branch.
> > > > > > > >
> > > > > > > > On Thu, Jun 21, 2018 at 10:24 AM Pedro Larroy <
> > > > > > > > pedro.larroy.li...@gmail.com>
> > > > > > > > 

Re: C++ api issue labeling

[Lin Yuan]

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 
> > 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: [VOTE] Release MXNet version 1.2.1.RC0 (Patch Release)

[sandeep krishnamurthy]

+1

Lai (https://github.com/roywei) and myself tested with Keras-MXNet for CNN
and RNN standard use cases, things are working as expected on CPU and GPU.

Best,
Sandeep

On Thu, Jun 21, 2018 at 11:06 PM Anirudh  wrote:

> Hi all,
>
> Thanks for checking the release. We need one more binding +1. I would
> request committers to help out here so that we can get the vote started on
> general@.
>
> Anirudh
>
> On Thu, Jun 21, 2018 at 3:06 PM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> wrote:
>
> > I already changed my vote to +1   I don't think this a big issue, just a
> > pixel difference of 1 when loading an image.
> >
> >
> >
> > On Thu, Jun 21, 2018 at 2:20 PM Marco de Abreu
> >  wrote:
> >
> > > We had 868 successful runs and no failures for that test so far, Pedro.
> > >
> > > On Thu, Jun 21, 2018 at 11:17 PM Pedro Larroy <
> > > pedro.larroy.li...@gmail.com>
> > > wrote:
> > >
> > > > Observed just one failure in OSX in test_imdecode:
> > > >
> > > >
> > > >
> ==
> > > > FAIL: test_imdecode (test_image.TestImage)
> > > >
> --
> > > > Traceback (most recent call last):
> > > >   File
> > > >
> > > >
> > > "/Users/pllarroy/devel/mxnet/mxnet_release/tests/python/
> > unittest/test_image.py",
> > > > line 94, in test_imdecode
> > > > assert_almost_equal(image.asnumpy(), cv_image)
> > > >   File
> > > > "/Users/pllarroy/devel/mxnet/mxnet_release/python/mxnet/
> > test_utils.py",
> > > > line 493, in assert_almost_equal
> > > > raise AssertionError(msg)
> > > > AssertionError:
> > > > Items are not equal:
> > > > Error 980.392157 exceeds tolerance rtol=0.10, atol=0.00.
> > > Location
> > > > of maximum error:(100, 457, 1), a=103.00, b=102.00
> > > >  a: array([[[  0,  10,  20],
> > > > [  0,  11,  19],
> > > > [  2,  12,  19],...
> > > >  b: array([[[  0,  10,  20],
> > > > [  0,  11,  19],
> > > > [  2,  12,  19],...
> > > >
> > > >
> --
> > > > Ran 505 tests in 2018.430s
> > > >
> > > >
> > > > Is this one known?
> > > >
> > > > The other unit tests passed.
> > > >
> > > > On Thu, Jun 21, 2018 at 2:09 PM Haibin Lin  >
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Built from source with CUDA on Ubuntu.
> > > > >
> > > > > Ran example/gluon/word_language_model/train.py
> > > > >
> > > > > Best,
> > > > > Haibin
> > > > >
> > > > >
> > > > > On Thu, Jun 21, 2018 at 11:08 AM, Anirudh 
> > > wrote:
> > > > >
> > > > > > Hi Pedro,
> > > > > >
> > > > > > I think you raised this issue in 1.2.0 release here:
> > > > > > https://lists.apache.org/thread.html/
> > ddc088a21aac179144350ea97353a7
> > > > > > ea885b2765ccb98db08a03ba2d@%3Cdev.mxnet.apache.org%3E
> > > > > > .
> > > > > > I actually forgot about this issue during this release. Having
> said
> > > > > that, I
> > > > > > think since this works with make and the customers using cmake
> with
> > > > > > USE_OPENMP=OFF should be considerably small we should not block
> the
> > > > > release
> > > > > > for this.
> > > > > > The main reason we are doing this release is for this issue
> > > > > >  . Now
> > > pulling
> > > > > > this
> > > > > > change for the cmake fix would be also mean we need to pull 8
> more
> > > > > commits
> > > > > > from dmlc-core and its considerable risk to introduce for the
> patch
> > > > > > release.
> > > > > > This would also mean cutting another rc. I think in the interest
> of
> > > our
> > > > > > customers who are eagerly waiting for the patch release to fix
> the
> > > main
> > > > > > issue, we should move ahead here.
> > > > > > I missed reviewing all the known issue of 1.2.0 and add it to
> 1.2.1
> > > > > release
> > > > > > notes. I will do that now.
> > > > > >
> > > > > > Anirudh
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 21, 2018 at 10:42 AM, Pedro Larroy <
> > > > > > pedro.larroy.li...@gmail.com
> > > > > > > wrote:
> > > > > >
> > > > > > > I think I have fixed this before, I will check if the patch
> > didn't
> > > > make
> > > > > > it
> > > > > > > to the branch.
> > > > > > >
> > > > > > > On Thu, Jun 21, 2018 at 10:24 AM Pedro Larroy <
> > > > > > > pedro.larroy.li...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > -1   I can't compile:
> > > > > > > >
> > > > > > > > 3rdparty/dmlc-core/libdmlc.a(io.cc.o): In function
> > > > > > > > `std::thread::thread > > > > > > InputSplitBase::Chunk>::Init(std::function > > > > > > > (dmlc::io::InputSplitBase::Chunk**)>, std::function > > > > > > > ()>)::{lambda()#1}&>(dmlc::ThreadedIter > > > > > > InputSplitBase::Chunk>::Init(std::function > > > > > > > (dmlc::io::InputSplitBase::Chunk**)>, std::function > > > > > > > ()>)::{lambda()#1}&)':
> > > > > > > > /usr/include/c++/5/thread:137: undefined reference to
> 

Re: Project Proposal for fused CPU RNN OPs to the release 1.3

[Steffen Rochel]

Thanks Patric, appreciate  your contributions. I looked at your design
proposal. I'm missing any statements about validation of correctness and
performance of the integrated solution. I would suggest to pay more
attention to this aspect as we struggled in previously releases with the
quality of the integration. As you know, we still have too many issues on
MKL-DNN integration to move from experimental to GA stage.
Regards,
Steffen

On Thu, Jun 21, 2018 at 12:09 AM Zhao, Patric  wrote:

> Hi MXNET owner,
>
> Recently, we (Intel engineers) have implemented the fused RNN operations
> (LSTM/GRU/vRNN) for the CPU, including bidirectional, multiple layers,
> inference/training.
> The LSTM and GRU PR was merged and vRNN code will be PR soon.
>
> The new APIs make the gluon and symbolic models much faster :)
>
> Thus, I have added a new row in the 1.3 proposal table and hope the end
> user can leverage the new feature easily.
>
>
> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
>
> Feel free to let me know for any feedbacks and suggestions.
>
> BR,
>
> Thanks,
>
> --Patric
>
>

Re: users@mxnet

[Steffen Rochel]

Thanks Isabel and Sergio for the feedback and evaluation criteria.
Based on the discussion I see mixed views in the community.
To summarize my suggestion:
1. Setup user@ list and staff with volunteers to respond to user requests.
2. Make changes based on feedback to grow the user list organically.
3. Decide after 6 months how to continue based on user community adoption
and conversion into contributors.
4. Start tracking how many people from discussion forums convert to
contributors.

I will start a lazy vote on my suggestion tomorrow unless somebody has
strong objections and would like to discuss further.
Steffen

On Fri, Jun 22, 2018 at 6:47 AM Sergio Fernández 
wrote:

> Honestly, I'm quite surprised of the level of the reactions on this thread.
> When I started it, I just wanted to expand the community with a tool that,
> even some people consider it "old fashion", it has been proved to help many
> other Apache projects to foster their community in the past.
>
> I guess, until people change their mindset, stop to think as scientist, get
> rid of the affiliation and start to build an open source community, this
> podling will struggle to move forward.
>
> At least I hope the proposal Sebastian have made may be acceptable for most
> of the people who are reluctant to adopt the ASF communication channels.
>
> On Jun 20, 2018 18:38, "Chris Olivier"  wrote:
>
> +1
>
>
> On Wed, Jun 20, 2018 at 8:43 AM Steffen Rochel 
> wrote:
>
>
> > I had a discussion yesterday with Jun Wu (wujun@gmail.com) to get a
> > better understanding about the concerns raised, that users might get
> > confused and maintenance efforts.
> > I agree with Jim that building and fostering the community is important.
> > First of all, I suggest we should be open minded and not make claims that
> > we have a good understanding of user preferences. We might have insights
> > about preferences of current users (which I also would question as we
> > sampled only a small set), but we certainly don't have insight about the
> > preferences of new users we are trying to attract.
> > In such situation it might be better to run an experiment, offer choices
> > and collect real feedback - lets be customer focussed.
> > My suggestion is to establish a user@ list and support the list with a
> > volunteer subset of contributors and committers to minimize the
> maintenance
> > impact on the whole community.
> > After a reasonable time like 6 months we can evaluate the adoption of
> user@
> > and effort to support and can make an informed, data driven decision how
> to
> > proceed.
> >
> > I recommend to create the user@ list and call for volunteers to support
> > the
> > list.
> >
> > Regards,
> > Steffen
> >
> > On Tue, Jun 19, 2018 at 8:10 AM Hagay Lupesko  wrote:
> >
> > > Jim,
> > >
> > > Earlier on the thread you suggested to clarify and expand on the usage
> > of a
> > > user@ mailing list and how it is useful for a project.
> > >
> > > It may be helpful for the community to learn a bit more about it. Could
> > you
> > > expand and/or share relevant links and examples?
> > >
> > > Thank you,
> > > Hagay
> > >
> > > On Tue, Jun 19, 2018, 07:31 Jim Jagielski  wrote:
> > >
> > > > Just so we are clear: building and fostering a community takes
> effort.
> > > > Either it is something important to the project, or it's not.
> > > >
> > > > My assumption is that It Is.
> > > >
> > > > > On Jun 18, 2018, at 8:59 PM, YiZhi Liu 
> wrote:
> > > > >
> > > > > I am personally not a big fan of mailing list but agree with Thomas
> > > > > that we may get extra users, which worth a try.
> > > > > On the other hand, I also have concern that we do not have a
> > community
> > > > > big enough to support multiple forums. If people asked questions
> but
> > > > > got no response, that can be worse than not having the mailing list
> > at
> > > > > all.
> > > > > On Mon, Jun 18, 2018 at 5:46 PM Thomas DELTEIL
> > > > >  wrote:
> > > > >>
> > > > >> I was actually the one stating that we didn't need a user mailing
> > list
> > > > >> during the Seattle meetup, given all the reasons already exposed
> > > above.
> > > > >>
> > > > >> However given what proponents of a mailing list said, I personally
> > > > wouldn't
> > > > >> mind adding a new channel as a user mailing list, and monitoring
> it.
> > > > There
> > > > >> seems to be a subset of users, used to apache projects, that
> > wouldn't
> > > > use
> > > > >> the forum but would use a mailing list. Though I think it is not
> as
> > > > >> feature-rich as the forum and there is a risk of dilution of
> > > > information.
> > > > >> It is more about reaching those extra users. If we see a dilution
> of
> > > > >> traffic on the forum towards the mailing list (~currently 100
> > > > posts/week)
> > > > >> then maybe we can reconsider our assumptions?
> > > > >>
> > > > >> All the best,
> > > > >>
> > > > >> Thomas Delteil
> > > > >>
> > > > >> On Mon, Jun 18, 2018, 17:30 Pedro Larroy <
> > > pedro.larroy.li...@gmail

Re: users@mxnet

[Sergio Fernández]

Honestly, I'm quite surprised of the level of the reactions on this thread.
When I started it, I just wanted to expand the community with a tool that,
even some people consider it "old fashion", it has been proved to help many
other Apache projects to foster their community in the past.

I guess, until people change their mindset, stop to think as scientist, get
rid of the affiliation and start to build an open source community, this
podling will struggle to move forward.

At least I hope the proposal Sebastian have made may be acceptable for most
of the people who are reluctant to adopt the ASF communication channels.

On Jun 20, 2018 18:38, "Chris Olivier"  wrote:

+1


On Wed, Jun 20, 2018 at 8:43 AM Steffen Rochel 
wrote:


> I had a discussion yesterday with Jun Wu (wujun@gmail.com) to get a
> better understanding about the concerns raised, that users might get
> confused and maintenance efforts.
> I agree with Jim that building and fostering the community is important.
> First of all, I suggest we should be open minded and not make claims that
> we have a good understanding of user preferences. We might have insights
> about preferences of current users (which I also would question as we
> sampled only a small set), but we certainly don't have insight about the
> preferences of new users we are trying to attract.
> In such situation it might be better to run an experiment, offer choices
> and collect real feedback - lets be customer focussed.
> My suggestion is to establish a user@ list and support the list with a
> volunteer subset of contributors and committers to minimize the
maintenance
> impact on the whole community.
> After a reasonable time like 6 months we can evaluate the adoption of
user@
> and effort to support and can make an informed, data driven decision how
to
> proceed.
>
> I recommend to create the user@ list and call for volunteers to support
> the
> list.
>
> Regards,
> Steffen
>
> On Tue, Jun 19, 2018 at 8:10 AM Hagay Lupesko  wrote:
>
> > Jim,
> >
> > Earlier on the thread you suggested to clarify and expand on the usage
> of a
> > user@ mailing list and how it is useful for a project.
> >
> > It may be helpful for the community to learn a bit more about it. Could
> you
> > expand and/or share relevant links and examples?
> >
> > Thank you,
> > Hagay
> >
> > On Tue, Jun 19, 2018, 07:31 Jim Jagielski  wrote:
> >
> > > Just so we are clear: building and fostering a community takes effort.
> > > Either it is something important to the project, or it's not.
> > >
> > > My assumption is that It Is.
> > >
> > > > On Jun 18, 2018, at 8:59 PM, YiZhi Liu  wrote:
> > > >
> > > > I am personally not a big fan of mailing list but agree with Thomas
> > > > that we may get extra users, which worth a try.
> > > > On the other hand, I also have concern that we do not have a
> community
> > > > big enough to support multiple forums. If people asked questions but
> > > > got no response, that can be worse than not having the mailing list
> at
> > > > all.
> > > > On Mon, Jun 18, 2018 at 5:46 PM Thomas DELTEIL
> > > >  wrote:
> > > >>
> > > >> I was actually the one stating that we didn't need a user mailing
> list
> > > >> during the Seattle meetup, given all the reasons already exposed
> > above.
> > > >>
> > > >> However given what proponents of a mailing list said, I personally
> > > wouldn't
> > > >> mind adding a new channel as a user mailing list, and monitoring
it.
> > > There
> > > >> seems to be a subset of users, used to apache projects, that
> wouldn't
> > > use
> > > >> the forum but would use a mailing list. Though I think it is not as
> > > >> feature-rich as the forum and there is a risk of dilution of
> > > information.
> > > >> It is more about reaching those extra users. If we see a dilution
of
> > > >> traffic on the forum towards the mailing list (~currently 100
> > > posts/week)
> > > >> then maybe we can reconsider our assumptions?
> > > >>
> > > >> All the best,
> > > >>
> > > >> Thomas Delteil
> > > >>
> > > >> On Mon, Jun 18, 2018, 17:30 Pedro Larroy <
> > pedro.larroy.li...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> I agree with Tianqi, Eric and others. We shouldn't dilute the
> > community
> > > >>> with another forum. Disqus is already working and has healthy
> > > >>> participation, you can get an email digest if you so desire.
> > > Subscribing to
> > > >>> a mailing list to get a question answered is quite a heavyweight
> > > investment
> > > >>> for many people and users who might not have the resources nor
> mental
> > > >>> bandwidth to receive more email volume in their inboxes.
> > > >>>
> > > >>> On Mon, Jun 18, 2018 at 10:19 AM Tianqi Chen <
> > tqc...@cs.washington.edu
> > > >
> > > >>> wrote:
> > > >>>
> > >  The problem of having multiple separate channels of communication
> is
> > > that
> > >  users get confused, and the cost of maintenance goes up(people
> have
> > to
> > >  watch both). As the current community was at discuss forum a

Re: users@mxnet

[Isabel Drost-Fromm]

Am 20. Juni 2018 17:43:35 MESZ schrieb Steffen Rochel :
>After a reasonable time like 6 months we can evaluate the adoption of
>user@
>and effort to support and can make an informed, data driven decision
>how to
>proceed.

In addition to adoption, I would add "amount of users converted to 
contributers" as a criterion.

As an aside: As an ASF member I would love to better understand how well other 
user discussion media work in turning users into contributors.

Isabel



-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: C++ api issue labeling

[Hagay Lupesko]

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