Re: Call for contribution - MXNet Scala on Windows

[Krishnan Murali]

Glad to have your aid, Eftiquar.

> On May 22, 2018, at 12:17 PM, Shaikh, Eftiquar  wrote:
> 
> Hi Naveen, 
> I can fill in for Windows expertise. Do we have approximate estimates on how 
> long will it take to provide basic support. 
> 
> Best 
> Eftiquar 
> 
> From: Naveen Swamy 
> Sent: Tuesday, May 22, 2018 11:45 AM
> To: d...@mxnet.apache.org
> Subject: Call for contribution - MXNet Scala on Windows
> 
> We have a few users requesting support MXNet Scala on the windows platform,
> currently I or other MXNet Scala contributors that I know do not have the
> expertise on Windows.
> 
> Anyone have expertise on Windows and willing to take this up? I can help
> you bootstrapped with MXNet-Scala ?
> 
> https://github.com/apache/incubator-mxnet/issues/8075
> 
> Thanks, Naveen

Re: CMake issues

[Naveen Swamy]

+1 to pushing to the branch. We can revisit a patch release if there are
critical bugs.

On Tue, May 22, 2018 at 1:51 PM, Anirudh  wrote:

> I think pushing the fixes back to the release branch should be sufficient.
> I am not sure why we need to maintain a different patches branch. I agree
> that if there are a bunch of important fixes that didn't go into the
> release, then we need to do a patch release for the same.
>
> On Tue, May 22, 2018 at 1:44 PM, sandeep krishnamurthy <
> sandeep.krishn...@gmail.com> wrote:
>
> > 1.2.1 patch release with this bug fix (+ others if applicable) will be
> very
> > useful for the users.
> >
> > On Tue, May 22, 2018 at 1:08 PM, Rahul Huilgol 
> > wrote:
> >
> > > Maybe we could do that now, after the code for the release has been
> voted
> > > on. We could maintain a patches branch for a release. This would also
> be
> > > helpful for users who are using a particular release version but
> hesitate
> > > to switch to the latest release when it's out because of the many
> > changes.
> > > Such users I've seen maintain their own patches branch. We could help
> > them
> > > and keep things consistent. We can cut a patch release from that if we
> > have
> > > many fixes or important fixes.
> > >
> > > On Thu, May 17, 2018 at 10:05 PM, Anirudh 
> wrote:
> > >
> > > > Thats an interesting suggestion. I understand the benefits, but this
> > will
> > > > complicate things if we want to do another quick release like the
> > > previous
> > > > one (for eg. if there is a license issue because of which the release
> > is
> > > > cancelled).
> > > >
> > > > Anirudh
> > > >
> > > > On Thu, May 17, 2018 at 9:23 PM, Naveen Swamy 
> > > wrote:
> > > >
> > > > > why don't we cherry-pick and push it to the branch as well ? next
> > time
> > > a
> > > > > release is cut from that branch we'll have everything working.
> > > > >
> > > > > On Thu, May 17, 2018 at 9:21 PM, Anirudh 
> > > wrote:
> > > > >
> > > > > > Correction : This fix went into master but not 1.2 release.
> > > > > >
> > > > > > On Thu, May 17, 2018 at 9:21 PM, Anirudh 
> > > > wrote:
> > > > > >
> > > > > > > Hi Xinyu,
> > > > > > >
> > > > > > > Thank you! This fix didnt went into master but not 1.2 release.
> > > > > > >
> > > > > > > Anirudh
> > > > > > >
> > > > > > > On Thu, May 17, 2018 at 5:23 PM, Chen, Xinyu1 <
> > > xinyu1.c...@intel.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi all,
> > > > > > >>
> > > > > > >> Regarding to the following knowing issues listed below RC3:
> > > > > > >>
> > > > > > >>
> > > > > > >>   *   CMake build ignores the USE_MKLDNN flag and doesn't
> build
> > > with
> > > > > > >> MKLDNN support even with -DUSE_MKLDNN=1. To workaround the
> issue
> > > > > please
> > > > > > >> see: #10801 > > 10801
> > > > >.
> > > > > > >> I think this problem has already been fixed in #10629<
> > > > > > >> https://github.com/apache/incubator-mxnet/pull/10629> and we
> > can
> > > > use
> > > > > > >> CMake to build MXNet with MKLDNN support on WIN32 platform
> now.
> > > > > > >> Xinyu
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Rahul Huilgol
> > >
> >
> >
> >
> > --
> > Sandeep Krishnamurthy
> >
>

Re: CMake issues

[Anirudh]

I think pushing the fixes back to the release branch should be sufficient.
I am not sure why we need to maintain a different patches branch. I agree
that if there are a bunch of important fixes that didn't go into the
release, then we need to do a patch release for the same.

On Tue, May 22, 2018 at 1:44 PM, sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> 1.2.1 patch release with this bug fix (+ others if applicable) will be very
> useful for the users.
>
> On Tue, May 22, 2018 at 1:08 PM, Rahul Huilgol 
> wrote:
>
> > Maybe we could do that now, after the code for the release has been voted
> > on. We could maintain a patches branch for a release. This would also be
> > helpful for users who are using a particular release version but hesitate
> > to switch to the latest release when it's out because of the many
> changes.
> > Such users I've seen maintain their own patches branch. We could help
> them
> > and keep things consistent. We can cut a patch release from that if we
> have
> > many fixes or important fixes.
> >
> > On Thu, May 17, 2018 at 10:05 PM, Anirudh  wrote:
> >
> > > Thats an interesting suggestion. I understand the benefits, but this
> will
> > > complicate things if we want to do another quick release like the
> > previous
> > > one (for eg. if there is a license issue because of which the release
> is
> > > cancelled).
> > >
> > > Anirudh
> > >
> > > On Thu, May 17, 2018 at 9:23 PM, Naveen Swamy 
> > wrote:
> > >
> > > > why don't we cherry-pick and push it to the branch as well ? next
> time
> > a
> > > > release is cut from that branch we'll have everything working.
> > > >
> > > > On Thu, May 17, 2018 at 9:21 PM, Anirudh 
> > wrote:
> > > >
> > > > > Correction : This fix went into master but not 1.2 release.
> > > > >
> > > > > On Thu, May 17, 2018 at 9:21 PM, Anirudh 
> > > wrote:
> > > > >
> > > > > > Hi Xinyu,
> > > > > >
> > > > > > Thank you! This fix didnt went into master but not 1.2 release.
> > > > > >
> > > > > > Anirudh
> > > > > >
> > > > > > On Thu, May 17, 2018 at 5:23 PM, Chen, Xinyu1 <
> > xinyu1.c...@intel.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >>
> > > > > >> Regarding to the following knowing issues listed below RC3:
> > > > > >>
> > > > > >>
> > > > > >>   *   CMake build ignores the USE_MKLDNN flag and doesn't build
> > with
> > > > > >> MKLDNN support even with -DUSE_MKLDNN=1. To workaround the issue
> > > > please
> > > > > >> see: #10801 > 10801
> > > >.
> > > > > >> I think this problem has already been fixed in #10629<
> > > > > >> https://github.com/apache/incubator-mxnet/pull/10629> and we
> can
> > > use
> > > > > >> CMake to build MXNet with MKLDNN support on WIN32 platform now.
> > > > > >> Xinyu
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Rahul Huilgol
> >
>
>
>
> --
> Sandeep Krishnamurthy
>

Re: CMake issues

[sandeep krishnamurthy]

1.2.1 patch release with this bug fix (+ others if applicable) will be very
useful for the users.

On Tue, May 22, 2018 at 1:08 PM, Rahul Huilgol 
wrote:

> Maybe we could do that now, after the code for the release has been voted
> on. We could maintain a patches branch for a release. This would also be
> helpful for users who are using a particular release version but hesitate
> to switch to the latest release when it's out because of the many changes.
> Such users I've seen maintain their own patches branch. We could help them
> and keep things consistent. We can cut a patch release from that if we have
> many fixes or important fixes.
>
> On Thu, May 17, 2018 at 10:05 PM, Anirudh  wrote:
>
> > Thats an interesting suggestion. I understand the benefits, but this will
> > complicate things if we want to do another quick release like the
> previous
> > one (for eg. if there is a license issue because of which the release is
> > cancelled).
> >
> > Anirudh
> >
> > On Thu, May 17, 2018 at 9:23 PM, Naveen Swamy 
> wrote:
> >
> > > why don't we cherry-pick and push it to the branch as well ? next time
> a
> > > release is cut from that branch we'll have everything working.
> > >
> > > On Thu, May 17, 2018 at 9:21 PM, Anirudh 
> wrote:
> > >
> > > > Correction : This fix went into master but not 1.2 release.
> > > >
> > > > On Thu, May 17, 2018 at 9:21 PM, Anirudh 
> > wrote:
> > > >
> > > > > Hi Xinyu,
> > > > >
> > > > > Thank you! This fix didnt went into master but not 1.2 release.
> > > > >
> > > > > Anirudh
> > > > >
> > > > > On Thu, May 17, 2018 at 5:23 PM, Chen, Xinyu1 <
> xinyu1.c...@intel.com
> > >
> > > > > wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >> Regarding to the following knowing issues listed below RC3:
> > > > >>
> > > > >>
> > > > >>   *   CMake build ignores the USE_MKLDNN flag and doesn't build
> with
> > > > >> MKLDNN support even with -DUSE_MKLDNN=1. To workaround the issue
> > > please
> > > > >> see: #10801 10801
> > >.
> > > > >> I think this problem has already been fixed in #10629<
> > > > >> https://github.com/apache/incubator-mxnet/pull/10629> and we can
> > use
> > > > >> CMake to build MXNet with MKLDNN support on WIN32 platform now.
> > > > >> Xinyu
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Rahul Huilgol
>



-- 
Sandeep Krishnamurthy

Re: CMake issues

[Rahul Huilgol]

Maybe we could do that now, after the code for the release has been voted
on. We could maintain a patches branch for a release. This would also be
helpful for users who are using a particular release version but hesitate
to switch to the latest release when it's out because of the many changes.
Such users I've seen maintain their own patches branch. We could help them
and keep things consistent. We can cut a patch release from that if we have
many fixes or important fixes.

On Thu, May 17, 2018 at 10:05 PM, Anirudh  wrote:

> Thats an interesting suggestion. I understand the benefits, but this will
> complicate things if we want to do another quick release like the previous
> one (for eg. if there is a license issue because of which the release is
> cancelled).
>
> Anirudh
>
> On Thu, May 17, 2018 at 9:23 PM, Naveen Swamy  wrote:
>
> > why don't we cherry-pick and push it to the branch as well ? next time a
> > release is cut from that branch we'll have everything working.
> >
> > On Thu, May 17, 2018 at 9:21 PM, Anirudh  wrote:
> >
> > > Correction : This fix went into master but not 1.2 release.
> > >
> > > On Thu, May 17, 2018 at 9:21 PM, Anirudh 
> wrote:
> > >
> > > > Hi Xinyu,
> > > >
> > > > Thank you! This fix didnt went into master but not 1.2 release.
> > > >
> > > > Anirudh
> > > >
> > > > On Thu, May 17, 2018 at 5:23 PM, Chen, Xinyu1  >
> > > > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> Regarding to the following knowing issues listed below RC3:
> > > >>
> > > >>
> > > >>   *   CMake build ignores the USE_MKLDNN flag and doesn't build with
> > > >> MKLDNN support even with -DUSE_MKLDNN=1. To workaround the issue
> > please
> > > >> see: #10801 >.
> > > >> I think this problem has already been fixed in #10629<
> > > >> https://github.com/apache/incubator-mxnet/pull/10629> and we can
> use
> > > >> CMake to build MXNet with MKLDNN support on WIN32 platform now.
> > > >> Xinyu
> > > >>
> > > >>
> > > >
> > >
> >
>



-- 
Rahul Huilgol

Re: installation page UX

[Rahul Huilgol]

Hi Aaron,

Thanks for your work on this! Few points I noticed

1. Looks like something is wrong with the pip instructions. I see
instructions for pre-reqs but not the actual pip install.

2. Most of the language bindings seem to be redirects to install page for
that OS, regardless of CPU/GPU, but we still show that selector.

3. Can we remove the 'Validate MXNet..' wording when instructions are on a
different page. The combination Linux, Scala, CPU for example.

4. I don't see much advantage of Pytorch or Caffe style installation
webpages. Like you mentioned we have couple of more selectors. But it's
pretty clear and not enough to overwhelm the user. If the problem is the
maintenance of backend instructions, could we address that by having
different files / folders for different scenarios and including them from
one file? Not sure if that's feasible.

+1 for hyperlinks to specific instructions.

Regards,
Rahul

On Tue, May 22, 2018 at 11:53 AM, Naveen Swamy  wrote:

> MXNet UI definitely needs more love.
>
> +1 - pytorch style
> +0.5 - caffe2
>
>
> On Tue, May 22, 2018 at 11:48 AM, Markham, Aaron 
> wrote:
>
> > Hi everyone,
> > In addition to the options on the wiki (pros & cons), there's this
> preview.
> > It uses a dropdown next to the install options to make it clearer what
> > versions you can install… then updates the pip commands…
> >
> > http://54.210.6.225/install/index.html#
> >
> > Thoughts?
> >
> >
> > On 5/16/18, 9:31 AM, "Aaron Markham"  wrote:
> >
> > Hi,
> > I've written some notes on the wiki about issues with the
> installation
> > page
> > along with some suggestions. I'd appreciate your feedback here or on
> > the
> > wiki.
> >
> > https://cwiki.apache.org/confluence/display/MXNET/
> Installation+page+UX
> >
> > Cheers,
> > Aaron
> >
> >
> >
>



-- 
Rahul Huilgol

Re: Slack access

[Naveen Swamy]

done.

On Tue, May 22, 2018 at 12:30 PM, Wellner, Benjamin R. 
wrote:

> Hello,
>
> I have just joined the Apache MXNet mailing list and would like to receive
> access to the MXNet Slack channel.
>
> Thanks,
>
>   *   Ben
>

Slack access

[Wellner, Benjamin R.]

Hello,

I have just joined the Apache MXNet mailing list and would like to receive 
access to the MXNet Slack channel.

Thanks,

  *   Ben

Re: installation page UX

[Markham, Aaron]

Ultimately, I want to retire the version selector that swaps out the whole 
site. Version selection can be at the API docs and at the install page where 
people would expect to have that option.

Side note, because this come up when mentioning removal of the versions 
dropdown for the site: tutorials can be tagged with their minimum version & 
Python or other language support. Keeping around v0.11.0 tutorials just creates 
really high bounce rates for the site.

I was hoping to tackle one problem at a time. We need clear install 
instructions for the 90% of the visitors. We shouldn't complicate the install 
page with every corner case. I'd cut the install page down to the bare minimum.

Basically +1 for PyTorch UI.
But... other considerations come into play. Is it ok to push the non-Python 
language binding to their own pages?

And +1 for the direct linking capability - regardless of the UI.


On 5/22/18, 12:05 PM, "sandeep krishnamurthy"  
wrote:

Thanks Aaron for this quick preview.

Version is selected at the top level documentation? Should we show how to
install v1.0 when the user is viewing v1.2 docs?

From UX functionality perspective - MXNet installation page is similar to
PyTorch? Collection of choices to make.

Behind the scenes, one single monolithic markdown is a severe problem as
rightly pointed out.
Aaron, can you please include more details on how this issue is planned to
be handled?
Another issue we need to list down is - We cannot hyperlink to specific
choices in the install guide. For example, Hyperlink that takes directly to
Ubuntu, GPU, Source build. This might be helpful in search engine, blogs,
and documentation.

Best,
Sandeep

On Tue, May 22, 2018 at 11:53 AM, Naveen Swamy  wrote:

> MXNet UI definitely needs more love.
>
> +1 - pytorch style
> +0.5 - caffe2
>
>
> On Tue, May 22, 2018 at 11:48 AM, Markham, Aaron 
> wrote:
>
> > Hi everyone,
> > In addition to the options on the wiki (pros & cons), there's this
> preview.
> > It uses a dropdown next to the install options to make it clearer what
> > versions you can install… then updates the pip commands…
> >
> > http://54.210.6.225/install/index.html#
> >
> > Thoughts?
> >
> >
> > On 5/16/18, 9:31 AM, "Aaron Markham"  wrote:
> >
> > Hi,
> > I've written some notes on the wiki about issues with the
> installation
> > page
> > along with some suggestions. I'd appreciate your feedback here or on
> > the
> > wiki.
> >
> > https://cwiki.apache.org/confluence/display/MXNET/
> Installation+page+UX
> >
> > Cheers,
> > Aaron
> >
> >
> >
>



-- 
Sandeep Krishnamurthy

Re: Call for contribution - MXNet Scala on Windows

[Shaikh, Eftiquar]

Hi Naveen, 
I can fill in for Windows expertise. Do we have approximate estimates on how 
long will it take to provide basic support. 

Best 
Eftiquar 

From: Naveen Swamy 
Sent: Tuesday, May 22, 2018 11:45 AM
To: d...@mxnet.apache.org
Subject: Call for contribution - MXNet Scala on Windows

We have a few users requesting support MXNet Scala on the windows platform,
currently I or other MXNet Scala contributors that I know do not have the
expertise on Windows.

Anyone have expertise on Windows and willing to take this up? I can help
you bootstrapped with MXNet-Scala ?

https://github.com/apache/incubator-mxnet/issues/8075

Thanks, Naveen

Flaky test failures are impacting development

[Pedro Larroy]

Hi team.

Flaky test failures are impacting PR validation and hindering contributions
to MXNet.

We should prioritize dealing with these failing tests.

See recent failures on master:

http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-mxnet/job/master/

The biggest offenders right now:

https://github.com/apache/incubator-mxnet/issues/9853
https://github.com/apache/incubator-mxnet/issues/10973


Pedro.

Re: installation page UX

[sandeep krishnamurthy]

Thanks Aaron for this quick preview.

Version is selected at the top level documentation? Should we show how to
install v1.0 when the user is viewing v1.2 docs?

>From UX functionality perspective - MXNet installation page is similar to
PyTorch? Collection of choices to make.

Behind the scenes, one single monolithic markdown is a severe problem as
rightly pointed out.
Aaron, can you please include more details on how this issue is planned to
be handled?
Another issue we need to list down is - We cannot hyperlink to specific
choices in the install guide. For example, Hyperlink that takes directly to
Ubuntu, GPU, Source build. This might be helpful in search engine, blogs,
and documentation.

Best,
Sandeep

On Tue, May 22, 2018 at 11:53 AM, Naveen Swamy  wrote:

> MXNet UI definitely needs more love.
>
> +1 - pytorch style
> +0.5 - caffe2
>
>
> On Tue, May 22, 2018 at 11:48 AM, Markham, Aaron 
> wrote:
>
> > Hi everyone,
> > In addition to the options on the wiki (pros & cons), there's this
> preview.
> > It uses a dropdown next to the install options to make it clearer what
> > versions you can install… then updates the pip commands…
> >
> > http://54.210.6.225/install/index.html#
> >
> > Thoughts?
> >
> >
> > On 5/16/18, 9:31 AM, "Aaron Markham"  wrote:
> >
> > Hi,
> > I've written some notes on the wiki about issues with the
> installation
> > page
> > along with some suggestions. I'd appreciate your feedback here or on
> > the
> > wiki.
> >
> > https://cwiki.apache.org/confluence/display/MXNET/
> Installation+page+UX
> >
> > Cheers,
> > Aaron
> >
> >
> >
>



-- 
Sandeep Krishnamurthy

Re: installation page UX

[Naveen Swamy]

MXNet UI definitely needs more love.

+1 - pytorch style
+0.5 - caffe2


On Tue, May 22, 2018 at 11:48 AM, Markham, Aaron 
wrote:

> Hi everyone,
> In addition to the options on the wiki (pros & cons), there's this preview.
> It uses a dropdown next to the install options to make it clearer what
> versions you can install… then updates the pip commands…
>
> http://54.210.6.225/install/index.html#
>
> Thoughts?
>
>
> On 5/16/18, 9:31 AM, "Aaron Markham"  wrote:
>
> Hi,
> I've written some notes on the wiki about issues with the installation
> page
> along with some suggestions. I'd appreciate your feedback here or on
> the
> wiki.
>
> https://cwiki.apache.org/confluence/display/MXNET/Installation+page+UX
>
> Cheers,
> Aaron
>
>
>

Re: installation page UX

[Markham, Aaron]

Hi everyone,
In addition to the options on the wiki (pros & cons), there's this preview.
It uses a dropdown next to the install options to make it clearer what versions 
you can install… then updates the pip commands…

http://54.210.6.225/install/index.html#

Thoughts?


On 5/16/18, 9:31 AM, "Aaron Markham"  wrote:

Hi,
I've written some notes on the wiki about issues with the installation page
along with some suggestions. I'd appreciate your feedback here or on the
wiki.

https://cwiki.apache.org/confluence/display/MXNET/Installation+page+UX

Cheers,
Aaron

Re: Using parts of code from library under PyTorch organization

[Zai, Alexander]

I need to call `cpuinfo_processors_count`. The 8 files needed are below:

https://github.com/pytorch/cpuinfo/blob/master/src/api.c#L16
https://github.com/pytorch/cpuinfo/blob/master/src/api.h

https://github.com/pytorch/cpuinfo/blob/master/src/x86/windows/init.c#L569
https://github.com/pytorch/cpuinfo/blob/master/src/x86/linux/init.c#L570
https://github.com/pytorch/cpuinfo/blob/master/src/x86/mach/init.c#L325

https://github.com/pytorch/cpuinfo/blob/master/src/arm/mach/init.c#L480
https://github.com/pytorch/cpuinfo/blob/master/src/arm/linux/init.c#L654

Best,
Alex

On 5/19/18, 9:51 AM, "Hen"  wrote:

It's 2-clause BSD: https://github.com/pytorch/cpuinfo/blob/master/LICENSE

Which files are you looking to incorporate? I want to see what the source
headers look like.

Hen

On Fri, May 18, 2018 at 5:47 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> By the way. In general, I'd prefer to have a solution in C++ as part of 
our
> Backend, as this would allow us to share this information with all 
frontend
> APIs. Tobias is currently working on a PR which does exactly the same, but
> for GPUs.
>
> Marco de Abreu  schrieb am Sa., 19. Mai
> 2018,
> 02:45:
>
> > I would have to check the license, but I assume it's under Apache. In
> that
> > case, it should be enough to copy the file and keep the original license
> > header. Additionally, you have to document any changes you made and 
where
> > you got it from. You can do this in the header, below the license.
> >
> > In any case, check the NOTICE of the project and see if they contain any
> > special instructions.
> >
> > -Marco
> >
> > Anirudh  schrieb am Sa., 19. Mai 2018, 00:27:
> >
> >> Hi Alex,
> >>
> >> I am no expert but adding the license and the copyright to the header 
of
> >> the file should be enough.
> >> Can someone who has experience with this confirm ?
> >>
> >> Anirudh
> >>
> >> On Fri, May 18, 2018 at 10:55 AM, Alex Zai  wrote:
> >>
> >> > For this issue (https://github.com/apache/
> incubator-mxnet/issues/10836
> >> ),
> >> > we
> >> > need to determine the number of physical cores for each platform.
> >> Currently
> >> > we assume each platform supports HyperThreading and just fetch the
> >> number
> >> > of logical cores and divide by 2. However, in cases where the machine
> >> does
> >> > not support HTT, we underutilize the CPUs. Per the issue’s thread, 
the
> >> > PyTorch organization has a library that does just this (
> >> > https://github.com/pytorch/cpuinfo). The library is a bit heavy and
> we
> >> > only
> >> > need a small portion of the code. Does anyone know if there is an
> issue
> >> > with just using a subset of the code?
> >> >
> >> >
> >> >
> >> > Alex
> >> >
> >>
> >
>

Re: MXNet issues labeling

[Roshani Nagmote]

Sorry for incomplete email. Sent it too fast.
Thanks for all the comments. Aaron guessed it right. We can treat it as a
multi-label classification problem. :)
We are currently working on the design document, will share it on dev list
once it is more concrete.

@Marco, seems like a good idea too but as you said, it will still involve
manual labeling. We can do this as a temporary solution but need a
long-term solution.
@Hao, will explore that option too! Thanks!

Thanks,
Roshani


On Tue, May 22, 2018 at 9:52 AM, Roshani Nagmote 
wrote:

> Thanks for all the comments. Aaron guessed it right. We can treat it as a
> multi-label classification problem. :)
> We are currently working on the design document, will share it on dev list
> once it is more concrete.
>
> @Marco, seems like a good idea too but as you said, it will still involve
> manual labeling. We can do this as a temporary solution but need a more
> @Hao, will explore that option too! Thanks!
>
> Thanks,
> Roshani
>
> On Mon, May 21, 2018 at 5:42 PM, Jin, Hao  wrote:
>
>> Definitely a good idea. I think maybe we can also try out the new gluon
>> NLP toolkit on this task?
>>
>> On 5/21/18, 5:24 PM, "Anirudh"  wrote:
>>
>> Yes, I guessed that :). Was looking for more details.
>>
>> On Mon, May 21, 2018 at 5:03 PM, Aaron Markham <
>> aaron.s.mark...@gmail.com>
>> wrote:
>>
>> > AI obviously.
>> >
>> > On Mon, May 21, 2018 at 5:01 PM, Anirudh 
>> wrote:
>> >
>> > > Hi Roshani,
>> > >
>> > > Good suggestion! How will the bot decide what labels to add ?
>> > >
>> > > Anirudh
>> > >
>> > > On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy > >
>> > wrote:
>> > >
>> > > > +1 for the proposal to triage issues, I think committers should
>> also do
>> > > > this exercise to understand the customer pain.
>> > > >
>> > > > I am also inclined to use a bot account like how Tensorflow and
>> other
>> > > repos
>> > > > do it, https://github.com/googlebot.
>> > > > https://github.com/tensorflow/tensorflow/pull/19445#event-16
>> 38027271
>> > -->
>> > > > This is auto-tagged by the bot, it would be cool if we could do
>> that as
>> > > > well.
>> > > >
>> > > >
>> > > >
>> > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy <
>> > > > sandeep.krishn...@gmail.com> wrote:
>> > > >
>> > > > > Thanks,
>> > > > >
>> > > > > Roshani for starting this thread.
>> > > > >
>> > > > > Yes, I think labeling the issues will help a lot in driving
>> the
>> > > attention
>> > > > > of contributors to specific areas and make it easy for new
>> > contributors
>> > > > to
>> > > > > search and pick their contribution.
>> > > > >
>> > > > > I agree manually doing it all the time is not scalable and
>> efficient.
>> > > > Your
>> > > > > proposal on bot script to auto-label, similar to the working
>> of
>> > Jenkins
>> > > > bot
>> > > > > to re-test, re-build actions, will be very useful and
>> effective.
>> > > Hence, I
>> > > > > am more inclined to your *option 1* to have a bot account to
>> add
>> > > labels.
>> > > > >
>> > > > > Best,
>> > > > > Sandeep
>> > > > >
>> > > > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote <
>> > > > > roshaninagmo...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > Some of us here at Amazon as a part of our day job, are
>> triaging
>> > > Github
>> > > > > > issues to find where MXNet users are experiencing
>> difficulty and
>> > help
>> > > > the
>> > > > > > community focus on those areas. This is done by assigning
>> labels to
>> > > the
>> > > > > > Github issues. We do know that only labeling won’t solve
>> the real
>> > > > problem
>> > > > > > but we will expand our scope to also attempt to resolve the
>> issues.
>> > > > > > Categorizing issues could also help contributors and
>> maintainers
>> > who
>> > > > > know a
>> > > > > > particular area to pick up the issue and help the user.
>> > > > > >
>> > > > > > Right now, we just manually go through the issues. If they
>> are
>> > > > questions,
>> > > > > > we redirect users to start a discussion on discuss forum,
>> find the
>> > > > > > appropriate labels and then ask one of the committers to
>> add those
>> > > > > labels.
>> > > > > > This process is not very smooth as its completely manual
>> and every
>> > > time
>> > > > > we
>> > > > > > need to ask committers to add labels.
>> > > > > >
>> > > > > > We want to be able to automate/simplify this issue labeling
>> > process.
>> > > > > > Right now, as far as I know, there's no way for
>> non-committers to
>> > add
>> > > > 

Re: MXNet issues labeling

[Roshani Nagmote]

Thanks for all the comments. Aaron guessed it right. We can treat it as a
multi-label classification problem. :)
We are currently working on the design document, will share it on dev list
once it is more concrete.

@Marco, seems like a good idea too but as you said, it will still involve
manual labeling. We can do this as a temporary solution but need a more
@Hao, will explore that option too! Thanks!

Thanks,
Roshani

On Mon, May 21, 2018 at 5:42 PM, Jin, Hao  wrote:

> Definitely a good idea. I think maybe we can also try out the new gluon
> NLP toolkit on this task?
>
> On 5/21/18, 5:24 PM, "Anirudh"  wrote:
>
> Yes, I guessed that :). Was looking for more details.
>
> On Mon, May 21, 2018 at 5:03 PM, Aaron Markham <
> aaron.s.mark...@gmail.com>
> wrote:
>
> > AI obviously.
> >
> > On Mon, May 21, 2018 at 5:01 PM, Anirudh 
> wrote:
> >
> > > Hi Roshani,
> > >
> > > Good suggestion! How will the bot decide what labels to add ?
> > >
> > > Anirudh
> > >
> > > On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy 
> > wrote:
> > >
> > > > +1 for the proposal to triage issues, I think committers should
> also do
> > > > this exercise to understand the customer pain.
> > > >
> > > > I am also inclined to use a bot account like how Tensorflow and
> other
> > > repos
> > > > do it, https://github.com/googlebot.
> > > > https://github.com/tensorflow/tensorflow/pull/19445#event-
> 1638027271
> > -->
> > > > This is auto-tagged by the bot, it would be cool if we could do
> that as
> > > > well.
> > > >
> > > >
> > > >
> > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy <
> > > > sandeep.krishn...@gmail.com> wrote:
> > > >
> > > > > Thanks,
> > > > >
> > > > > Roshani for starting this thread.
> > > > >
> > > > > Yes, I think labeling the issues will help a lot in driving the
> > > attention
> > > > > of contributors to specific areas and make it easy for new
> > contributors
> > > > to
> > > > > search and pick their contribution.
> > > > >
> > > > > I agree manually doing it all the time is not scalable and
> efficient.
> > > > Your
> > > > > proposal on bot script to auto-label, similar to the working of
> > Jenkins
> > > > bot
> > > > > to re-test, re-build actions, will be very useful and
> effective.
> > > Hence, I
> > > > > am more inclined to your *option 1* to have a bot account to
> add
> > > labels.
> > > > >
> > > > > Best,
> > > > > Sandeep
> > > > >
> > > > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote <
> > > > > roshaninagmo...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Some of us here at Amazon as a part of our day job, are
> triaging
> > > Github
> > > > > > issues to find where MXNet users are experiencing difficulty
> and
> > help
> > > > the
> > > > > > community focus on those areas. This is done by assigning
> labels to
> > > the
> > > > > > Github issues. We do know that only labeling won’t solve the
> real
> > > > problem
> > > > > > but we will expand our scope to also attempt to resolve the
> issues.
> > > > > > Categorizing issues could also help contributors and
> maintainers
> > who
> > > > > know a
> > > > > > particular area to pick up the issue and help the user.
> > > > > >
> > > > > > Right now, we just manually go through the issues. If they
> are
> > > > questions,
> > > > > > we redirect users to start a discussion on discuss forum,
> find the
> > > > > > appropriate labels and then ask one of the committers to add
> those
> > > > > labels.
> > > > > > This process is not very smooth as its completely manual and
> every
> > > time
> > > > > we
> > > > > > need to ask committers to add labels.
> > > > > >
> > > > > > We want to be able to automate/simplify this issue labeling
> > process.
> > > > > > Right now, as far as I know, there's no way for
> non-committers to
> > add
> > > > > > labels. So, I want to propose two options:
> > > > > >
> > > > > > - Using a separate account having minimum permissions to run
> the
> > bot
> > > > > script
> > > > > > which will do the labeling. For this, we will need an
> account to be
> > > > > created
> > > > > > from Apache infrastructure with proper access and they can
> control
> > > the
> > > > > > access for the account through
> > > > > > https://docs.aws.amazon.com/secretsmanager/latest/
> > > userguide/intro.html
> > > > > >
> > > > > > - Using one of the committers auth token to run the script.
> > > > > >
> > > > > > Please let me know if you have any other ideas to do this.
> > 

Re: [Launch Announcement] Keras 2 with Apache MXNet (incubating) backend

[Indhu]

This is great. Thanks to everybody involved.


On Tue, May 22, 2018, 9:15 AM sandeep krishnamurthy  wrote:

> Hello MXNet community,
>
> Keras users can now use the high-performance MXNet deep learning engine for
> the distributed training of convolutional neural networks (CNNs) and
> recurrent neural networks (RNNs). With an update of a few lines of code,
> Keras developers can increase training speed by using MXNet's multi-GPU
> distributed training capabilities. Saving an MXNet model is another
> valuable feature of the release. You can design in Keras, train with
> Keras-MXNet, and run inference in production, at-scale with MXNet.
>
> From our initial benchmarks, CNNs with Keras-MXNet is up to 3X faster on
> GPUs compared to the default backend. See the benchmark module
>  for
> more details.
>
> RNN support in this release is experimental with few known
> issues/unsupported functionalities. See using RNN with Keras-MXNet
> limitations and workarounds doc
> <
> https://github.com/awslabs/keras-apache-mxnet/blob/master/docs/mxnet_backend/using_rnn_with_mxnet_backend.md
> >
> for more details.
>
> See Release Notes
>  for
> more details on unsupported operators and known issues. We will continue
> our efforts in the future releases to close the gaps.
>
> Thank you for all the contributors - Lai Wei ,
> Karan
> Jariwala , Jiajie Chen
> , Kalyanee Chendke <
> https://github.com/kalyc>,
> Junyuan Xie 
>
> We welcome your contributions -
> https://github.com/awslabs/keras-apache-mxnet. Here is the issue with the
> list of operators to be implemented. Do check it out and create a PR -
> https://github.com/awslabs/keras-apache-mxnet/issues/18
>
> Best,
> Sandeep
>

[Launch Announcement] Keras 2 with Apache MXNet (incubating) backend

[sandeep krishnamurthy]

Hello MXNet community,

Keras users can now use the high-performance MXNet deep learning engine for
the distributed training of convolutional neural networks (CNNs) and
recurrent neural networks (RNNs). With an update of a few lines of code,
Keras developers can increase training speed by using MXNet's multi-GPU
distributed training capabilities. Saving an MXNet model is another
valuable feature of the release. You can design in Keras, train with
Keras-MXNet, and run inference in production, at-scale with MXNet.

>From our initial benchmarks, CNNs with Keras-MXNet is up to 3X faster on
GPUs compared to the default backend. See the benchmark module
 for
more details.

RNN support in this release is experimental with few known
issues/unsupported functionalities. See using RNN with Keras-MXNet
limitations and workarounds doc

for more details.

See Release Notes
 for
more details on unsupported operators and known issues. We will continue
our efforts in the future releases to close the gaps.

Thank you for all the contributors - Lai Wei , Karan
Jariwala , Jiajie Chen
, Kalyanee Chendke ,
Junyuan Xie 

We welcome your contributions -
https://github.com/awslabs/keras-apache-mxnet. Here is the issue with the
list of operators to be implemented. Do check it out and create a PR -
https://github.com/awslabs/keras-apache-mxnet/issues/18

Best,
Sandeep

Re: Scala Packages in Maven

[Naveen Swamy]

I am working to publish the full package for the 3 platforms that also
contains infer package. Spark package does not have any tests at the
moment. I think it needs some testing before we can publish to maven.

On Mon, May 21, 2018 at 9:19 PM, Hagay Lupesko  wrote:

> +1 for a CD for publishing to Maven
> +1 for reducing the number of packages. Do we really need more than full,
> infer and spark (x3 platforms)?
>
> On Mon, May 21, 2018 at 5:47 PM, Naveen Swamy  wrote:
>
> > not at the moment, certainly is in my radar. Apache release requires a
> > committer's LDAP username/password. we could see how we can leverage CI
> > setup to do this
> >
> > On Mon, May 21, 2018 at 5:44 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com> wrote:
> >
> > > Great, thanks a lot. This looks great!
> > >
> > > Is the result of your process going to be a script we can run to
> generate
> > > the artefacts? AFAIK, there's been attempts in the community to push
> > > towards CD, thus it'd be great if this process could directly be
> designed
> > > with an automated processing step in mind.
> > >
> > > -Marco
> > >
> > > On Tue, May 22, 2018 at 2:41 AM, Naveen Swamy 
> > wrote:
> > >
> > > > I am not sure who published it in the past, hence this discussion.
> > > >
> > > > I am already in the process of documenting them here, I clean it up
> and
> > > add
> > > > more info as I make progress.
> > > > 1)
> > > > https://cwiki.apache.org/confluence/display/MXNET/Release+Process#
> > > > ReleaseProcess-Step1.12.CreateScalaMavenPackages(WIP)
> > > >
> > > > 2) https://cwiki.apache.org/confluence/display/MXNET/MXNet-Scala
> > > >
> > > > On Mon, May 21, 2018 at 5:37 PM, Marco de Abreu <
> > > > marco.g.ab...@googlemail.com> wrote:
> > > >
> > > > > Agree, we should make a proper assessment of what all these
> packages
> > > are
> > > > > before we try managing them. Do you know who published them before?
> > > > >
> > > > > Moving forward, it'd be great if you could document the entire
> > process
> > > > (and
> > > > > all issues you encounter) in confluence. This would allow us to
> > > re-visit
> > > > > decisions later on and give us a source of information for
> questions
> > > > > exactly like this one. If we decide to add a new package to the
> > publish
> > > > > process, we could just document it there and have a central point
> to
> > > look
> > > > > it up.
> > > > >
> > > > > -Marco
> > > > >
> > > > > On Tue, May 22, 2018 at 1:34 AM, Naveen Swamy 
> > > > wrote:
> > > > >
> > > > > > I think this needs quite a bit of rework to clean up, currently I
> > am
> > > > > > thinking to publish only the mxnet-full_2.11-{platform} x 3 and
> > > revisit
> > > > > > what the other packages should be published by the next release
> > > > > >
> > > > > > On Mon, May 21, 2018 at 3:49 PM, Naveen Swamy <
> mnnav...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > I am working on publishing MXNet Scala packages of the 1.2
> > release
> > > to
> > > > > > > maven and observed that there are about 20 packages that needs
> to
> > > be
> > > > > > > published. I think this is too many of them and probably will
> > > confuse
> > > > > the
> > > > > > > users.
> > > > > > >
> > > > > > > I think we can cut down the number of packages, I wanted ask if
> > > > someone
> > > > > > > knows why the below packages were published and if it is ok not
> > > > publish
> > > > > > > them going forward.
> > > > > > >
> > > > > > > Proposing to not publish
> > > > > > > ---
> > > > > > >
> > > > > > > mxnet-full-parent_2.11
> > > > > > > mxnet-parent_2.11
> > > > > > > mxnet-scala-native-parent
> > > > > > > Any other packages that you propose to remove?
> > > > > > > ---
> > > > > > >
> > > > > > > ---Full List --
> > > > > > > libmxnet-init-scala-{platform} x 2
> > > > > > > libmxnet-scala-{platform} x 3
> > > > > > > mxnet-core_2.11
> > > > > > > mxnet-examples_2.11
> > > > > > > mxnet-full-parent_2.11
> > > > > > > mxnet-full_2.11-{platform} x 3
> > > > > > > mxnet-infer_2.11
> > > > > > > mxnet-init_2.11
> > > > > > > mxnet-macros_2.11
> > > > > > > mxnet-parent_2.11
> > > > > > > mxnet-scala-init-native-parent
> > > > > > > mxnet-scala-native-parent
> > > > > > > mxnet-spark_2.11
> > > > > > > ---
> > > > > > >
> > > > > > > Please let me know your thoughts?
> > > > > > >
> > > > > > > Thanks, Naveen
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>