Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread 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 hap

RE: [VOTE] Release MXNet version 1.2.1.RC1

2018-07-17 Thread 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. >

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread 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 mo

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Sheng Zha
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

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Sheng Zha
Hi S, Keeping a separate list defeats the purpose, because then such conversation is again not happening on dev, which is deemed to be in the "did not happen" category. Also, conversations that are not relevant to you are already happening on the list, and you're under no obligation to read them a

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread K, S
-1 Keeping a separate email list for subscribing to github activities seems like a better idea. One can always reference the issue/discussion/PR in the dev list to initiate conversation. Biggest concern is that important discussion can get buried in a flood of emails that are not completely rel

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Rahul Huilgol
-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/8b834e39110381fadb8a0ab59185a8f52b8406247a1f281f7d691392@%3Cdev.mxnet.apache.org%3E I don't know if people have a sense o

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread YiZhi Liu
+1 On Tue, Jul 17, 2018 at 12:55 PM Joshua Z. Zhang wrote: > > +1 > > We NEED to bring valuable discussions to a centralized place (@dev for > example) rather than scattered single threads. > Per filter options, there are a lot we can do to improve the SNR. > > Zhi > > On 2018/07/17 16:26:01, She

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Joshua Z. Zhang
+1 We NEED to bring valuable discussions to a centralized place (@dev for example) rather than scattered single threads. Per filter options, there are a lot we can do to improve the SNR. Zhi On 2018/07/17 16:26:01, Sheng Zha wrote: > Hi Anirudh, > > 1. You need exactly one filter to filter o

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Sheng Zha
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 discussi

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread pracheer gupta
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

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Junru Shao
+1 Both GitHub activities and dev list are places for development. It will be great if we could have a all-in-one place for such discussions. I believe Sheng's proposal is a perfect solution. On 2018/07/16 03:32:06, Sheng Zha wrote: > Hi, > > I'm starting a vote on subscribing dev@ to Github

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Junru Shao
+1 Both GitHub activities and dev list are places for development. It will be great if we could have a all-in-one place for such discussions. I believe Sheng's proposal is a perfect solution. On 2018/07/16 03:32:06, Sheng Zha wrote: > Hi, > > I'm starting a vote on subscribing dev@ to Github act

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Anirudh Acharya
+1 On Tue, Jul 17, 2018 at 9:58 AM Anirudh wrote: > Its not foregoing transparency since people can easily subscribe to the > github activities individually. dev@ has been used till now for design > discussions, other project discussions, > votes etc. After we subscribe dev@ to all activities, I

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Anirudh
Its not foregoing transparency since people can easily subscribe to the github activities individually. dev@ has been used till now for design discussions, other project discussions, votes etc. After we subscribe dev@ to all activities, I am afraid dev@ will be reduced to a forwarded mail box and i

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Qing Lan
-1, unless we can keep this under control. It's not all of the PRs or Issues worthwhile to be involved into discussion. I hope we can put this under control such as @subscribe_dev as a bot to spread the information to dev@. Thanks, Qing On 7/17/18, 9:26 AM, "Lin Yuan" wrote: +1, I thin

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Lin Yuan
+1, I think they are very relevant to dev and as Aaron said we can always set up personalized filter. On Tue, Jul 17, 2018 at 9:21 AM Aaron Markham wrote: > +1, I don't read your emails anyways. Just kidding. I think it would be > good to see the action, even if I eventually have to setup filter

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Sheng Zha
Hi Anirudh, 1. You need exactly one filter to filter out all the github notifications on PRs and issues: "from:notificati...@github.com", and you'd get your S/N ratio back. 2. Having the option to do design discussion on an issue or PR is actually a good thing as many discussions are quite small a

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Aaron Markham
+1, I don't read your emails anyways. Just kidding. I think it would be good to see the action, even if I eventually have to setup filters if it gets overwhelming. On Tue, Jul 17, 2018 at 9:15 AM, Tianqi Chen wrote: > +1, most of issue and PR activities are about development, and they belong > t

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Tianqi Chen
+1, most of issue and PR activities are about development, and they belong to dev. It also helps us to recognizes contributors who are actively contributing but less vocal via emails -- there are many of them. Tianqi On Tue, Jul 17, 2018 at 8:47 AM, Anirudh wrote: > -1 > > The low signal to noi

Re: [VOTE] Subscribe dev@ to Github Activities

2018-07-17 Thread Anirudh
-1 The low signal to noise ratio would mean that we may miss important emails. Even with the different filters that we may setup for dev@, the emails would be too many to not miss the important ones. We would see more and more people starting a design discussion on an issue or PR. Because of the l

Re: [VOTE] Release MXNet version 1.2.1.RC1

2018-07-17 Thread Jim Jagielski
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