About Becoming a Committer

Hi, There have been a couple of offline inquiries from contributors about becoming a committer. From those inquiries, it seems that there’s confusion in our community about how to become a committer, so I’d like to take this opportunity to clarify. The guideline about becoming a committer can be

Re: [GitHub] szha closed pull request #11154: Revert "[MXNET-503] Website landing page for MMS (#11037)"

Thanks, Henri. I was reverting the commit on a PR that another committer didn't intend to merge but only realized afterwards. Given that it wasn't convenient for him to revert and the negative effect, I committed the revert and cc'd the original committer in the PR, both as notification and as a

Re: [VOTE] Release MXNet version 1.2.1.RC0 (Patch Release)

save_parameters didn't exist in 1.2.0 so its addition usually isn't supposed to happen in a patch release if we stick to semantic versioning. I couldn't find a discussion on this exception. Did it happen? Would people who used 1.2.0 to save models be able to load parameters in 1.2.1 using the

Re: [VOTE] Release MXNet version 1.2.1.RC0 (Patch Release)

.2.0. > It does not adhere exactly with semver but it had to be made, to quickly > help our customers who were using the APIs incorrectly. > > Anirudh > >> On Mon, Jun 25, 2018 at 5:42 PM, Sheng Zha wrote: >> >> save_parameters didn't exist in 1.2.0 so its additio

[Discussion] Branch Usage and Release Versioning

Dear community members, Now that we're preparing a new release under the 1.0 version, I'd like to propose that we discuss, clarify, and decide how we use versions and branches. Current practice is: 1. we use master branch for development. 2. we fork from master branch and create release branch

Re: Release plan - MXNET 1.0.1

Hi Haibin, Thanks for leading this. I suggest that we hold onto this release until we have clarity on the following items. 1. branch usage and versioning Given that we are past 1.0 and we're changing APIs, I'd like to suggest that we first agree on how versioning works in mxnet. If we follow

Re: Call for Help for Fixing Flaky Tests

for both points. Additionally, I'd propose to add the requirement to > > specify a reason if a new test takes more than X seconds (say 10) or adds > > an external dependency. > > > > Looking forward to getting these tests fixed :) > > > > Best regards, > >

Re: Call for Help for Fixing Flaky Tests

-- would that work? > > I like your suggestion of using this: https://pypi.python.org/pypi/flaky in > another email thread. May be we could have a higher rerun count as part of > the nightly test to have better test automation stability. > > Bhavin Thaker. > > On Sun, Jan 1

Re: [DISCUSSION] Adding labels to PRs

+1. Also, I think committers should act as role models in this regard, and ensure that our own code changes have sufficient details in the PR. Since I proposed the PR template, I also want to re-state that any suggestions to improving the PR template are welcome. By being open about it, we can

Call for Help for Fixing Flaky Tests

Hi MXNet community, Thanks to the efforts of several community members, we identified many flaky tests. These tests are currently disabled to ensure the smooth execution of continuous integration (CI). As a result, we lost coverage on those features. They need fixing and to be re-enabled to

Re: [VOTE] When in Doubt, Wait 24 Hours Before Merging

eto must > be preserved (ie set review status as 'request changes') > > On Fri, Feb 2, 2018 at 6:18 AM, Isabel Drost-Fromm <isa...@apache.org> > wrote: > >> >> >> Am 2. Februar 2018 01:20:31 MEZ schrieb Sheng Zha <zhash...@apache.org>: >> >Specif

Coordinating Breaking API Changes for 2.0

Hi, Now that we accepted semantic versioning as the practice going forward, and that we have been more mindful on API changes, I observed the needs for coordinating breaking API changes. Thus, I created the following issue for collecting desired API-breaking changes:

[VOTE] When in Doubt, Wait 24 Hours Before Merging

Hi, In order to avoid having miscommunication and unaligned expectation, I'd like to propose a lazy vote on a new rule for merging pull requests. Specifically, for merging PRs, if there are open review comments and changes afterwards didn’t address the comments, we should have a grace-period of

Re: [DISCUSS] improve MXNet Scala release process

/display/MXNET/ > MXNet-Scala+Release+Process > > > Hope that answers > > > On Fri, Jul 27, 2018 at 4:59 PM, Sheng Zha wrote: > > > Qing, > > > > For 1, why would it be a blocker, given that there were previous > releases? > > Has there been compatibi

Re: [DISCUSS] improve MXNet Scala release process

Qing, For 1, why would it be a blocker, given that there were previous releases? Has there been compatibility issues for scala packages? If so, why did we release? There are many maven packages that include binary already, so if we can find the binary for all dependency it's probably best to link

Re: Release blocker: non-determinstic forward in gluon

Dear users and developers of Apache MXNet (Incubating), Thanks to Tong's dedication, the root cause for this issue was identified to be instability in OpenBLAS's latest stable version 0.3.1. For details, see Tong's comment

Re: Release blocker: non-determinstic forward in gluon

Since OpenBLAS 0.3.2 could also have performance improvement, therefore I > propose to wait for OpenBLAS 0.3.2 for our pip post release. > > > Best regards, > > Tong He > > 2018-07-27 10:54 GMT-07:00 Sheng Zha : > > > Forgot to mention, the post release version is a pip pack

Re: Release blocker: non-determinstic forward in gluon

t causing the problem. > Sheng - what is 1.2.1.post0? Shouldn't a patch with fix be released as > 1.2.2? > Steffen > >> On Thu, Jul 26, 2018 at 5:33 PM Sheng Zha wrote: >> >> Dear users and developers of Apache MXNet (Incubating), >> >> Thanks

Re: Release blocker: non-determinstic forward in gluon

Forgot to mention, the post release version is a pip package version. -sz > On Jul 27, 2018, at 10:42 AM, Sheng Zha wrote: > > In this case we can regard it as a release problem, which is usually what > post release versions are for. It’s still the same release with different

Re: Growing number of open PRs and Labelling PRs

Hi Sandeep, Sorry if I asked an obvious question, but is it required to introduce a new solution that require committer access? We have an existing solution to communicate the PR status, which is through the PR template checklist. The PR checklist provides clickable options to reflect the PR

Re: There is a bug in shape inference of the where operator

Correct me if I'm wrong. The bug went into the release branch so we need to cherry-pick the fix once the patch is merged to master. -sz On Thu, Aug 23, 2018 at 4:14 PM Lin Yuan wrote: > Hi Da, > > I am currently running the unit test and will check in the fix once it's > complete. > > Thanks,

Re: [VOTE] Subscribe dev@ to Github Activities

issue. > > Anirudh > > On Mon, Jul 16, 2018 at 4:35 AM, Timur Shenkao wrote: > > > +1 if my vote can be taken into account > > > > On Mon, Jul 16, 2018 at 4:32 AM, Sheng Zha wrote: > > > > > Hi, > > > > > > I'm starting a v

Re: [VOTE] Subscribe dev@ to Github Activities

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

Re: [VOTE] Subscribe dev@ to Github Activities

___ > From: Junru Shao > Sent: Tuesday, July 17, 2018 10:58:33 AM > To: d...@mxnet.apache.org > Subject: Re: [VOTE] Subscribe dev@ to Github Activities > > +1 > > Both GitHub activities and dev list are places for development. It will be > great if we

Re: [VOTE] Subscribe dev@ to Github Activities

ils, 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@mxn

Re: [VOTE] Subscribe dev@ to Github Activities

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

Re: [VOTE] Subscribe dev@ to Github Activities

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

Re: [VOTE] Subscribe dev@ to Github Activities

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

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

e I said, I would rather call it MXNet Office hours and categorize > the > > > kind of support that is offered, we might be able to find contributors > > > willing to do this in different parts of the world regardless of their > > day > > > job or not. > > >

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

that is the case - developers would convert corresponding > office > hours issue into normal GitHub issue. > - > > We request SMEs to help in following up by the issues. > - At the end of the office hours conversation, developer who helped >the user would su

[RESULT][VOTE] Subscribe dev@ to Github Activities

Hi, The vote concluded at 9PM today (2018/07/18), and here are the results: +1 Timur Shenkao Aaron Markham Lin Yuan Anirudh Acharya Junru Shao Yizhi Liu (committer) Zhi Zhang (committer) Tianqi Chen (committer) Sheng Zha (committer) -1 Qing Lan Rahul Huilgol K, S Anirudh (committer) Chris

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

I'm guessing Mu's intention is to make it clear that such invitation is extended by teams in Amazon/AWS instead of by committers, so as to avoid the confusion of the naming "MXNet SDK". Suggestions to achieve the same goal are welcome. Best regards, -sz On Thu, Jul 19, 2018 at 9:09 AM, Isabel

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

Net comitter in our office hours (Marco de Abreu @marcoabreu), > others are contributors such as Anton (@lebeg) or others. I think we could > refocus the conversation to the point that the office hours might have some > emphasis in a particular area of MXNet. > > On Thu, Jul 19, 2018 at

[VOTE] Subscribe dev@ to Github Activities

Hi, I'm starting a vote on subscribing dev@ to Github activities. See previous discussion thread here . The vote lasts for three days and ends on 7/18/2018 at 9pm pst. -sz

Re: [DISCUSS] Subscribe dev@ to Github Activities?

t; wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > On Thu, Jul 12, 2018 at 12:26 PM Anirudh Acharya < > > > > anirudhk...@gmail.com> > > > > > > wrote: > > > > > > >

Re: Propose to discontinue supporting Apache MXNet on Windows 7

> You have peaked my curiousity though Sheng. How many win7 users does MXNet > have relative to macos/Linux? > > On Thu, Aug 30, 2018, 8:51 AM Sheng Zha wrote: > > > Hi Yuan, > > > > No problem. This is an issue that's worth having a clear definition, so

CI Issue in Julia PR #10149

Hi, This is regarding https://github.com/apache/incubator-mxnet/pull/10149. The author ran into an mxnet CI issue, and has tried to reach out to the people who donated the CI system on the PR but didn't get a response. As a result, the progress on porting the Julia binding is halted for three

Re: Nightly Builds Not Working for Cu90MKL?

Hi Alfredo, Looks like the recent increase in binary size is causing timeouts when publishing. I'm looking into it. In the meantime, please build from the source until it's resolved. Sorry for the inconvenience. -sz On 2018/08/31 21:29:05, Alfredo Luque wrote: > See here: >

Re: [VOTE] Release MXNet version 1.3.0.RC0

dditional reasoning > besides > > "X mentions the issue" or "fix was done by X"" > > I have. Repeating what I wrote in my previous email for clarity: Basic > > functionality broken: loading a model (albeit one that that was saved as > > non FP3

Re: [VOTE] Release MXNet version 1.3.0.RC0

Hi Hagay and Sandeep, Could you help us understand why this specific bug is more important than all the other known bugs, that this becomes a release blocker? Some facts to consider: - The bug exists since SymbolBlock was introduced a year ago and has survived at least three releases, so this is

Re: Propose to discontinue supporting Apache MXNet on Windows 7

Are any of the votes based on any measure of user impact, if we indeed decide not to fix the current problems? -sz On Wed, Aug 29, 2018 at 1:29 PM Hagay Lupesko wrote: > +1 (non-binding) > Thanks for raising this Lin! > Are you suggesting to do it as part of MXNet 1.3? > > On Wed, Aug 29, 2018

Re: Propose to discontinue supporting Apache MXNet on Windows 7

> > Lin > > > > On Wed, Aug 29, 2018 at 1:37 PM Sheng Zha wrote: > > > Are any of the votes based on any measure of user impact, if we indeed > > decide not to fix the current problems? > > > > -sz > > > > On Wed, Aug 29, 2018 at 1:29 PM Hag

Allow SSL Verification to be off in mx.gluon.utils.download?

Hi, This is a follow-up discussion from PR-11546 per suggestion from Marco. The proposed approach is to add an option to allow users who call the download function to explicitly turn off ssl verification. The

[DISCUSS] Subscribe dev@ to Github Activities?

Hi all, Should we subscribe dev list to github updates on mxnet repo? Both github issues/PRs and the dev list are intended for technical discussions and in that aspect largely share the same goal. Since MXNet has most activity github, this could help dev@ to become more active. Some pros and

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

ard and github inserts extended label info above it sometimes. > > Just an idea. > >> On Thu, Mar 8, 2018 at 9:13 AM, Sheng Zha <szha@gmail.com> wrote: >> >> The PR template is designed for that and its poor adoption is causing the >> same issue of missing informa

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

The PR template is designed for that and its poor adoption is causing the same issue of missing information in PRs. My concern of using JIRA is that more overhead would deter contribution and worsen the quality of description. -sz > On Mar 8, 2018, at 8:49 AM, Nan Zhu

Security Risk in requests<2.20 (CVE-2018-18074)

See https://github.com/apache/incubator-mxnet/issues/13032

Re: [Announce] Upcoming Apache MXNet (incubating) 1.3.1 patch release

Similar to the two PRs that Haibin suggested, 12992 introduces new interface for controlling determinism, which is better suited for minor release. I think other than lack of release manager to drive 1.4.0 release, there’s no reason we cannot do two releases (1.4.0 & 1.3.1) at the same time.

Re: [RESULT][LAZY VOTE] Next MXNet release

ork alone is > a headline feature that users would love to get their hands on. > > On Tue, Nov 6, 2018 at 11:32 PM Sheng Zha wrote: > > > I'd like to propose that we expedite the 1.4.0 release slightly as there > > doesn't seem to be a rule that prevents a minor release fr

Re: MKLDNN dynamically linked

+1. Ideally, MKLDNN can be statically linked. mxnet-mkl relies on Make for building it so help is wanted on mxnet. -sz On 2018/11/08 21:28:50, Alex Zai wrote: > Currently in mxnet-mkl the libmxnet.so is dynamically linked to to > libmkldnn.so.0. This is known to cause some issues if the wrong

Re: [Question] Difference between "Feature" and "Feature request" labels in Github

Oh, I see. I was moving the other 80 or so, so it was probably a race-condition. Anyway, thanks for being eager to help. -sz On Tue, Nov 13, 2018 at 5:24 PM Naveen Swamy wrote: > done now, removed the feature label, there were 4 issues with that label > but also had Feature Request. > > On

Re: [Question] Difference between "Feature" and "Feature request" labels in Github

I was in the middle of transferring all items labeled with "Feature" to the "Feature request" label when "Feature" label was deleted. I'm not sure who deleted the "Feature" label but it's gone now. -sz On Tue, Nov 13, 2018 at 5:05 PM Anirudh Acharya wrote: > This issue was raised before here -

Re: [RESULT][LAZY VOTE] Next MXNet release

I'd like to propose that we expedite the 1.4.0 release slightly as there doesn't seem to be a rule that prevents a minor release from happening at the same time of a patch release. This would shorten the time it takes for new features to reach users. Proposed revision to the timeline: - Code

Re: [VOTE] Release MXNet version 1.3.0.RC0

Hi Steffen and Zhi, That's because those are not the artifacts being voted on. I just uploaded the actual release artifact to [1]. Unfortunately, even the lengthy release process doc [2] didn't capture this step... Steffen, In case you don't already know, regarding the version string, since

[ANNOUNCE] Apache MXNet (incubating) 1.3.0 Release

andeep Krishnamurthy, Sebastian Bodenstein, Sergey Kolychev, Sergey Sokolov, Sheng Zha, Shen Zhu, Sheng-Ying, Shuai Zheng, slitsey, Simon, Sina Afrooze, Soji Adeshina, solin319, Soonhwan-Kwon, starimpact, Steffen Rochel, Taliesin Beynon, Tao Lv, Thom Lane, Thomas Delteil, Tianqi Chen, Todd Sundsted, T

Re: [ANNOUNCE] Apache MXNet (incubating) 1.3.0 Release

nk you announcement made it through: > https://lists.apache.org/list.html?annou...@apache.org:lte=1M:mxnet > > [image: Screen Shot 2018-09-19 at 12.05.14 PM.png] > > On Mon, Sep 17, 2018 at 3:51 PM Sheng Zha wrote: > >> Hello all, >> >> The Apache MXNet (incuba

Re: reject

To approve: > > announce-accept-1537392657.65969.akeecpnfdegkalmpn...@apache.org > > To reject: > > announce-reject-1537392657.65969.akeecpnfdegkalmpn...@apache.org > > To give a reason to reject: > > %%% Start comment > > %%% End comment > > &

Re: Design proposal - MXNet end to end models - Models with data transformations

Hi Sandeep, Thanks for taking the initiative and sharing the proposal. It's great to see the image operators being extended. To summarize, the design for the first phase provides two alternatives: - D1: Use the existing approach of expressing data transformation pipeline as hybrid block, and

Taxonomy on our cwiki

Hi MXNet, Given that currently cwiki is the only place other than mxnet website for mxnet-related documentation, I'd like to request your attention to the (slightly disorganized) cwiki page of MXNet. The top level folders (and their contents) currently looks like this: - Design Proposals* (bag of

Re: [DISCUSS] Make MKLDNN as a default on Maven nightly build

+1 if the licensing aspect is ok. Since MKLDNN (open source apache 2 license) depends on MKLML (binary only) which carries its own license (see below for the full text), we need to check if it's ok to include this license in our binary distribution. Full text of the MKLML license: Copyright (c)

Re: MXNET-1294: Priority-based parameter propagation for improved data parallel training throughput

Hi Anand, Thanks for sharing the work and for offering to improve mxnet and ps-lite. If you don't need to test the integration, you can - fork dmlc/ps-lite - make the changes - send a pull request back to the repo, just as you would to mxnet If you need to test the integration in mxnet first,

Re: MXNet - Gluon - Audio

Hi Gaurav, The performance concerns is not just around librosa, but also the way to integrate it. librosa as a python library requires holding GIL when calling it, which makes it hard for asynchronous data preprocessing during training. Also, the API design hasn't been verified on the more

[Anouncement] New Committer: Tao Lv

We are pleased to announce Tao Lv as a new committer of Apache MXNet. Tao's sustained contribution to the project has been greatly helping the CPU performance of MXNet. Please join me to welcome Tao to the team! -sz

Re: Taxonomy on our cwiki

gt; > > > +1, Good idea. > > > > > > It's not very easy to find out the related contents since lots of > > folders in the website. > > > > > > > > > > -Original Message- > > > > From: She

Re: Podling Report Reminder - April 2019

Thanks for the reminder. I’m working on it and will post the draft back to the list, and would appreciate feedback from the community by then. -sz > On Apr 2, 2019, at 5:23 PM, Tianqi Chen wrote: > > It would be great if the PPMC coordinate and prepare the report > >> On Tue, Apr 2, 2019 at

Re: Discussing plans for next MXNet releases

Hi Hagay, Thanks for taking the initiative. The proposed scope in this thread is in my opinion too large to fit in a single thread, so I'd suggest that we start separate threads for each individual release item. To elaborate on the reasons based on each individual item: - For 1.4.1 which is in

[Discussion] 1.5.0 roadmap

Hi all, In order to coordinate efforts for the next 1.5.0 minor release, let's join the discussion here: https://github.com/apache/incubator-mxnet/issues/14619 Once we have some clarity on the items to track for 1.5.0 release from the discussion, we will come back to the list and propose a

Re: MXNet 1.4.1 Release Proposal

Thanks Hagay for proposing the release and for Junru to volunteer to drive the release. I will help Junru as the committer for this release. -sz On Thu, Apr 4, 2019 at 2:18 PM Junru Shao wrote: > Hi Hagay, > > I have some experiences in MXNet development, and would love to volunteer > for

Re: assimilation of mshadow into the MXNet codebase

I agree it would make development easier to donate mshadow to mxnet code base, since mshadow is only used in MXNet. I support donating the mshadow code to mxnet and I started an RFC for this in mshadow [1]. [1] https://github.com/dmlc/mshadow/issues/373 -sz On 2019/04/06 04:38:19, Tianqi Chen

Re: assimilation of mshadow into the MXNet codebase

mshadow depends on *a* BLAS library, and there's nothing inherent in mshadow code base that requires OpenBLAS over MKL. The linked issue #11769 seems to be more of a build logic issue. -sz On 2019/04/07 18:56:43, Aaron Markham wrote: > +1 > Reduced complexity. Choice of math library...

Re: Rust Client Lib

Hi, Thanks for sharing the results. A problem in the benchmark is that the comparison does not take into account that MXNet is making a copy while pytorch is not. MXNet made the choice of not doing a zero-copy for numpy arrays, but instead making a copy of the numpy data. This means that

[Announcement] New Committer - Kan Wu (@wkcn)

Hi, Please join me in welcoming Kan Wu (@wkcn), as a new committer! Kan has brought many valuable contributions to MXNet [1]. He also enriches the MXNet ecosystem with his operator toolkit MobulaOP. We are excited to have Kan join us as a committer. -sz [1]

Re: CI woes pt.2

CI has been down again for several days now. Is there something I can help with? -sz On 2019/02/27 14:35:05, Per da Silva wrote: > Hi everyone, > > The PR temporarily disabling windows tests has been merged, so the windows > checks shouldn't block progress for the time being. Please retrigger

Re: [Design Review Request] Extending model save/load API

pe for binding. This > information if part of the model, could have simplified model training to > model deployment path much easier and decoupled. > > Best, > Sandeep > > On Thu, Feb 21, 2019 at 2:10 PM Sheng Zha wrote: > > > Hi Sandeep, > > > > In the design

Re: [DISCUSS] Process to remove deprecated operators

MXNet follows semantic versioning so we will be able to delete them in the next major release. -sz On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan wrote: > Dear Community, > > In MXNet there are many legacy operators such as this > < >

Re: [Design Review Request] Extending model save/load API

Hi Sandeep, In the design doc, you stated that > Input/Output signature are not part of the model: Saved model missing the information about the input/output descriptions, like name/shape, making the saved model unusable out of the box. Could you elaborate why you think this is the case? -sz

Re: Call for Ideas and Approaches to Community Building

First, I echo a lot with Steffen’s points on educating users on the usage of MXNet and DL, and my team at my day job takes it as its mission. Just to name a few related efforts: d2l.ai (a whole book on deep learning with mxnet), the numerous tutorials in GluonCV, GluonNLP, DGL toolkits, the

Re: libjpegturbo

MXNet pip statically links with libturbojpeg that's built from source, not from debian package. The script for linux and mac can be found here: https://github.com/apache/incubator-mxnet/blob/master/tools/dependencies/libturbojpeg.sh#L22 -sz On 2019/02/12 07:46:30, Per da Silva wrote: > Hello

Re: [RESTARTING][VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

Thanks for the detailed explanation and the help on educating the community, Michael. People on the general list are spending time to help us get the licensing right. If possible, I think we should be thankful by treating their feedbacks more seriously, making the efforts to quickly fix the

Re: [RESTARTING][VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

Update: All license issues mentioned in the general vote from Luciano (pom files, docker files, docs) have been fixed on master [1][2]. Let me know if there's more to address. -sz [1] https://github.com/apache/incubator-mxnet/pull/14138 [2] https://github.com/apache/incubator-mxnet/pull/14142

Re: [RESTARTING][VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

nks for being so proactive, but adding license headers to > the markdown files in #14142 breaks the website as I warned. I caught > it before it went live. > I've disabled website publishing until this situation is resolved. > > > On Wed, Feb 13, 2019 at 10:59 AM Sheng Zha wrote

Re: [RESULTS][VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

Update on the issue 1. and 4.: For 1., I fixed the notice year in master branch [1]. If we are to create a new rc, the fix should be cherry-picked. For 4., MKLDNN has found the issue [2] and posted the fix in their master branch. I'm requesting that the fix be backported for the minor version

Re: RE: Third-party package tests for MXNet nightly builds

Thanks for the proposal, Felix. On one hand, I agree that richer workload from the ecosystem helps find issues in MXNet early. On the other hand, I'm concerned about tightly coupling the development of projects. Monitoring the upstream library and addressing problems for upgrading dependency

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc3

-[Y] Are release files in correct location? -[Y] Do release files have the word incubating in their name? -[Y] Are the digital signature and hashes correct? -[Y] Does DISCLAIMER file exist? -[Y] Do LICENSE and NOTICE files exists? -[Y] Is the LICENSE and NOTICE text correct? -[N] Is the NOTICE

Re: [Announce] Runtime feature detection

Hi Pedro, Happy to help, though I was waiting for PR comments to be addressed. Currently the PR is close to complete, with some open comments to be resolved. -sz > On Jan 25, 2019, at 9:27 AM, Pedro Larroy > wrote: > > That's Great! There's a PR that we should merge first which >

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

I found an awesome checklist for incubator releases [1] so I'm using it here: -[Y] Are release files in correct location? -[Y] Do release files have the word incubating in their name? -[Y] Are the digital signature and hashes correct? -[Y] Does DISCLAIMER file exist? -[Y] Do LICENSE and NOTICE

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc2

s. > > > > > As of today, Friday Feb 1st 2019 6pm PST we have two binding votes, > > one > > > > +1 > > > > > (Carin), one +0 (Sheng). The vote continues be open waiting for > > > feedback > > > > > from PMC members. > > >

Re: [RESULTS] [VOTE] Release Apache MXNet (incubating) version 1.4.1.rc0

on’t believe it would have been a blocker. > > Hen > > On Sat, May 4, 2019 at 00:00 Junru Shao wrote: > > > Dear MXNet community, > > > > I'm happy to announce the results of the vote. > > > > This vote passes with 12 +1 votes (3 binding), no 0 vot

Re: CUDA recommendation

10.1 is recommended. The oldest CUDA version that we release is 8.0. -sz On 2019/05/24 23:29:38, Marco de Abreu wrote: > While we are at the topic, did we actually agree on dropping support for > some versions? So far we are releasing all the way been to cuda 7.5 I think > > -Marco > >

Re: Making new operators and AMP lists

feature, we also added AMP to the established methods including the coding > constraints and other checks that come with it. Lets be open and welcome to > this new feature and come back if the turnaround time is actually too high. > > -Marco > > > On Wed, May 29, 2019 at 1

Re: Making new operators and AMP lists

Thanks for initiating the discussion. The premise for adding the test was to make sure that AMP feature is "not broken", but that's IMO not the right view. AMP is not supposed to support a new operator it hasn't seen before in the first place. There's no way for it to know whether the fp32

Re: Making new operators and AMP lists

t; > To sum it up: I think this test is good and it should be kept as error, but > it should be moved to sanity checks. > > -Marco > > On Wed, May 29, 2019 at 12:21 AM Sheng Zha wrote: > > > Thanks for initiating the discussion. > > > > The premise for addin

Re: Making new operators and AMP lists

added operators that can benefit from > > FP16 computing into the appropriate lists, instead of shifting the burden > > away to many other developers at the moment. > > > > On Tue, May 28, 2019 at 4:13 PM Sheng Zha wrote: > > > > > The support for AMP should not be a bu

Re: Making new operators and AMP lists

> > -Marco > > On Wed, May 29, 2019 at 1:42 AM Sheng Zha wrote: > > > AMP is in contrib so there's no guarantee that the API is final. Adopting > > the test as-is is harmful because operator authors should not be required > > to invest in an experimental feature

Re: Making new operators and AMP lists

; optimizer and AMP inserts a FP32 cast before its input, the > > > > > optimizer would actually update the FP32 copy of the tensor > > > > > instead of the tensor itself. This is not a performance problem > > > > > (which, I agree, wo

cwiki permissions change

Hi, Recently I came across the permission setting page where it was slightly chaotic. Namely, some non-committers were given admin access while some committers don't have delete rights. The permission rights were also not given consistently across contributors. I made the following changes: -

Re: Making new operators and AMP lists

> The second misunderstanding is that the ask from the test is to somehow "add > support" for AMP in the operator. That is definitely not true and adding a > single line in either FP32_FUNCS (cast me always to FP32) or FP16_FP32_FUNCS > (do not do anything with me because I'm not relevant for

Re: [VOTE] Remove conflicting OpenMP from CMake builds

This vote is invalid as the original PR has been vetoed by a committer. A vote on dev@ won't help you circumvent a veto. -sz On 2019/06/14 23:59:33, Pedro Larroy wrote: > Hi all > > This is a 5-day vote to act and wrap up an outstanding PR that removes > linkage with multiple OpenMP from

Re: [VOTE] Release Apache MXNet (incubating) version 1.5.0.rc0

This vote has been closed. We will make another tag and start vote again. -sz > On Jun 18, 2019, at 5:24 PM, Lin Yuan wrote: > > With the PR https://github.com/apache/incubator-mxnet/pull/15213 I could > verify that building Horovod is successful with MXNet built from source. So > I will

Re: [VOTE] Remove conflicting OpenMP from CMake builds

g this PR then? all the questions have been > answered, performance numbers provided and more. Until how long can a > veto stand? Also without replies to contributors. > > Pedro. > > On Fri, Jun 14, 2019 at 5:44 PM Sheng Zha wrote: > > > > This vote is invalid as the ori

  1   2   3   >