Re: Release plan - MXNET 1.3

[Steffen Rochel]

To make it easier to find the discussions related to project proposals I
added a column with a link to the thread on dev@ for most projects.
Appreciate for the project owners to fill in the blanks and to check that I
got the right threads.

Regards,
Steffen

On Wed, Jul 18, 2018 at 7:11 PM Roshani Nagmote 
wrote:

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

Re: Release plan - MXNET 1.3

[sandeep krishnamurthy]

Thanks Roshani.
I know other 2 contributors (Anirudh and Ankit) working on stabilizing R
package release, any release announcements in R for 1.3?

Best,
Sandeep

On Wed, Jul 18, 2018 at 7:11 PM Roshani Nagmote 
wrote:

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


-- 
Sandeep Krishnamurthy

Re: Data Type improvement in MXNet Scala

[sandeep krishnamurthy]

Hi Qing,
Thanks for picking this issue.
How would multiple inputs/labels be handled? By name or by position?

Background:
Recently I faced issue in Python where name of the input symbol name was
not used, but, position was used. Python2 reads list from 0 and Python3
reads list from last element. So based on the python version, I was having
swapped symbol and hence shape mis match errors.

Best
Sandeep

On Wed, Jul 18, 2018 at 8:09 PM Naveen Swamy  wrote:

> Thanks for looking into this Qing :)
>
> this would alleviate the problems we have in getting RNNs to work in Scala.
> Can we call name the new APIs `provideDataDesc` and `provideLabelDesc` ?
>
> Thanks, Naveen
>
> On Wed, Jul 18, 2018 at 3:43 PM, Qing Lan  wrote:
>
> > Hi all,
> >
> > I would like to propose a change on the MXNet Scala data_type:
> >
> > Depreciate the `provideData` and `provideLabel` functions to provide
> > `DataDesc` type instead of `ListMap[String, Shape]` type.
> >
> > There were several issues regarding to this since v0.12 on Scala. Several
> > users reported that the `implicit def ListMap2Descs` helps to do some
> > downcasting job however missing information during this process (layout
> > property).
> > MXNet Python language has already change this part into `DataDesc`. In
> > that case, I plan to add two more methods that will take `DataDesc` and
> > depreciate the functions that mentioned above. The downcasting method
> > `ListMap2Descs` will also be depreciated and not to be used in current
> > MXNet Scala code base.
> >
> > Thanks,
> > Qing
> >
> > References:
> > Code position:
> > https://github.com/apache/incubator-mxnet/blob/master/
> > scala-package/core/src/main/scala/org/apache/mxnet/IO.scala#L312-L315
> > https://github.com/apache/incubator-mxnet/blob/master/
> > scala-package/core/src/main/scala/org/apache/mxnet/IO.scala#L358-L363
> >
> > Issue links:
> > https://github.com/apache/incubator-mxnet/issues/11775
> > https://github.com/apache/incubator-mxnet/issues/10753
> > https://github.com/apache/incubator-mxnet/issues/11571
> >
> >
>


-- 
Sandeep Krishnamurthy

Re: Data Type improvement in MXNet Scala

[Naveen Swamy]

Thanks for looking into this Qing :)

this would alleviate the problems we have in getting RNNs to work in Scala.
Can we call name the new APIs `provideDataDesc` and `provideLabelDesc` ?

Thanks, Naveen

On Wed, Jul 18, 2018 at 3:43 PM, Qing Lan  wrote:

> Hi all,
>
> I would like to propose a change on the MXNet Scala data_type:
>
> Depreciate the `provideData` and `provideLabel` functions to provide
> `DataDesc` type instead of `ListMap[String, Shape]` type.
>
> There were several issues regarding to this since v0.12 on Scala. Several
> users reported that the `implicit def ListMap2Descs` helps to do some
> downcasting job however missing information during this process (layout
> property).
> MXNet Python language has already change this part into `DataDesc`. In
> that case, I plan to add two more methods that will take `DataDesc` and
> depreciate the functions that mentioned above. The downcasting method
> `ListMap2Descs` will also be depreciated and not to be used in current
> MXNet Scala code base.
>
> Thanks,
> Qing
>
> References:
> Code position:
> https://github.com/apache/incubator-mxnet/blob/master/
> scala-package/core/src/main/scala/org/apache/mxnet/IO.scala#L312-L315
> https://github.com/apache/incubator-mxnet/blob/master/
> scala-package/core/src/main/scala/org/apache/mxnet/IO.scala#L358-L363
>
> Issue links:
> https://github.com/apache/incubator-mxnet/issues/11775
> https://github.com/apache/incubator-mxnet/issues/10753
> https://github.com/apache/incubator-mxnet/issues/11571
>
>

Re: Release plan - MXNET 1.3

[Roshani Nagmote]

Hi Kellen,

Sure. I will update the notes with the information.

Thanks,
Roshani

On Wed, Jul 18, 2018 at 3:01 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Hey Roshani,
>
> Would you be able to add 'TensorRT Runtime Integration' to the list of
> upcoming features?  We'll target getting the release in and polished by the
> 23rd.  Design proposal is here:
>
> https://cwiki.apache.org/confluence/display/MXNET/Runtime+Integration+with+TensorRT
> and the lead contributor is Marek Kolodziej.
>
> -Kellen
>
> On Wed, Jul 18, 2018 at 8:32 PM Roshani Nagmote  >
> wrote:
>
> > Hi All,
> >
> > I am starting the process to prepare for Apache MXNet (incubating) 1.3
> > Release. Please find project proposal draft for this release here:
> > <*
> >
> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
> > <
> >
> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
> > >*
> > >
> >
> > Target feature freeze date is July 23rd. A release candidate will be cut
> > around Monday, August 6th and voting will commence from then until
> > Thursday, August 9th. If you have any additional features in progress and
> > would like to include it in this release, please make sure to comment so
> I
> > can update the release notes.
> >
> > Feel free to add any other comments/suggestions.
> >
> > Thanks,
> > Roshani
> >
>

Data Type improvement in MXNet Scala

[Qing Lan]

Hi all,

I would like to propose a change on the MXNet Scala data_type:

Depreciate the `provideData` and `provideLabel` functions to provide `DataDesc` 
type instead of `ListMap[String, Shape]` type.

There were several issues regarding to this since v0.12 on Scala. Several users 
reported that the `implicit def ListMap2Descs` helps to do some downcasting job 
however missing information during this process (layout property).
MXNet Python language has already change this part into `DataDesc`. In that 
case, I plan to add two more methods that will take `DataDesc` and depreciate 
the functions that mentioned above. The downcasting method `ListMap2Descs` will 
also be depreciated and not to be used in current MXNet Scala code base.

Thanks,
Qing

References:
Code position:
https://github.com/apache/incubator-mxnet/blob/master/scala-package/core/src/main/scala/org/apache/mxnet/IO.scala#L312-L315
https://github.com/apache/incubator-mxnet/blob/master/scala-package/core/src/main/scala/org/apache/mxnet/IO.scala#L358-L363

Issue links:
https://github.com/apache/incubator-mxnet/issues/11775
https://github.com/apache/incubator-mxnet/issues/10753
https://github.com/apache/incubator-mxnet/issues/11571

Re: Release plan - MXNET 1.3

[kellen sunderland]

Hey Roshani,

Would you be able to add 'TensorRT Runtime Integration' to the list of
upcoming features?  We'll target getting the release in and polished by the
23rd.  Design proposal is here:
https://cwiki.apache.org/confluence/display/MXNET/Runtime+Integration+with+TensorRT
and the lead contributor is Marek Kolodziej.

-Kellen

On Wed, Jul 18, 2018 at 8:32 PM Roshani Nagmote 
wrote:

> Hi All,
>
> I am starting the process to prepare for Apache MXNet (incubating) 1.3
> Release. Please find project proposal draft for this release here:
> <*
> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
> <
> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
> >*
> >
>
> Target feature freeze date is July 23rd. A release candidate will be cut
> around Monday, August 6th and voting will commence from then until
> Thursday, August 9th. If you have any additional features in progress and
> would like to include it in this release, please make sure to comment so I
> can update the release notes.
>
> Feel free to add any other comments/suggestions.
>
> Thanks,
> Roshani
>

Re: Request for feedback: proposal for MXNet SDK Office hours

[Naveen Swamy]

I think this should be called MXNet Office hours and in a subsection spell
what is supported now(expectation)? Amazon contributors could lead part of
the effort? and later have other interested contributors join this effort.

On Wed, Jul 18, 2018 at 2:30 PM, Mu Li  wrote:

> A minor suggestion: rename MXNet SDK to AWS MXNet SDK or Amazon MXNet SDK.
>
> On Wed, Jul 18, 2018 at 2:22 PM, Davydenko, Denis <
> dzianis.davydze...@gmail.com> wrote:
>
> > Hello, MXNet community,
> >
> > Following up on recent announcement of office hours introduction from
> > MXNet Berlin team,  we are trying to see if we can introduce some
> > modifications to that to make process a bit more streamlined and easier
> to
> > track. Also, we are trying to see how to scale that process to allow
> other
> > MXNet teams to provide this channel of support to their customers. With
> > that in mind, I would like to ask for your feedback on the proposal [1].
> >
> > [1] https://cwiki.apache.org/confluence/display/MXNET/
> > PROPOSAL%3A+MXNet+SDK+Office+Hours
> >
> >
> >
>

Re: Request for feedback: proposal for MXNet SDK Office hours

[Mu Li]

A minor suggestion: rename MXNet SDK to AWS MXNet SDK or Amazon MXNet SDK.

On Wed, Jul 18, 2018 at 2:22 PM, Davydenko, Denis <
dzianis.davydze...@gmail.com> wrote:

> Hello, MXNet community,
>
> Following up on recent announcement of office hours introduction from
> MXNet Berlin team,  we are trying to see if we can introduce some
> modifications to that to make process a bit more streamlined and easier to
> track. Also, we are trying to see how to scale that process to allow other
> MXNet teams to provide this channel of support to their customers. With
> that in mind, I would like to ask for your feedback on the proposal [1].
>
> [1] https://cwiki.apache.org/confluence/display/MXNET/
> PROPOSAL%3A+MXNet+SDK+Office+Hours
>
>
>

Request for feedback: proposal for MXNet SDK Office hours

[Davydenko, Denis]

Hello, MXNet community,

Following up on recent announcement of office hours introduction from MXNet 
Berlin team,  we are trying to see if we can introduce some modifications to 
that to make process a bit more streamlined and easier to track. Also, we are 
trying to see how to scale that process to allow other MXNet teams to provide 
this channel of support to their customers. With that in mind, I would like to 
ask for your feedback on the proposal [1].

[1] 
https://cwiki.apache.org/confluence/display/MXNET/PROPOSAL%3A+MXNet+SDK+Office+Hours

Re: [VOTE] Release MXNet version 1.2.1.RC1

[Afrooze, Sina]

This was observed on pip package for MXNet's nightly and has already been fixed 
by Sheng in #11776. - Sina

On 7/17/18, 11:41 PM, "Yasser Zamani"  wrote:

Hi Sina,

Do you encounter that issue during building MXNet from source (including 
tests) or on your own code/test? Three days ago I was successful to build 
master via VS2017 with Intel MKL+MKLDNN support. If you have an own test/code 
which fails, please pull request it into master.

Regards.

>-Original Message-
>From: Jim Jagielski 
>Sent: Tuesday, July 17, 2018 5:06 PM
>To: dev@mxnet.incubator.apache.org
>Subject: Re: [VOTE] Release MXNet version 1.2.1.RC1
>
>FWIW, neither can I.
>
>> On Jul 16, 2018, at 8:45 PM, Anirudh  wrote:
>>
>> Hi Sina,
>>
>> I am unable to reproduce this issue on 1.2.1.
>>
>> Anirudh
>>
>> On Mon, Jul 16, 2018 at 5:26 PM, Afrooze, Sina  
wrote:
>>
>>> I know voting is over for this release, but I think this issue may
>>> warrant
>>> delaying: https://github.com/apache/incubator-mxnet/issues/11772.
>>> Looks like save_parameters doesn't fix the issue it is designed to
>>> fix (i.e. two instances of the same network in the same session) if 
LSTMs are
>used.
>>>
>>> - Sina
>>>
>>> On 7/12/18, 3:27 PM, "Hao Jin"  wrote:
>>>
>>>+1 Built on Ubuntu with CUDA 9.0 and CuDNN 7 and verified that
>>> sparse tests
>>>are passing.
>>>Hao
>>>
>>>On Thu, Jul 12, 2018 at 3:01 PM, Sergio Fernández
>>> 
>>> wrote:
>>>
 +1 (binding)

 On Mon, Jul 9, 2018, 16:53 Roshani Nagmote <
>>> roshaninagmo...@gmail.com>
 wrote:

> Hi all,
>
> I would like to propose a vote to release Apache MXNet (incubating)
 version
> 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50
>>> PM
> PDT, Thursday, July 12th.
>
> Link to release candidate 1.2.1.rc1:
> *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> 
> View this page, click on "Build from Source", and use the source
>>> code
> obtained from 1.2.1.rc1 tag:
> https://mxnet.incubator.apache.org/install/index.html
>
> (Note: The README.md points to the 1.2.1 tag and does not work at
>>> the
> moment.)
>
> Please remember to test first before voting accordingly:
>
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
> Thanks,
> Roshani
>

>>>
>>>
>>>
>>>

Re: MXNet developer setup on Mac with VSCode for develop, test and debug

[Naveen Swamy]

Thanks Sandeep for putting this together, it would make it easy for people
who prefer to IDEs to get started with MXNet easily.

On Wed, Jul 18, 2018 at 1:04 PM, Lin Yuan  wrote:

> Hi Aaron,
>
> This doc is for development on Mac. It is not intended for Windows users.
> Maybe we can start a different thread to discuss about MXNet build on
> Windows? I have tried it myself on a GPU instances built on Windows DLAMI
> 10.0. I would love to share with you my setup steps.
>
> Lin
>
> On Wed, Jul 18, 2018 at 11:43 AM Markham, Aaron
> 
> wrote:
>
> > This is tangential, but Lin, I noticed during the RC1 tests you said you
> > tried it out on Windows and it worked for you. I'd like to get VS2017 or
> VS
> > Code working, take Sandeep's setup content and possibly your Windows
> > experience, and improve the MXNet Windows setup guide. I've tried it and
> > failed. Multiple times. I also tried the MKLDNN instructions and failed.
> I
> > tried the setup tools batch file and was hit with a lot of dependency
> > errors. Some of the problem isn't in the MXNet docs, but in the
> > dependencies' documentation, but I'm left to go figure that out on my
> own.
> > Anyway, any help you can provide here would be great. Also, if any of you
> > reading this has a sort of checklist or guide for Windows, I'd love to
> see
> > it.
> >
> > BTW, I'm using Windows 10 with an NVIDIA GeForce GTX 980, and was trying
> > to use VS2017 Community Edition and MKL. I went to MKL after OpenBLAS
> > wasn't installing/building.
> >
> > On 7/18/18, 10:59 AM, "Lin Yuan"  wrote:
> >
> > Thanks for the well-written document! As a new MXNet developer, I
> have
> > found it very helpful.
> >
> > Lin
> >
> > On Wed, Jul 18, 2018 at 10:50 AM sandeep krishnamurthy <
> s...@apache.org
> > >
> > wrote:
> >
> > > Hello Community,
> > >
> > >
> > >
> > > As a MXNet contributor, I had issues and took me some time on
> getting
> > > hands-on with MXNet codebase, being able to code, test, DEBUG
> > python/CPP
> > > combination. I have documented the steps for MXNet development
> setup
> > using
> > > VSCode on Mac. Document starts from installing all required
> > > tools/packages/IDEs/extensions and then provides steps for
> debugging
> > mix of
> > > Python/CPP code, which is most likely the case for any MXNet
> > developer, all
> > > in single IDE window. By end of this document, anyone should be
> able
> > to
> > > walk through the MXNet code, debug and be able to make first code
> > change.
> > >
> > >
> > >
> > > Please feel free to add comments, make changes as necessary.
> > >
> > >
> > >
> > https://cwiki.apache.org/confluence/display/MXNET/
> MXNet+Developer+Setup+on+Mac
> > >
> > > Best,
> > > Sandeep
> > >
> >
> >
> >
>

Re: MXNet developer setup on Mac with VSCode for develop, test and debug

[Lin Yuan]

Hi Aaron,

This doc is for development on Mac. It is not intended for Windows users.
Maybe we can start a different thread to discuss about MXNet build on
Windows? I have tried it myself on a GPU instances built on Windows DLAMI
10.0. I would love to share with you my setup steps.

Lin

On Wed, Jul 18, 2018 at 11:43 AM Markham, Aaron 
wrote:

> This is tangential, but Lin, I noticed during the RC1 tests you said you
> tried it out on Windows and it worked for you. I'd like to get VS2017 or VS
> Code working, take Sandeep's setup content and possibly your Windows
> experience, and improve the MXNet Windows setup guide. I've tried it and
> failed. Multiple times. I also tried the MKLDNN instructions and failed. I
> tried the setup tools batch file and was hit with a lot of dependency
> errors. Some of the problem isn't in the MXNet docs, but in the
> dependencies' documentation, but I'm left to go figure that out on my own.
> Anyway, any help you can provide here would be great. Also, if any of you
> reading this has a sort of checklist or guide for Windows, I'd love to see
> it.
>
> BTW, I'm using Windows 10 with an NVIDIA GeForce GTX 980, and was trying
> to use VS2017 Community Edition and MKL. I went to MKL after OpenBLAS
> wasn't installing/building.
>
> On 7/18/18, 10:59 AM, "Lin Yuan"  wrote:
>
> Thanks for the well-written document! As a new MXNet developer, I have
> found it very helpful.
>
> Lin
>
> On Wed, Jul 18, 2018 at 10:50 AM sandeep krishnamurthy  >
> wrote:
>
> > Hello Community,
> >
> >
> >
> > As a MXNet contributor, I had issues and took me some time on getting
> > hands-on with MXNet codebase, being able to code, test, DEBUG
> python/CPP
> > combination. I have documented the steps for MXNet development setup
> using
> > VSCode on Mac. Document starts from installing all required
> > tools/packages/IDEs/extensions and then provides steps for debugging
> mix of
> > Python/CPP code, which is most likely the case for any MXNet
> developer, all
> > in single IDE window. By end of this document, anyone should be able
> to
> > walk through the MXNet code, debug and be able to make first code
> change.
> >
> >
> >
> > Please feel free to add comments, make changes as necessary.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac
> >
> > Best,
> > Sandeep
> >
>
>
>

Re: MXNet developer setup on Mac with VSCode for develop, test and debug

[Markham, Aaron]

This is tangential, but Lin, I noticed during the RC1 tests you said you tried 
it out on Windows and it worked for you. I'd like to get VS2017 or VS Code 
working, take Sandeep's setup content and possibly your Windows experience, and 
improve the MXNet Windows setup guide. I've tried it and failed. Multiple 
times. I also tried the MKLDNN instructions and failed. I tried the setup tools 
batch file and was hit with a lot of dependency errors. Some of the problem 
isn't in the MXNet docs, but in the dependencies' documentation, but I'm left 
to go figure that out on my own. Anyway, any help you can provide here would be 
great. Also, if any of you reading this has a sort of checklist or guide for 
Windows, I'd love to see it.

BTW, I'm using Windows 10 with an NVIDIA GeForce GTX 980, and was trying to use 
VS2017 Community Edition and MKL. I went to MKL after OpenBLAS wasn't 
installing/building.

On 7/18/18, 10:59 AM, "Lin Yuan"  wrote:

Thanks for the well-written document! As a new MXNet developer, I have
found it very helpful.

Lin

On Wed, Jul 18, 2018 at 10:50 AM sandeep krishnamurthy 
wrote:

> Hello Community,
>
>
>
> As a MXNet contributor, I had issues and took me some time on getting
> hands-on with MXNet codebase, being able to code, test, DEBUG python/CPP
> combination. I have documented the steps for MXNet development setup using
> VSCode on Mac. Document starts from installing all required
> tools/packages/IDEs/extensions and then provides steps for debugging mix 
of
> Python/CPP code, which is most likely the case for any MXNet developer, 
all
> in single IDE window. By end of this document, anyone should be able to
> walk through the MXNet code, debug and be able to make first code change.
>
>
>
> Please feel free to add comments, make changes as necessary.
>
>
> 
https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac
>
> Best,
> Sandeep
>

Release plan - MXNET 1.3

[Roshani Nagmote]

Hi All,

I am starting the process to prepare for Apache MXNet (incubating) 1.3
Release. Please find project proposal draft for this release here:
<*https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release
*
>

Target feature freeze date is July 23rd. A release candidate will be cut
around Monday, August 6th and voting will commence from then until
Thursday, August 9th. If you have any additional features in progress and
would like to include it in this release, please make sure to comment so I
can update the release notes.

Feel free to add any other comments/suggestions.

Thanks,
Roshani

MXNet developer setup on Mac with VSCode for develop, test and debug

[sandeep krishnamurthy]

Hello Community,



As a MXNet contributor, I had issues and took me some time on getting
hands-on with MXNet codebase, being able to code, test, DEBUG python/CPP
combination. I have documented the steps for MXNet development setup using
VSCode on Mac. Document starts from installing all required
tools/packages/IDEs/extensions and then provides steps for debugging mix of
Python/CPP code, which is most likely the case for any MXNet developer, all
in single IDE window. By end of this document, anyone should be able to
walk through the MXNet code, debug and be able to make first code change.



Please feel free to add comments, make changes as necessary.

https://cwiki.apache.org/confluence/display/MXNET/MXNet+Developer+Setup+on+Mac

Best,
Sandeep

Re: [VOTE] Subscribe dev@ to Github Activities

[Tianqi Chen]

While I do agree that the GitHub issue triaging should be improved,
possibly by moving more user discussions to the discuss forum/user list. I
already see there is a good effort on triaging the issues.

I do think forwarding GitHub activities are a good first step to make
people aware of what is going on. The filtering mechanism means that it is
possible to alleviate this problem for those who don't want to see
"noise"(although most of them are not noises, but bugfixes, discussions
etc.).

Tianqi

On Wed, Jul 18, 2018 at 10:41 AM, Rahul Huilgol 
wrote:

> The point is not that valuable discussion does not happen on Github. The
> point is that mails about it will be dwarfed by the other activity on
> Github.
>
> On Wed, Jul 18, 2018 at 10:30 AM, Tianqi Chen 
> wrote:
>
> > Being Apache is about being inclusive to the new contributors. Apache
> > encourages the use of Github, and currently, the community is doing so.
> >
> > I don't think it is a good idea to use political terms to force
> proliferate
> > our contributors --- we are all Apache contributors. Instead, we should
> > make all contributors feel inclusive under the frameworks of Apache
> > (including those who contribute and discuss through github, which is
> > currently the majority).
> >
> > On the other hand, the filtering mechanism would work for those who do
> not
> > want to receive the content.
> >
> > Tianqi
> >
> > On Wed, Jul 18, 2018 at 10:21 AM, Chris Olivier 
> > wrote:
> >
> > > to know about github discussions, you’d need to scan all issues and prs
> > > constantly which isn’t a reasonable expectation. dev is where
> discussions
> > > are supposed to happen in a apache, PERIOD.
> > >
> > > Apache isn’t dmlc. I wish some people would stop trying to turn Apache
> > > conventions into dmlc conventions.  seems this is a constant push from
> > day
> > > one.
> > >
> > >
> > > On Wed, Jul 18, 2018 at 9:39 AM Sheng Zha  wrote:
> > >
> > > > Thanks, I hear the concerns and it's not my intention to push people
> > off
> > > > the list. On the other hand, I think github discussions are no more
> > > > "artificial" than discussions on dev list, and the good and important
> > > > discussions warrant the same amount of attention. With this vote, I
> > > intend
> > > > to make contributors' life easier by decoupling the recognized forum
> > from
> > > > the technology they use, and that github contributors can easily
> > > > communicate with the community on the list.
> > > >
> > > > -sz
> > > >
> > > > On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> > > > christopher.bar...@analog.com> wrote:
> > > >
> > > > > Can't you simply tell contributors to discuss changes on dev before
> > > > > submitting a PR? Since the contribution guidelines don't tell
> > > developers
> > > > to
> > > > > post to dev, why would you expect them to do that?
> > > > >
> > > > > Is there an easy way to just subscribe to PR notifications or will
> > > > someone
> > > > > have to write a filter to avoid spamming dev with all GitHub
> > > > notifications?
> > > > > I think that if dev gets too much traffic, then people with casual
> > > > interest
> > > > > may find it easier to unsubscribe than to set up filters. Once
> > someone
> > > > > unsubscribes, they probably won't be coming back soon, so you
> should
> > be
> > > > > very careful with this.
> > > > >
> > > > > I don't see why artificially increasing the traffic on dev will do
> > > > > anything to grow the community in any case.
> > > > >
> > > > > - C
> > > > >
> > > > > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> > > > >
> > > > > Some mentors/contributors/committees feel that the amount of
> > > > > discussions in
> > > > > dev list is too less given the amount of commits that happen
> and
> > > more
> > > > > discussions need to happen in the dev list to grow the
> community.
> > > > >
> > > > > In response some committees feel discussions actually happen in
> > > > GitHub
> > > > > PRs.
> > > > > If the policy says "if it didn't happen in dev, it didn't
> > happen",
> > > > > let's
> > > > > forward all GitHub discussions to dev so those discussions
> would
> > > > count.
> > > > > That's the motivation for this vote.
> > > > >
> > > > > I think when people say there needs to be more discussions in
> the
> > > dev
> > > > > list,
> > > > > I assume they mean the kind of discussions that happen
> *before* a
> > > PR
> > > > is
> > > > > created or even before someone starts working on anything. I
> > don't
> > > > > think
> > > > > people are asking an email for every activity on GitHub. The
> > > correct
> > > > > way to
> > > > > address the problem would be for committees/contributors to
> stop
> > > > > communicating in private channels (like Amazon or DMLC
> > > communication
> > > > > channels) and do those discussions in the dev list instead.
> > > > >
> > > > > Indu
> > > > >
> > > > >
> > > > > On Wed, Jul 18, 2018, 5:51 AM 

Re: [VOTE] Subscribe dev@ to Github Activities

[Rahul Huilgol]

The point is not that valuable discussion does not happen on Github. The
point is that mails about it will be dwarfed by the other activity on
Github.

On Wed, Jul 18, 2018 at 10:30 AM, Tianqi Chen 
wrote:

> Being Apache is about being inclusive to the new contributors. Apache
> encourages the use of Github, and currently, the community is doing so.
>
> I don't think it is a good idea to use political terms to force proliferate
> our contributors --- we are all Apache contributors. Instead, we should
> make all contributors feel inclusive under the frameworks of Apache
> (including those who contribute and discuss through github, which is
> currently the majority).
>
> On the other hand, the filtering mechanism would work for those who do not
> want to receive the content.
>
> Tianqi
>
> On Wed, Jul 18, 2018 at 10:21 AM, Chris Olivier 
> wrote:
>
> > to know about github discussions, you’d need to scan all issues and prs
> > constantly which isn’t a reasonable expectation. dev is where discussions
> > are supposed to happen in a apache, PERIOD.
> >
> > Apache isn’t dmlc. I wish some people would stop trying to turn Apache
> > conventions into dmlc conventions.  seems this is a constant push from
> day
> > one.
> >
> >
> > On Wed, Jul 18, 2018 at 9:39 AM Sheng Zha  wrote:
> >
> > > Thanks, I hear the concerns and it's not my intention to push people
> off
> > > the list. On the other hand, I think github discussions are no more
> > > "artificial" than discussions on dev list, and the good and important
> > > discussions warrant the same amount of attention. With this vote, I
> > intend
> > > to make contributors' life easier by decoupling the recognized forum
> from
> > > the technology they use, and that github contributors can easily
> > > communicate with the community on the list.
> > >
> > > -sz
> > >
> > > On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> > > christopher.bar...@analog.com> wrote:
> > >
> > > > Can't you simply tell contributors to discuss changes on dev before
> > > > submitting a PR? Since the contribution guidelines don't tell
> > developers
> > > to
> > > > post to dev, why would you expect them to do that?
> > > >
> > > > Is there an easy way to just subscribe to PR notifications or will
> > > someone
> > > > have to write a filter to avoid spamming dev with all GitHub
> > > notifications?
> > > > I think that if dev gets too much traffic, then people with casual
> > > interest
> > > > may find it easier to unsubscribe than to set up filters. Once
> someone
> > > > unsubscribes, they probably won't be coming back soon, so you should
> be
> > > > very careful with this.
> > > >
> > > > I don't see why artificially increasing the traffic on dev will do
> > > > anything to grow the community in any case.
> > > >
> > > > - C
> > > >
> > > > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> > > >
> > > > Some mentors/contributors/committees feel that the amount of
> > > > discussions in
> > > > dev list is too less given the amount of commits that happen and
> > more
> > > > discussions need to happen in the dev list to grow the community.
> > > >
> > > > In response some committees feel discussions actually happen in
> > > GitHub
> > > > PRs.
> > > > If the policy says "if it didn't happen in dev, it didn't
> happen",
> > > > let's
> > > > forward all GitHub discussions to dev so those discussions would
> > > count.
> > > > That's the motivation for this vote.
> > > >
> > > > I think when people say there needs to be more discussions in the
> > dev
> > > > list,
> > > > I assume they mean the kind of discussions that happen *before* a
> > PR
> > > is
> > > > created or even before someone starts working on anything. I
> don't
> > > > think
> > > > people are asking an email for every activity on GitHub. The
> > correct
> > > > way to
> > > > address the problem would be for committees/contributors to stop
> > > > communicating in private channels (like Amazon or DMLC
> > communication
> > > > channels) and do those discussions in the dev list instead.
> > > >
> > > > Indu
> > > >
> > > >
> > > > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> > > > christopher.bar...@analog.com> wrote:
> > > >
> > > > > Can't people already subscribe to github notifications? I think
> > it
> > > > is safe
> > > > > to assume that developers are already smart enough to figure
> out
> > > how
> > > > to do
> > > > > that if they want. What problem are you really trying to solve
> > > here?
> > > > >
> > > > > On 7/18/18, 4:49 AM, "Chris Olivier" 
> > > wrote:
> > > > >
> > > > > -1.  (changed from -0.9)
> > > > >
> > > > > seems more like a strategy (whether intentional or on
> > accident)
> > > > to
> > > > > *not*
> > > > > have design discussions on dev by flooding it with noise
> and
> > > > then later
> > > > > claim it was discussed, even though you would have 

Re: [VOTE] Subscribe dev@ to Github Activities

[Barber, Christopher]

You should explicitly tell potential contributors what you expect of them. Here 
is what you document:

https://github.com/apache/incubator-mxnet/blob/master/docs/community/contribute.md

There is nothing there that tells contributors to discuss proposals on dev 
first. It sounds like that needs to be fixed.

On 7/18/18, 1:21 PM, "Chris Olivier"  wrote:

to know about github discussions, you’d need to scan all issues and prs
constantly which isn’t a reasonable expectation. dev is where discussions
are supposed to happen in a apache, PERIOD.

Apache isn’t dmlc. I wish some people would stop trying to turn Apache
conventions into dmlc conventions.  seems this is a constant push from day
one.


On Wed, Jul 18, 2018 at 9:39 AM Sheng Zha  wrote:

> Thanks, I hear the concerns and it's not my intention to push people off
> the list. On the other hand, I think github discussions are no more
> "artificial" than discussions on dev list, and the good and important
> discussions warrant the same amount of attention. With this vote, I intend
> to make contributors' life easier by decoupling the recognized forum from
> the technology they use, and that github contributors can easily
> communicate with the community on the list.
>
> -sz
>
> On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> christopher.bar...@analog.com> wrote:
>
> > Can't you simply tell contributors to discuss changes on dev before
> > submitting a PR? Since the contribution guidelines don't tell developers
> to
> > post to dev, why would you expect them to do that?
> >
> > Is there an easy way to just subscribe to PR notifications or will
> someone
> > have to write a filter to avoid spamming dev with all GitHub
> notifications?
> > I think that if dev gets too much traffic, then people with casual
> interest
> > may find it easier to unsubscribe than to set up filters. Once someone
> > unsubscribes, they probably won't be coming back soon, so you should be
> > very careful with this.
> >
> > I don't see why artificially increasing the traffic on dev will do
> > anything to grow the community in any case.
> >
> > - C
> >
> > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> >
> > Some mentors/contributors/committees feel that the amount of
> > discussions in
> > dev list is too less given the amount of commits that happen and 
more
> > discussions need to happen in the dev list to grow the community.
> >
> > In response some committees feel discussions actually happen in
> GitHub
> > PRs.
> > If the policy says "if it didn't happen in dev, it didn't happen",
> > let's
> > forward all GitHub discussions to dev so those discussions would
> count.
> > That's the motivation for this vote.
> >
> > I think when people say there needs to be more discussions in the 
dev
> > list,
> > I assume they mean the kind of discussions that happen *before* a PR
> is
> > created or even before someone starts working on anything. I don't
> > think
> > people are asking an email for every activity on GitHub. The correct
> > way to
> > address the problem would be for committees/contributors to stop
> > communicating in private channels (like Amazon or DMLC communication
> > channels) and do those discussions in the dev list instead.
> >
> > Indu
> >
> >
> > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > Can't people already subscribe to github notifications? I think it
> > is safe
> > > to assume that developers are already smart enough to figure out
> how
> > to do
> > > that if they want. What problem are you really trying to solve
> here?
> > >
> > > On 7/18/18, 4:49 AM, "Chris Olivier" 
> wrote:
> > >
> > > -1.  (changed from -0.9)
> > >
> > > seems more like a strategy (whether intentional or on 
accident)
> > to
> > > *not*
> > > have design discussions on dev by flooding it with noise and
> > then later
> > > claim it was discussed, even though you would have to sift
> > through
> > > thousands of emails to find it.
> > >
> > >
> > >
> > > On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol <
> > rahulhuil...@gmail.com
> > > >
> > > wrote:
> > >
> > > > I pulled up some more stats so we can make an informed
> > decision.
> > > >
> > > > Here are some popular Apache projects and the number of
> emails
> > to
> > > their
> > > > dev@
> > > > list 

Re: [VOTE] Subscribe dev@ to Github Activities

[Tianqi Chen]

Being Apache is about being inclusive to the new contributors. Apache
encourages the use of Github, and currently, the community is doing so.

I don't think it is a good idea to use political terms to force proliferate
our contributors --- we are all Apache contributors. Instead, we should
make all contributors feel inclusive under the frameworks of Apache
(including those who contribute and discuss through github, which is
currently the majority).

On the other hand, the filtering mechanism would work for those who do not
want to receive the content.

Tianqi

On Wed, Jul 18, 2018 at 10:21 AM, Chris Olivier 
wrote:

> to know about github discussions, you’d need to scan all issues and prs
> constantly which isn’t a reasonable expectation. dev is where discussions
> are supposed to happen in a apache, PERIOD.
>
> Apache isn’t dmlc. I wish some people would stop trying to turn Apache
> conventions into dmlc conventions.  seems this is a constant push from day
> one.
>
>
> On Wed, Jul 18, 2018 at 9:39 AM Sheng Zha  wrote:
>
> > Thanks, I hear the concerns and it's not my intention to push people off
> > the list. On the other hand, I think github discussions are no more
> > "artificial" than discussions on dev list, and the good and important
> > discussions warrant the same amount of attention. With this vote, I
> intend
> > to make contributors' life easier by decoupling the recognized forum from
> > the technology they use, and that github contributors can easily
> > communicate with the community on the list.
> >
> > -sz
> >
> > On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > Can't you simply tell contributors to discuss changes on dev before
> > > submitting a PR? Since the contribution guidelines don't tell
> developers
> > to
> > > post to dev, why would you expect them to do that?
> > >
> > > Is there an easy way to just subscribe to PR notifications or will
> > someone
> > > have to write a filter to avoid spamming dev with all GitHub
> > notifications?
> > > I think that if dev gets too much traffic, then people with casual
> > interest
> > > may find it easier to unsubscribe than to set up filters. Once someone
> > > unsubscribes, they probably won't be coming back soon, so you should be
> > > very careful with this.
> > >
> > > I don't see why artificially increasing the traffic on dev will do
> > > anything to grow the community in any case.
> > >
> > > - C
> > >
> > > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> > >
> > > Some mentors/contributors/committees feel that the amount of
> > > discussions in
> > > dev list is too less given the amount of commits that happen and
> more
> > > discussions need to happen in the dev list to grow the community.
> > >
> > > In response some committees feel discussions actually happen in
> > GitHub
> > > PRs.
> > > If the policy says "if it didn't happen in dev, it didn't happen",
> > > let's
> > > forward all GitHub discussions to dev so those discussions would
> > count.
> > > That's the motivation for this vote.
> > >
> > > I think when people say there needs to be more discussions in the
> dev
> > > list,
> > > I assume they mean the kind of discussions that happen *before* a
> PR
> > is
> > > created or even before someone starts working on anything. I don't
> > > think
> > > people are asking an email for every activity on GitHub. The
> correct
> > > way to
> > > address the problem would be for committees/contributors to stop
> > > communicating in private channels (like Amazon or DMLC
> communication
> > > channels) and do those discussions in the dev list instead.
> > >
> > > Indu
> > >
> > >
> > > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> > > christopher.bar...@analog.com> wrote:
> > >
> > > > Can't people already subscribe to github notifications? I think
> it
> > > is safe
> > > > to assume that developers are already smart enough to figure out
> > how
> > > to do
> > > > that if they want. What problem are you really trying to solve
> > here?
> > > >
> > > > On 7/18/18, 4:49 AM, "Chris Olivier" 
> > wrote:
> > > >
> > > > -1.  (changed from -0.9)
> > > >
> > > > seems more like a strategy (whether intentional or on
> accident)
> > > to
> > > > *not*
> > > > have design discussions on dev by flooding it with noise and
> > > then later
> > > > claim it was discussed, even though you would have to sift
> > > through
> > > > thousands of emails to find it.
> > > >
> > > >
> > > >
> > > > On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol <
> > > rahulhuil...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > I pulled up some more stats so we can make an informed
> > > decision.
> > > > >
> > > > > Here are some popular Apache projects and the number of
> > emails
> > > to
> > > > their

Re: [VOTE] Subscribe dev@ to Github Activities

[Chris Olivier]

to know about github discussions, you’d need to scan all issues and prs
constantly which isn’t a reasonable expectation. dev is where discussions
are supposed to happen in a apache, PERIOD.

Apache isn’t dmlc. I wish some people would stop trying to turn Apache
conventions into dmlc conventions.  seems this is a constant push from day
one.


On Wed, Jul 18, 2018 at 9:39 AM Sheng Zha  wrote:

> Thanks, I hear the concerns and it's not my intention to push people off
> the list. On the other hand, I think github discussions are no more
> "artificial" than discussions on dev list, and the good and important
> discussions warrant the same amount of attention. With this vote, I intend
> to make contributors' life easier by decoupling the recognized forum from
> the technology they use, and that github contributors can easily
> communicate with the community on the list.
>
> -sz
>
> On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> christopher.bar...@analog.com> wrote:
>
> > Can't you simply tell contributors to discuss changes on dev before
> > submitting a PR? Since the contribution guidelines don't tell developers
> to
> > post to dev, why would you expect them to do that?
> >
> > Is there an easy way to just subscribe to PR notifications or will
> someone
> > have to write a filter to avoid spamming dev with all GitHub
> notifications?
> > I think that if dev gets too much traffic, then people with casual
> interest
> > may find it easier to unsubscribe than to set up filters. Once someone
> > unsubscribes, they probably won't be coming back soon, so you should be
> > very careful with this.
> >
> > I don't see why artificially increasing the traffic on dev will do
> > anything to grow the community in any case.
> >
> > - C
> >
> > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> >
> > Some mentors/contributors/committees feel that the amount of
> > discussions in
> > dev list is too less given the amount of commits that happen and more
> > discussions need to happen in the dev list to grow the community.
> >
> > In response some committees feel discussions actually happen in
> GitHub
> > PRs.
> > If the policy says "if it didn't happen in dev, it didn't happen",
> > let's
> > forward all GitHub discussions to dev so those discussions would
> count.
> > That's the motivation for this vote.
> >
> > I think when people say there needs to be more discussions in the dev
> > list,
> > I assume they mean the kind of discussions that happen *before* a PR
> is
> > created or even before someone starts working on anything. I don't
> > think
> > people are asking an email for every activity on GitHub. The correct
> > way to
> > address the problem would be for committees/contributors to stop
> > communicating in private channels (like Amazon or DMLC communication
> > channels) and do those discussions in the dev list instead.
> >
> > Indu
> >
> >
> > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > Can't people already subscribe to github notifications? I think it
> > is safe
> > > to assume that developers are already smart enough to figure out
> how
> > to do
> > > that if they want. What problem are you really trying to solve
> here?
> > >
> > > On 7/18/18, 4:49 AM, "Chris Olivier" 
> wrote:
> > >
> > > -1.  (changed from -0.9)
> > >
> > > seems more like a strategy (whether intentional or on accident)
> > to
> > > *not*
> > > have design discussions on dev by flooding it with noise and
> > then later
> > > claim it was discussed, even though you would have to sift
> > through
> > > thousands of emails to find it.
> > >
> > >
> > >
> > > On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol <
> > rahulhuil...@gmail.com
> > > >
> > > wrote:
> > >
> > > > I pulled up some more stats so we can make an informed
> > decision.
> > > >
> > > > Here are some popular Apache projects and the number of
> emails
> > to
> > > their
> > > > dev@
> > > > list in the last 30 days
> > > > Apache Flink: 540 mails
> > > > ​Apache Spark: 249 mails
> > > > Apache Hive: 481 mails
> > > > Apache HBase: 300 mails
> > > >
> > > > Current dev list for MXNet: 348 mails
> > > > Current commits list for MXNet: 5329 mails
> > > > Making the proposed dev list for MXNet to be ~5677 mails.
> > > >
> > > > Sheng, even going by your comments that 1 of of those 4 mails
> > are
> > > relevant
> > > > for dev@, that's still a really high number of emails. (130
> > email
> > > lists
> > > > doesn't say anything if we ignore the actual number of emails
> > in
> > > those
> > > > lists, especially when the 131st sends these many mails :) ).
> > People
> > > are
> > > 

Re: [VOTE] Subscribe dev@ to Github Activities

[Tianqi Chen]

Discussions happened on Github are highly valuable, as a matter of fact, we
have quite a lot of proliferating contributors who discuss things on
GitHub when they contribute.
We need to be inclusive to these contributors, to welcome and recognize
these discussions.

The filtering solutions seem to be good enough for people who do not want
to receive these messages, so I see there is no down side from doing this

Tianqi


On Wed, Jul 18, 2018 at 9:39 AM, Sheng Zha  wrote:

> Thanks, I hear the concerns and it's not my intention to push people off
> the list. On the other hand, I think github discussions are no more
> "artificial" than discussions on dev list, and the good and important
> discussions warrant the same amount of attention. With this vote, I intend
> to make contributors' life easier by decoupling the recognized forum from
> the technology they use, and that github contributors can easily
> communicate with the community on the list.
>
> -sz
>
> On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> christopher.bar...@analog.com> wrote:
>
> > Can't you simply tell contributors to discuss changes on dev before
> > submitting a PR? Since the contribution guidelines don't tell developers
> to
> > post to dev, why would you expect them to do that?
> >
> > Is there an easy way to just subscribe to PR notifications or will
> someone
> > have to write a filter to avoid spamming dev with all GitHub
> notifications?
> > I think that if dev gets too much traffic, then people with casual
> interest
> > may find it easier to unsubscribe than to set up filters. Once someone
> > unsubscribes, they probably won't be coming back soon, so you should be
> > very careful with this.
> >
> > I don't see why artificially increasing the traffic on dev will do
> > anything to grow the community in any case.
> >
> > - C
> >
> > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> >
> > Some mentors/contributors/committees feel that the amount of
> > discussions in
> > dev list is too less given the amount of commits that happen and more
> > discussions need to happen in the dev list to grow the community.
> >
> > In response some committees feel discussions actually happen in
> GitHub
> > PRs.
> > If the policy says "if it didn't happen in dev, it didn't happen",
> > let's
> > forward all GitHub discussions to dev so those discussions would
> count.
> > That's the motivation for this vote.
> >
> > I think when people say there needs to be more discussions in the dev
> > list,
> > I assume they mean the kind of discussions that happen *before* a PR
> is
> > created or even before someone starts working on anything. I don't
> > think
> > people are asking an email for every activity on GitHub. The correct
> > way to
> > address the problem would be for committees/contributors to stop
> > communicating in private channels (like Amazon or DMLC communication
> > channels) and do those discussions in the dev list instead.
> >
> > Indu
> >
> >
> > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > Can't people already subscribe to github notifications? I think it
> > is safe
> > > to assume that developers are already smart enough to figure out
> how
> > to do
> > > that if they want. What problem are you really trying to solve
> here?
> > >
> > > On 7/18/18, 4:49 AM, "Chris Olivier" 
> wrote:
> > >
> > > -1.  (changed from -0.9)
> > >
> > > seems more like a strategy (whether intentional or on accident)
> > to
> > > *not*
> > > have design discussions on dev by flooding it with noise and
> > then later
> > > claim it was discussed, even though you would have to sift
> > through
> > > thousands of emails to find it.
> > >
> > >
> > >
> > > On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol <
> > rahulhuil...@gmail.com
> > > >
> > > wrote:
> > >
> > > > I pulled up some more stats so we can make an informed
> > decision.
> > > >
> > > > Here are some popular Apache projects and the number of
> emails
> > to
> > > their
> > > > dev@
> > > > list in the last 30 days
> > > > Apache Flink: 540 mails
> > > > ​Apache Spark: 249 mails
> > > > Apache Hive: 481 mails
> > > > Apache HBase: 300 mails
> > > >
> > > > Current dev list for MXNet: 348 mails
> > > > Current commits list for MXNet: 5329 mails
> > > > Making the proposed dev list for MXNet to be ~5677 mails.
> > > >
> > > > Sheng, even going by your comments that 1 of of those 4 mails
> > are
> > > relevant
> > > > for dev@, that's still a really high number of emails. (130
> > email
> > > lists
> > > > doesn't say anything if we ignore the actual number of emails
> > in
> > > those
> > > > lists, especially 

Re: [VOTE] Subscribe dev@ to Github Activities

[Sheng Zha]

Thanks, I hear the concerns and it's not my intention to push people off
the list. On the other hand, I think github discussions are no more
"artificial" than discussions on dev list, and the good and important
discussions warrant the same amount of attention. With this vote, I intend
to make contributors' life easier by decoupling the recognized forum from
the technology they use, and that github contributors can easily
communicate with the community on the list.

-sz

On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
christopher.bar...@analog.com> wrote:

> Can't you simply tell contributors to discuss changes on dev before
> submitting a PR? Since the contribution guidelines don't tell developers to
> post to dev, why would you expect them to do that?
>
> Is there an easy way to just subscribe to PR notifications or will someone
> have to write a filter to avoid spamming dev with all GitHub notifications?
> I think that if dev gets too much traffic, then people with casual interest
> may find it easier to unsubscribe than to set up filters. Once someone
> unsubscribes, they probably won't be coming back soon, so you should be
> very careful with this.
>
> I don't see why artificially increasing the traffic on dev will do
> anything to grow the community in any case.
>
> - C
>
> On 7/18/18, 11:17 AM, "Indhu"  wrote:
>
> Some mentors/contributors/committees feel that the amount of
> discussions in
> dev list is too less given the amount of commits that happen and more
> discussions need to happen in the dev list to grow the community.
>
> In response some committees feel discussions actually happen in GitHub
> PRs.
> If the policy says "if it didn't happen in dev, it didn't happen",
> let's
> forward all GitHub discussions to dev so those discussions would count.
> That's the motivation for this vote.
>
> I think when people say there needs to be more discussions in the dev
> list,
> I assume they mean the kind of discussions that happen *before* a PR is
> created or even before someone starts working on anything. I don't
> think
> people are asking an email for every activity on GitHub. The correct
> way to
> address the problem would be for committees/contributors to stop
> communicating in private channels (like Amazon or DMLC communication
> channels) and do those discussions in the dev list instead.
>
> Indu
>
>
> On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> christopher.bar...@analog.com> wrote:
>
> > Can't people already subscribe to github notifications? I think it
> is safe
> > to assume that developers are already smart enough to figure out how
> to do
> > that if they want. What problem are you really trying to solve here?
> >
> > On 7/18/18, 4:49 AM, "Chris Olivier"  wrote:
> >
> > -1.  (changed from -0.9)
> >
> > seems more like a strategy (whether intentional or on accident)
> to
> > *not*
> > have design discussions on dev by flooding it with noise and
> then later
> > claim it was discussed, even though you would have to sift
> through
> > thousands of emails to find it.
> >
> >
> >
> > On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol <
> rahulhuil...@gmail.com
> > >
> > wrote:
> >
> > > I pulled up some more stats so we can make an informed
> decision.
> > >
> > > Here are some popular Apache projects and the number of emails
> to
> > their
> > > dev@
> > > list in the last 30 days
> > > Apache Flink: 540 mails
> > > ​Apache Spark: 249 mails
> > > Apache Hive: 481 mails
> > > Apache HBase: 300 mails
> > >
> > > Current dev list for MXNet: 348 mails
> > > Current commits list for MXNet: 5329 mails
> > > Making the proposed dev list for MXNet to be ~5677 mails.
> > >
> > > Sheng, even going by your comments that 1 of of those 4 mails
> are
> > relevant
> > > for dev@, that's still a really high number of emails. (130
> email
> > lists
> > > doesn't say anything if we ignore the actual number of emails
> in
> > those
> > > lists, especially when the 131st sends these many mails :) ).
> People
> > are
> > > already talking about setting up filters here. Doesn't that
> defeat
> > the
> > > purpose by making people filter out the discussion on Github?
> People
> > can
> > > subscribe to commits@ if they find it more convenient to
> follow
> > Github
> > > activity over email rather than Github.com.
> > >
> > > We should strive to maintain dev@ as a place for high quality
> > discussion.
> > > It's upto the contributors to bring up something to dev@ if
> they
> > believe
> > > it
> > > deserves a focused discussion in the community. That
> discussion may
>

Re: [VOTE] Subscribe dev@ to Github Activities

[Sheng Zha]

A discussion is a discussion, and in the case of MXNet I’d say a lot more high 
quality discussion has happened on GitHub than on dev@. Github issues have 
plenty of discussions before code change. The reason is simply because MXNet 
has longer history on Github than the existence of dev list, and long-term 
contributors tend to bring high quality discussion on dev@.

I don’t intend to flood the dev list with this vote. There are high quality 
discussions on the github that people on dev list can benefit from, and that’s 
the only intention for such change. The community feedback will help decide how 
to best integrate these two communication tools. However, some good solutions 
such as the “opt-in w/ github mention” that Qing has brought up will require 
exploration with apache infra team, which requires a vote to show the will of 
the community first.

-sz


> On Jul 18, 2018, at 8:16 AM, Indue  wrote:
> 
> Some mentors/contributors/committees feel that the amount of discussions in
> dev list is too less given the amount of commits that happen and more
> discussions need to happen in the dev list to grow the community.
> 
> In response some committees feel discussions actually happen in GitHub PRs.
> If the policy says "if it didn't happen in dev, it didn't happen", let's
> forward all GitHub discussions to dev so those discussions would count.
> That's the motivation for this vote.
> 
> I think when people say there needs to be more discussions in the dev list,
> I assume they mean the kind of discussions that happen *before* a PR is
> created or even before someone starts working on anything. I don't think
> people are asking an email for every activity on GitHub. The correct way to
> address the problem would be for committees/contributors to stop
> communicating in private channels (like Amazon or DMLC communication
> channels) and do those discussions in the dev list instead.
> 
> Indu
> 
> 
> On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> christopher.bar...@analog.com> wrote:
> 
>> Can't people already subscribe to github notifications? I think it is safe
>> to assume that developers are already smart enough to figure out how to do
>> that if they want. What problem are you really trying to solve here?
>> 
>> On 7/18/18, 4:49 AM, "Chris Olivier"  wrote:
>> 
>>-1.  (changed from -0.9)
>> 
>>seems more like a strategy (whether intentional or on accident) to
>> *not*
>>have design discussions on dev by flooding it with noise and then later
>>claim it was discussed, even though you would have to sift through
>>thousands of emails to find it.
>> 
>> 
>> 
>>On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol >> 
>>wrote:
>> 
>>> I pulled up some more stats so we can make an informed decision.
>>> 
>>> Here are some popular Apache projects and the number of emails to
>> their
>>> dev@
>>> list in the last 30 days
>>> Apache Flink: 540 mails
>>> ​Apache Spark: 249 mails
>>> Apache Hive: 481 mails
>>> Apache HBase: 300 mails
>>> 
>>> Current dev list for MXNet: 348 mails
>>> Current commits list for MXNet: 5329 mails
>>> Making the proposed dev list for MXNet to be ~5677 mails.
>>> 
>>> Sheng, even going by your comments that 1 of of those 4 mails are
>> relevant
>>> for dev@, that's still a really high number of emails. (130 email
>> lists
>>> doesn't say anything if we ignore the actual number of emails in
>> those
>>> lists, especially when the 131st sends these many mails :) ). People
>> are
>>> already talking about setting up filters here. Doesn't that defeat
>> the
>>> purpose by making people filter out the discussion on Github? People
>> can
>>> subscribe to commits@ if they find it more convenient to follow
>> Github
>>> activity over email rather than Github.com.
>>> 
>>> We should strive to maintain dev@ as a place for high quality
>> discussion.
>>> It's upto the contributors to bring up something to dev@ if they
>> believe
>>> it
>>> deserves a focused discussion in the community. That discussion may
>> be
>>> started by the person who proposes code changes, or a reviewer who
>> believes
>>> that a particular code change warrants further discussion.
>>> 
>>> Regards,
>>> Rahul
>>> 
>> 
>> 
>> 

Re: [VOTE] Subscribe dev@ to Github Activities

[Barber, Christopher]

Can't you simply tell contributors to discuss changes on dev before submitting 
a PR? Since the contribution guidelines don't tell developers to post to dev, 
why would you expect them to do that?

Is there an easy way to just subscribe to PR notifications or will someone have 
to write a filter to avoid spamming dev with all GitHub notifications? I think 
that if dev gets too much traffic, then people with casual interest may find it 
easier to unsubscribe than to set up filters. Once someone unsubscribes, they 
probably won't be coming back soon, so you should be very careful with this.

I don't see why artificially increasing the traffic on dev will do anything to 
grow the community in any case.

- C

On 7/18/18, 11:17 AM, "Indhu"  wrote:

Some mentors/contributors/committees feel that the amount of discussions in
dev list is too less given the amount of commits that happen and more
discussions need to happen in the dev list to grow the community.

In response some committees feel discussions actually happen in GitHub PRs.
If the policy says "if it didn't happen in dev, it didn't happen", let's
forward all GitHub discussions to dev so those discussions would count.
That's the motivation for this vote.

I think when people say there needs to be more discussions in the dev list,
I assume they mean the kind of discussions that happen *before* a PR is
created or even before someone starts working on anything. I don't think
people are asking an email for every activity on GitHub. The correct way to
address the problem would be for committees/contributors to stop
communicating in private channels (like Amazon or DMLC communication
channels) and do those discussions in the dev list instead.

Indu


On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
christopher.bar...@analog.com> wrote:

> Can't people already subscribe to github notifications? I think it is safe
> to assume that developers are already smart enough to figure out how to do
> that if they want. What problem are you really trying to solve here?
>
> On 7/18/18, 4:49 AM, "Chris Olivier"  wrote:
>
> -1.  (changed from -0.9)
>
> seems more like a strategy (whether intentional or on accident) to
> *not*
> have design discussions on dev by flooding it with noise and then 
later
> claim it was discussed, even though you would have to sift through
> thousands of emails to find it.
>
>
>
> On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol  >
> wrote:
>
> > I pulled up some more stats so we can make an informed decision.
> >
> > Here are some popular Apache projects and the number of emails to
> their
> > dev@
> > list in the last 30 days
> > Apache Flink: 540 mails
> > ​Apache Spark: 249 mails
> > Apache Hive: 481 mails
> > Apache HBase: 300 mails
> >
> > Current dev list for MXNet: 348 mails
> > Current commits list for MXNet: 5329 mails
> > Making the proposed dev list for MXNet to be ~5677 mails.
> >
> > Sheng, even going by your comments that 1 of of those 4 mails are
> relevant
> > for dev@, that's still a really high number of emails. (130 email
> lists
> > doesn't say anything if we ignore the actual number of emails in
> those
> > lists, especially when the 131st sends these many mails :) ). People
> are
> > already talking about setting up filters here. Doesn't that defeat
> the
> > purpose by making people filter out the discussion on Github? People
> can
> > subscribe to commits@ if they find it more convenient to follow
> Github
> > activity over email rather than Github.com.
> >
> > We should strive to maintain dev@ as a place for high quality
> discussion.
> > It's upto the contributors to bring up something to dev@ if they
> believe
> > it
> > deserves a focused discussion in the community. That discussion may
> be
> > started by the person who proposes code changes, or a reviewer who
> believes
> > that a particular code change warrants further discussion.
> >
> > Regards,
> > Rahul
> >
>
>
>

Re: [VOTE] Subscribe dev@ to Github Activities

[Indhu]

Some mentors/contributors/committees feel that the amount of discussions in
dev list is too less given the amount of commits that happen and more
discussions need to happen in the dev list to grow the community.

In response some committees feel discussions actually happen in GitHub PRs.
If the policy says "if it didn't happen in dev, it didn't happen", let's
forward all GitHub discussions to dev so those discussions would count.
That's the motivation for this vote.

I think when people say there needs to be more discussions in the dev list,
I assume they mean the kind of discussions that happen *before* a PR is
created or even before someone starts working on anything. I don't think
people are asking an email for every activity on GitHub. The correct way to
address the problem would be for committees/contributors to stop
communicating in private channels (like Amazon or DMLC communication
channels) and do those discussions in the dev list instead.

Indu


On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
christopher.bar...@analog.com> wrote:

> Can't people already subscribe to github notifications? I think it is safe
> to assume that developers are already smart enough to figure out how to do
> that if they want. What problem are you really trying to solve here?
>
> On 7/18/18, 4:49 AM, "Chris Olivier"  wrote:
>
> -1.  (changed from -0.9)
>
> seems more like a strategy (whether intentional or on accident) to
> *not*
> have design discussions on dev by flooding it with noise and then later
> claim it was discussed, even though you would have to sift through
> thousands of emails to find it.
>
>
>
> On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol  >
> wrote:
>
> > I pulled up some more stats so we can make an informed decision.
> >
> > Here are some popular Apache projects and the number of emails to
> their
> > dev@
> > list in the last 30 days
> > Apache Flink: 540 mails
> > ​Apache Spark: 249 mails
> > Apache Hive: 481 mails
> > Apache HBase: 300 mails
> >
> > Current dev list for MXNet: 348 mails
> > Current commits list for MXNet: 5329 mails
> > Making the proposed dev list for MXNet to be ~5677 mails.
> >
> > Sheng, even going by your comments that 1 of of those 4 mails are
> relevant
> > for dev@, that's still a really high number of emails. (130 email
> lists
> > doesn't say anything if we ignore the actual number of emails in
> those
> > lists, especially when the 131st sends these many mails :) ). People
> are
> > already talking about setting up filters here. Doesn't that defeat
> the
> > purpose by making people filter out the discussion on Github? People
> can
> > subscribe to commits@ if they find it more convenient to follow
> Github
> > activity over email rather than Github.com.
> >
> > We should strive to maintain dev@ as a place for high quality
> discussion.
> > It's upto the contributors to bring up something to dev@ if they
> believe
> > it
> > deserves a focused discussion in the community. That discussion may
> be
> > started by the person who proposes code changes, or a reviewer who
> believes
> > that a particular code change warrants further discussion.
> >
> > Regards,
> > Rahul
> >
>
>
>

Re: [VOTE] Subscribe dev@ to Github Activities

[Barber, Christopher]

Can't people already subscribe to github notifications? I think it is safe to 
assume that developers are already smart enough to figure out how to do that if 
they want. What problem are you really trying to solve here?

On 7/18/18, 4:49 AM, "Chris Olivier"  wrote:

-1.  (changed from -0.9)

seems more like a strategy (whether intentional or on accident) to *not*
have design discussions on dev by flooding it with noise and then later
claim it was discussed, even though you would have to sift through
thousands of emails to find it.



On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol 
wrote:

> I pulled up some more stats so we can make an informed decision.
>
> Here are some popular Apache projects and the number of emails to their
> dev@
> list in the last 30 days
> Apache Flink: 540 mails
> ​Apache Spark: 249 mails
> Apache Hive: 481 mails
> Apache HBase: 300 mails
>
> Current dev list for MXNet: 348 mails
> Current commits list for MXNet: 5329 mails
> Making the proposed dev list for MXNet to be ~5677 mails.
>
> Sheng, even going by your comments that 1 of of those 4 mails are relevant
> for dev@, that's still a really high number of emails. (130 email lists
> doesn't say anything if we ignore the actual number of emails in those
> lists, especially when the 131st sends these many mails :) ). People are
> already talking about setting up filters here. Doesn't that defeat the
> purpose by making people filter out the discussion on Github? People can
> subscribe to commits@ if they find it more convenient to follow Github
> activity over email rather than Github.com.
>
> We should strive to maintain dev@ as a place for high quality discussion.
> It's upto the contributors to bring up something to dev@ if they believe
> it
> deserves a focused discussion in the community. That discussion may be
> started by the person who proposes code changes, or a reviewer who 
believes
> that a particular code change warrants further discussion.
>
> Regards,
> Rahul
>

Re: [VOTE] Subscribe dev@ to Github Activities

[Chris Olivier]

-1.  (changed from -0.9)

seems more like a strategy (whether intentional or on accident) to *not*
have design discussions on dev by flooding it with noise and then later
claim it was discussed, even though you would have to sift through
thousands of emails to find it.



On Wed, Jul 18, 2018 at 12:42 AM Rahul Huilgol 
wrote:

> I pulled up some more stats so we can make an informed decision.
>
> Here are some popular Apache projects and the number of emails to their
> dev@
> list in the last 30 days
> Apache Flink: 540 mails
> ​Apache Spark: 249 mails
> Apache Hive: 481 mails
> Apache HBase: 300 mails
>
> Current dev list for MXNet: 348 mails
> Current commits list for MXNet: 5329 mails
> Making the proposed dev list for MXNet to be ~5677 mails.
>
> Sheng, even going by your comments that 1 of of those 4 mails are relevant
> for dev@, that's still a really high number of emails. (130 email lists
> doesn't say anything if we ignore the actual number of emails in those
> lists, especially when the 131st sends these many mails :) ). People are
> already talking about setting up filters here. Doesn't that defeat the
> purpose by making people filter out the discussion on Github? People can
> subscribe to commits@ if they find it more convenient to follow Github
> activity over email rather than Github.com.
>
> We should strive to maintain dev@ as a place for high quality discussion.
> It's upto the contributors to bring up something to dev@ if they believe
> it
> deserves a focused discussion in the community. That discussion may be
> started by the person who proposes code changes, or a reviewer who believes
> that a particular code change warrants further discussion.
>
> Regards,
> Rahul
>

Re: [VOTE] Subscribe dev@ to Github Activities

[Rahul Huilgol]

I pulled up some more stats so we can make an informed decision.

Here are some popular Apache projects and the number of emails to their dev@
list in the last 30 days
Apache Flink: 540 mails
​Apache Spark: 249 mails
Apache Hive: 481 mails
Apache HBase: 300 mails

Current dev list for MXNet: 348 mails
Current commits list for MXNet: 5329 mails
Making the proposed dev list for MXNet to be ~5677 mails.

Sheng, even going by your comments that 1 of of those 4 mails are relevant
for dev@, that's still a really high number of emails. (130 email lists
doesn't say anything if we ignore the actual number of emails in those
lists, especially when the 131st sends these many mails :) ). People are
already talking about setting up filters here. Doesn't that defeat the
purpose by making people filter out the discussion on Github? People can
subscribe to commits@ if they find it more convenient to follow Github
activity over email rather than Github.com.

We should strive to maintain dev@ as a place for high quality discussion.
It's upto the contributors to bring up something to dev@ if they believe it
deserves a focused discussion in the community. That discussion may be
started by the person who proposes code changes, or a reviewer who believes
that a particular code change warrants further discussion.

Regards,
Rahul

Re: [VOTE] Subscribe dev@ to Github Activities

[Sheng Zha]

From the linked discussion thread you can find comments that Flink does and 
Spark used to but not any more.

I don’t intend to claim anything on this vote thread, though one thing is 
clear: without this change, github activity doesn’t count as happening per 
apache standard, because it didn’t happen on dev@. I do personally like 
Tianqi’s take that this will help us discover contributors who are prolific in 
development besides those in writing emails.

-sz

> On Jul 17, 2018, at 11:21 PM, Chris Olivier  wrote:
> 
> -0.9
> 
> Do any other Apache projects do this? Seems really odd. Jira was posting to
> dev for maybe 3 days and people were complaining like crazy about the
> noise, and that was just a few tickets. Now we’re talking about possibly
> hundreds of emails per day. ALL PR comments, commit notificatios, issue
> movement, tagging, etc.
> 
> It’s hard to imagine how this would be useful.
> 
> Also, does this also mean that claiming that anything said or done in
> github “was discusssd on dev”?
> 
> -C
> 
>> On Tue, Jul 17, 2018 at 2:24 PM Sheng Zha  wrote:
>> 
>> Thanks, Rahul. Out of the 4 conversations you listed that you think are not
>> necessary, I actually think the PR on coreml tool may be worth discussing.
>> For example, should it (and other tools) have a separate repo, and should
>> its version management be tied to mxnet.
>> 
>> And on:
>> 
>>> If people are forced to setup filters to parse these mails, then we are
>> *ensuring*
>> people don't get their eyes on valuable discussions on dev@.
>> 
>> I think this argument is based more on emotion than on reason. I subscribe
>> to over 130 email lists for work, lots of which has PR/commit updates that
>> are not my immediate concern, and it hasn't prevented me from reading
>> valuable discussions.
>> 
>> -sz
>> 
>> On Tue, Jul 17, 2018 at 1:05 PM, Rahul Huilgol 
>> wrote:
>> 
>>> -1
>>> 
>>> We had such a thing before and people asked for the mails to be
>> redirected
>>> to a different list commits@ because of the flood of mails.
>>> 
>>> https://lists.apache.org/thread.html/8b834e39110381fadb8a0ab59185a8
>>> f52b8406247a1f281f7d691392@%3Cdev.mxnet.apache.org%3E
>>> 
>>> I don't know if people have a sense of the volume of mails this can add
>>> here. Here's the stats from the commits@ email list we have. I'd be
>>> curious
>>> to see how many subscribers we have to that. Hopefully the people voting
>> +1
>>> here subscribed to that :)
>>> 
>>> 2018 June: 4617
>>> 2018 July: (half a month) 3106
>>> (Source of the numbers are here
>>> https://lists.apache.org/list.html?comm...@mxnet.apache.org:2018-7)
>>> 
>>> @Joshua: yes we need to bring 'valuable' (emphasis mine) discussion to a
>>> centralized place @dev. Does everything needs to be sent to dev@. For
>>> example, consider these recent PRs, why is it necessary for them to be
>>> forwarded to dev@?
>>> 
>>> fix flaky test test_operator_gpu.test_countsketch:
>>> https://github.com/apache/incubator-mxnet/pull/11780
>>> Update PyPI version number:
>>> https://github.com/apache/incubator-mxnet/pull/11773
>>> Fix file name creation for Windows:
>>> https://github.com/apache/incubator-mxnet/pull/11765
>>> [MXNET-8230] test_operator_gpu.test_rms fails:
>>> https://github.com/apache/incubator-mxnet/pull/11749
>>> 
>>> If people are forced to setup filters to parse these mails, then we are
>>> *ensuring* people don't get their eyes on valuable discussions on dev@.
>>> 
>>> Regards,
>>> Rahul
>>> 
 On Tue, Jul 17, 2018 at 12:49 PM, Sheng Zha  wrote:
 
 FWIW: "from:notificati...@github.com AND
>> to:dev@mxnet.incubator.apache.
>>> org
 AND NOT to:me" but I'm sure you get the gist :)
 
 
 Opt-in model applies to individuals rather than the dev list, because
>> the
 dev list is intended as an asynchronous way for new comers to easily
>>> follow
 past technical discussions, and is the only place recognized by apache
>>> for
 these discussions. Currently, lots of high quality technical
>> discussions
 that are happening on github are lost and not archived here. The
>>> procedural
 change in this vote is intended for bridging such gap. Besides, it's
>> more
 likely for new contributors to know how to filter emails than to know
>> how
 to "opt-in".
 
 
 More discussion is welcome in the linked discussion thread.
 
 
 -sz
 
 On Tue, Jul 17, 2018 at 12:37 PM, pracheer gupta <
 pracheer_gu...@hotmail.com
> wrote:
 
> FWIW: The filter needs to be more complicated than just "
> from:notificati...@github.com". After all, if someone mentions me
> directly in PR thread and/or I subscribe to only a particular PR,
>> those
> emails will also come from "notificati...@github.com". There are
>> ways
> around that though.
> 
> 
> It might be good to mention this filter in some wiki/webpage
>> somewhere;
> may save some effort for people trying to find the right set of
>>> filters.

RE: [VOTE] Release MXNet version 1.2.1.RC1

[Yasser Zamani]

Hi Sina,

Do you encounter that issue during building MXNet from source (including tests) 
or on your own code/test? Three days ago I was successful to build master via 
VS2017 with Intel MKL+MKLDNN support. If you have an own test/code which fails, 
please pull request it into master.

Regards.

>-Original Message-
>From: Jim Jagielski 
>Sent: Tuesday, July 17, 2018 5:06 PM
>To: dev@mxnet.incubator.apache.org
>Subject: Re: [VOTE] Release MXNet version 1.2.1.RC1
>
>FWIW, neither can I.
>
>> On Jul 16, 2018, at 8:45 PM, Anirudh  wrote:
>>
>> Hi Sina,
>>
>> I am unable to reproduce this issue on 1.2.1.
>>
>> Anirudh
>>
>> On Mon, Jul 16, 2018 at 5:26 PM, Afrooze, Sina  wrote:
>>
>>> I know voting is over for this release, but I think this issue may
>>> warrant
>>> delaying: https://github.com/apache/incubator-mxnet/issues/11772.
>>> Looks like save_parameters doesn't fix the issue it is designed to
>>> fix (i.e. two instances of the same network in the same session) if LSTMs 
>>> are
>used.
>>>
>>> - Sina
>>>
>>> On 7/12/18, 3:27 PM, "Hao Jin"  wrote:
>>>
>>>+1 Built on Ubuntu with CUDA 9.0 and CuDNN 7 and verified that
>>> sparse tests
>>>are passing.
>>>Hao
>>>
>>>On Thu, Jul 12, 2018 at 3:01 PM, Sergio Fernández
>>> 
>>> wrote:
>>>
 +1 (binding)

 On Mon, Jul 9, 2018, 16:53 Roshani Nagmote <
>>> roshaninagmo...@gmail.com>
 wrote:

> Hi all,
>
> I would like to propose a vote to release Apache MXNet (incubating)
 version
> 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50
>>> PM
> PDT, Thursday, July 12th.
>
> Link to release candidate 1.2.1.rc1:
> *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> 
> View this page, click on "Build from Source", and use the source
>>> code
> obtained from 1.2.1.rc1 tag:
> https://mxnet.incubator.apache.org/install/index.html
>
> (Note: The README.md points to the 1.2.1 tag and does not work at
>>> the
> moment.)
>
> Please remember to test first before voting accordingly:
>
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
> Thanks,
> Roshani
>

>>>
>>>
>>>
>>>

Re: [VOTE] Subscribe dev@ to Github Activities

[Chris Olivier]

-0.9

Do any other Apache projects do this? Seems really odd. Jira was posting to
dev for maybe 3 days and people were complaining like crazy about the
noise, and that was just a few tickets. Now we’re talking about possibly
hundreds of emails per day. ALL PR comments, commit notificatios, issue
movement, tagging, etc.

It’s hard to imagine how this would be useful.

Also, does this also mean that claiming that anything said or done in
github “was discusssd on dev”?

-C

On Tue, Jul 17, 2018 at 2:24 PM Sheng Zha  wrote:

> Thanks, Rahul. Out of the 4 conversations you listed that you think are not
> necessary, I actually think the PR on coreml tool may be worth discussing.
> For example, should it (and other tools) have a separate repo, and should
> its version management be tied to mxnet.
>
> And on:
>
> > If people are forced to setup filters to parse these mails, then we are
> *ensuring*
> people don't get their eyes on valuable discussions on dev@.
>
> I think this argument is based more on emotion than on reason. I subscribe
> to over 130 email lists for work, lots of which has PR/commit updates that
> are not my immediate concern, and it hasn't prevented me from reading
> valuable discussions.
>
> -sz
>
> On Tue, Jul 17, 2018 at 1:05 PM, Rahul Huilgol 
> wrote:
>
> > -1
> >
> > We had such a thing before and people asked for the mails to be
> redirected
> > to a different list commits@ because of the flood of mails.
> >
> > https://lists.apache.org/thread.html/8b834e39110381fadb8a0ab59185a8
> > f52b8406247a1f281f7d691392@%3Cdev.mxnet.apache.org%3E
> >
> > I don't know if people have a sense of the volume of mails this can add
> > here. Here's the stats from the commits@ email list we have. I'd be
> > curious
> > to see how many subscribers we have to that. Hopefully the people voting
> +1
> > here subscribed to that :)
> >
> > 2018 June: 4617
> > 2018 July: (half a month) 3106
> > (Source of the numbers are here
> > https://lists.apache.org/list.html?comm...@mxnet.apache.org:2018-7)
> >
> > @Joshua: yes we need to bring 'valuable' (emphasis mine) discussion to a
> > centralized place @dev. Does everything needs to be sent to dev@. For
> > example, consider these recent PRs, why is it necessary for them to be
> > forwarded to dev@?
> >
> > fix flaky test test_operator_gpu.test_countsketch:
> > https://github.com/apache/incubator-mxnet/pull/11780
> > Update PyPI version number:
> > https://github.com/apache/incubator-mxnet/pull/11773
> > Fix file name creation for Windows:
> > https://github.com/apache/incubator-mxnet/pull/11765
> > [MXNET-8230] test_operator_gpu.test_rms fails:
> > https://github.com/apache/incubator-mxnet/pull/11749
> >
> > If people are forced to setup filters to parse these mails, then we are
> > *ensuring* people don't get their eyes on valuable discussions on dev@.
> >
> > Regards,
> > Rahul
> >
> > On Tue, Jul 17, 2018 at 12:49 PM, Sheng Zha  wrote:
> >
> > > FWIW: "from:notificati...@github.com AND
> to:dev@mxnet.incubator.apache.
> > org
> > > AND NOT to:me" but I'm sure you get the gist :)
> > >
> > >
> > > Opt-in model applies to individuals rather than the dev list, because
> the
> > > dev list is intended as an asynchronous way for new comers to easily
> > follow
> > > past technical discussions, and is the only place recognized by apache
> > for
> > > these discussions. Currently, lots of high quality technical
> discussions
> > > that are happening on github are lost and not archived here. The
> > procedural
> > > change in this vote is intended for bridging such gap. Besides, it's
> more
> > > likely for new contributors to know how to filter emails than to know
> how
> > > to "opt-in".
> > >
> > >
> > > More discussion is welcome in the linked discussion thread.
> > >
> > >
> > > -sz
> > >
> > > On Tue, Jul 17, 2018 at 12:37 PM, pracheer gupta <
> > > pracheer_gu...@hotmail.com
> > > > wrote:
> > >
> > > > FWIW: The filter needs to be more complicated than just "
> > > > from:notificati...@github.com". After all, if someone mentions me
> > > > directly in PR thread and/or I subscribe to only a particular PR,
> those
> > > > emails will also come from "notificati...@github.com". There are
> ways
> > > > around that though.
> > > >
> > > >
> > > > It might be good to mention this filter in some wiki/webpage
> somewhere;
> > > > may save some effort for people trying to find the right set of
> > filters.
> > > It
> > > > could even be in the welcome email when one subscribes to this
> > > email-list.
> > > >
> > > >
> > > > Another alternate option: How about choosing an opt-in model rather
> > than
> > > > an opt-out model? Having another email list and anyone can subscribe
> to
> > > it
> > > > if they wish.
> > > >
> > > >
> > > > Not sure if there is a perfect answer out there for this but in
> > principle
> > > > I agree that it will be good to have "push notifications" for all
> > > PRs/issue.
> > > >
> > > >
> > > > -Pracheer
> > > >
> > > >