Re: Scala Packages in Maven

[Hagay Lupesko]

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

Re: Scala Packages in Maven

[Naveen Swamy]

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

Re: Scala Packages in Maven

[Marco de Abreu]

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

Re: Config for Scala Maven Package

[Naveen Swamy]

Hi Marco,
For MKL/MKLDNN --> I don't think we should build since its still
experimental. Its sad that MKLML was removed without a proper discussion,
granted
I have not tested with CUDA 9.2, I will building on a AWS Ubuntu instance
that is built with CUDA 9.0, I presume it should work fine.


On Mon, May 21, 2018 at 5:31 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> Hi Naveen,
>
> thank you for driving the releases for the Scala packages!
>
> For CPU, I'd propose add MKL/MKLDNN builds.
>
> For GPU, do we have to specify the minor version of CUDA up front or are
> they interchangeable? CUDA 9.2, for example, received some quite
> significant performance updates and it would be great if our users could
> use them.
>
> Best regards,
> Marco
>
> On Fri, May 18, 2018 at 8:28 PM, Naveen Swamy  wrote:
>
> > I am working on publishing the Scala package from 1.2.0 release. What do
> > you recommend should be the configuration for the Scala Packages ?
> >
> > I am thinking of the below
> > For CPU build with
> > OPENBLAS
> > LAPACK
> >
> > For GPU build with
> > OPENBLAS
> > CUDA 9.0
> > NCCL
> >
> > Let me know if you concerns or recommendations.
> >
> > Thanks, Naveen
> >
>

Re: MXNet issues labeling

[Marco de Abreu]

Haha, Aaron could work in marketing - AI solves everything! :P

But yeah, a bit more details would be good. As an alternative approach, I'd
like to propose a bot that does actions on your behalf. In this case, we
could have a bit that listens for comments and (based on a whitelist), it
would apply labels if certain contributors commented and requested the
labels to be assigned. I know that this still involves manual work, but it
would greatly reduce the round trip time since the bot would assign them
instantaneously. This means, the only difference for contributors would be
to make a comment instead of pressing the "labels" button. Would this
solution also be feasible?

-Marco

On Tue, May 22, 2018 at 2:24 AM, Anirudh  wrote:

> Yes, I guessed that :). Was looking for more details.
>
> On Mon, May 21, 2018 at 5:03 PM, Aaron Markham 
> 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.
> > > > > >
> > > > > > Thanks,
> > > > > > Roshani
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sandeep Krishnamurthy
> > > > >
> > > >
> > >
> >
>

Re: MXNet issues labeling

[Jin, Hao]

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 
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.
> > > > >
> > > > > Thanks,
> > > > > Roshani
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sandeep Krishnamurthy
> > > >
> > >
> >
>

Re: Scala Packages in Maven

[Naveen Swamy]

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

Re: Config for Scala Maven Package

[Marco de Abreu]

Hi Naveen,

thank you for driving the releases for the Scala packages!

For CPU, I'd propose add MKL/MKLDNN builds.

For GPU, do we have to specify the minor version of CUDA up front or are
they interchangeable? CUDA 9.2, for example, received some quite
significant performance updates and it would be great if our users could
use them.

Best regards,
Marco

On Fri, May 18, 2018 at 8:28 PM, Naveen Swamy  wrote:

> I am working on publishing the Scala package from 1.2.0 release. What do
> you recommend should be the configuration for the Scala Packages ?
>
> I am thinking of the below
> For CPU build with
> OPENBLAS
> LAPACK
>
> For GPU build with
> OPENBLAS
> CUDA 9.0
> NCCL
>
> Let me know if you concerns or recommendations.
>
> Thanks, Naveen
>

Re: MXNet issues labeling

[Anirudh]

Yes, I guessed that :). Was looking for more details.

On Mon, May 21, 2018 at 5:03 PM, Aaron Markham 
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.
> > > > >
> > > > > Thanks,
> > > > > Roshani
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sandeep Krishnamurthy
> > > >
> > >
> >
>

Re: MXNet issues labeling

[Aaron Markham]

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.
> > > >
> > > > Thanks,
> > > > Roshani
> > > >
> > >
> > >
> > >
> > > --
> > > Sandeep Krishnamurthy
> > >
> >
>

Re: MXNet issues labeling

[Anirudh]

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.
> > >
> > > Thanks,
> > > Roshani
> > >
> >
> >
> >
> > --
> > Sandeep Krishnamurthy
> >
>

Invitation: Apache MXNet release post mortem and next release brainstorm @ Tue May 29, 2018 8am - 9am (PDT) (dev@mxnet.incubator.apache.org)

[Steffen Rochel]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20180529T15Z
DTEND:20180529T16Z
DTSTAMP:20180521T235736Z
ORGANIZER;CN=Steffen Rochel:mailto:steffenroc...@gmail.com
UID:7b5ldve1b5d1en46mkpgqiu...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Steffen Rochel;X-NUM-GUESTS=0:mailto:steffenroc...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incu
 bator.apache.org
CREATED:20180521T235736Z
DESCRIPTION:Hi - we would like to follow up to discuss what went well or no
 t so well with MXNet release v1.2 and brainstorm about the next release - c
 ontent and schedule.\nWe will do two sessions on May 29 - 8am and 5pm PDT t
 o allow for call ins from different time zones. Please let me know if you n
 eed additional sessions and times.\n\n\n\nYou have been invited to an onlin
 e meeting\, powered by Amazon Chime.\n\n1. Click to join the meeting:\n\nht
 tps://chime.aws/1656021019\n\nMeeting ID: 1656 02 1019\n\n2. You can use yo
 ur computer’s microphone and speakers\, however\, a headset is recommended.
  Or\, call in using your phone:\n\nUnited States Toll-Free: +1 855-552-4463
 \nMeeting PIN: 1656 02 1019\n\nOne-click Mobile Dial-in (United States (1))
 : +1 206-462-5569\,\,1656021019#\n\nUnited States (1): +1 206-462-5569\nInt
 ernational: https://chime.aws/dialinnumbers/\n\n\nMeeting PIN: 1656021019#\
 n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~::~:~::-\nPlease do not edit this section of the description.\n\nVie
 w your event at https://www.google.com/calendar/event?action=VIEW=N2I1b
 GR2ZTFiNWQxZW40Nm1rcGdxaXVlZHIgZGV2QG14bmV0LmluY3ViYXRvci5hcGFjaGUub3Jn
 =MjMjc3RlZmZlbnJvY2hlbEBnbWFpbC5jb204MzYwMzU4NzNlMjEyMjY0OWQ1YTZhNGVlZmMxOT
 QxN2ZjNDgzZjY0=America%2FLos_Angeles=en=1.\n-::~:~::~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180521T235736Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Apache MXNet release post mortem and next release brainstorm
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: MXNet issues labeling

[Naveen Swamy]

+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.
> >
> > Thanks,
> > Roshani
> >
>
>
>
> --
> Sandeep Krishnamurthy
>

Re: MXNet issues labeling

[Qing Lan]

Great topic! Vote for Option 1
Labelling and problem triaging process should be a lot simpler for all 
developers and bring less load to committers.

Thanks,
Qing

On 5/21/18, 4:26 PM, "sandeep krishnamurthy"  
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 
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.
>
> Thanks,
> Roshani
>



-- 
Sandeep Krishnamurthy

MXNet issues labeling

[Roshani Nagmote]

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.

Thanks,
Roshani

Proposal of MxNet-to-ONNX exporter

[Marek Kolodziej]

def mxnet.contrib.onnx._export.export_model( sym, params, input_shape,
output):
"""
Exports a given MXNet symbol object file or path to saved file to ONNX
model file.
Input Parameters -
--
sym -
A str object (path to json file) or mxnet symbol object or
checkpointed mxnet symbol object
params -
A str object (path to params file) or dict object containing the
model params
input_shape -
list of tuple object , specifies the shape of each input to the
model
output -
path to the output file, including the filename.  Default: current
path , filename: model.onnx

Return Type –
--
onnx_model_path -
str object , path to saved .onnx file.
"""
...
return onnx_model_path