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
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.
>
>
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.
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
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
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
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
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:
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
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
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
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
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,
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
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
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
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
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
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
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
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.
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
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
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
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
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
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)
-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
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
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
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.
-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
32 matches
Mail list logo