Re: [ANNOUNCEMENT] New Committer: Qing Lan

Thanks everyone! Looking forward to contribute more to the community! Thanks, Qing On 11/20/18, 6:31 PM, "Steffen Rochel" wrote: Congratulation Qing! On Tue, Nov 20, 2018 at 6:29 PM Hagay Lupesko wrote: > Congrats Qing! Awesome to see you become a committer! > >

CI impaired

Hello, I'd like to let you know that our CI was impaired and down for the last few hours. After getting the CI back up, I noticed that our auto scaling broke due to a silent update of Jenkins which broke our upscale-detection. Manual scaling is currently not possible and stopping the scaling

Re: [Anouncement] New Committer: Kellen Sunderland

Welcome Kellen ! Am Mi., 21. Nov. 2018, 03:28 hat Steffen Rochel geschrieben: > Congratulation Kellen, well deserved! > Steffen > > On Tue, Nov 20, 2018 at 4:02 PM Tianqi Chen wrote: > > > We are pleased to announce Kellen Sunderland as a new committer of Apache > > MXNet. Kellen has a

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

Thanks Patrick, lets target to get the PR's merged this week. Call for contributions from the community: Right now we have 10 PR awaiting merge and we have 61 open PR awaiting review.

Re: [ANNOUNCEMENT] New Committer: Qing Lan

Congratulation Qing! On Tue, Nov 20, 2018 at 6:29 PM Hagay Lupesko wrote: > Congrats Qing! Awesome to see you become a committer! > > On Tue, Nov 20, 2018 at 4:26 PM Marco de Abreu > wrote: > > > Great to have your on board, Qing! > > > > Am Mi., 21. Nov. 2018, 01:24 hat Naveen Swamy > >

Re: [Announcement] New committer: Thomas Delteil

Congratulation Thomas! On Tue, Nov 20, 2018 at 2:54 PM Thomas DELTEIL wrote: > Thanks Marco and PMC members, looking forward to the road ahead. > > All the best, > > Thomas Delteil > > Le mar. 20 nov. 2018 à 14:40, Marco de Abreu > a écrit : > > > The Project Management Committee (PMC) for

Re: [ANNOUNCEMENT] New Committer: Qing Lan

Congrats Qing! Awesome to see you become a committer! On Tue, Nov 20, 2018 at 4:26 PM Marco de Abreu wrote: > Great to have your on board, Qing! > > Am Mi., 21. Nov. 2018, 01:24 hat Naveen Swamy > geschrieben: > > > The Project Podling Management Committee (PPMC) for Apache MXNet has > >

Re: [ANNOUNCEMENT] New Committer: Qing Lan

Great to have your on board, Qing! Am Mi., 21. Nov. 2018, 01:24 hat Naveen Swamy geschrieben: > The Project Podling Management Committee (PPMC) for Apache MXNet has > invited Qing Lan based on his contribution to MXNet Scala to become a > committer and we are pleased to announce that he has

[ANNOUNCEMENT] New Committer: Qing Lan

The Project Podling Management Committee (PPMC) for Apache MXNet has invited Qing Lan based on his contribution to MXNet Scala to become a committer and we are pleased to announce that he has accepted. Qing, thanks a lot for your contribution and continued effort to support MXNet community.

[Anouncement] New Committer: Kellen Sunderland

We are pleased to announce Kellen Sunderland as a new committer of Apache MXNet. Kellen has a sustained effort to the project both in the discussion and code contributions. PRs https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+author%3AKellenSunderland+ reviews

soft relu gradient, is it correct?

I bumped into the definition of the softrelu gradient: https://github.com/apache/incubator-mxnet/blob/master/src/operator/mshadow_op.h#L170 Which is defined as 1- exp(-x) As we define the forward of the softrelu as the softplus function, shouldn't the gradient be the logistic function? Is my

Re: [Announcement] New committer: Thomas Delteil

Thanks Marco and PMC members, looking forward to the road ahead. All the best, Thomas Delteil Le mar. 20 nov. 2018 à 14:40, Marco de Abreu a écrit : > The Project Management Committee (PMC) for Apache MXNet (incubating) > has invited Thomas Delteil to become a committer and we are pleased >

[Announcement] New committer: Thomas Delteil

The Project Management Committee (PMC) for Apache MXNet (incubating) has invited Thomas Delteil to become a committer and we are pleased to announce that he has accepted. Thomas, thanks a lot for your helpful contributions and we are looking forward to working with you on further projects! Best

Re: Splitting Jenkins pipelines - stop changes to Jenkinsfiles!

I have just submitted my PR at https://github.com/apache/incubator-mxnet/pull/13344. Test jobs are available at http://jenkins.mxnet-ci-dev.amazon-ml.com/view/test-marco-mxnet/. As soon as I'm done with my tests, I will mark it as ready for review. Best regards, Marco On Tue, Nov 20, 2018 at

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

Re: Splitting Jenkins pipelines - stop changes to Jenkinsfiles!

Thanks, Pedro! I have also been looking into that issue, but it seems like this would require changes in the groovy interpreter of Jenkins. From what I can tell, a refactor will give us multiple benefits (clarity and speed) aside from resolving this issue. Best regards, Marco Am Di., 20. Nov.

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

Great - congrats! On Tue, Nov 20, 2018 at 8:51 AM Anton Chernov wrote: > Dear MXNet community, > > I'm happy to announce the results of the vote. > > This vote passes with 8 +1 votes (4 binding) and no 0 or -1 votes. > > +1 votes > > * Carin / binding > * Indhu / binding > * Sandeep / binding >

Re: MXNet - Gluon - Audio

Hi All! Following up on this PR: https://github.com/apache/incubator-mxnet/pull/13241 I would need some comments or feedback regarding the API design : https://cwiki.apache.org/confluence/display/MXNET/Gluon+-+Audio The comments on the PR were mostly around *librosa *and its performance being a

Re: Splitting Jenkins pipelines - stop changes to Jenkinsfiles!

I think this is a big problem, which has blocked us before. I want to point out that you are doing a great thing by avoiding everyone getting blocked by refactoring the pipelines. My concern is that we are kicking the can down the road and not addressing the root cause of the problem with is

Re: Splitting Jenkins pipelines - stop changes to Jenkinsfiles!

Hello Steffen, no, there won't be any impact on the PR process or nightly regressions. Only the reporting will have to be updated with the new job links, but that should be a minor issue. To avoid any outage, I have been thinking about running both versions in parallel. Best regards, Marco On

[RESULTS] [VOTE] Release Apache MXNet (incubating) version 1.3.1.rc0

Dear MXNet community, I'm happy to announce the results of the vote. This vote passes with 8 +1 votes (4 binding) and no 0 or -1 votes. +1 votes * Carin / binding * Indhu / binding * Sandeep / binding * Jim / binding * Kellen * Steffen * Roshani * Aaron 0 votes * No votes -1 votes * No votes

Re: Should PR-860 (Use modernized range loops where possible) be reverted?

Great. Thanks for the clarifications everyone. I think we are good then :) - Carin On Tue, Nov 20, 2018 at 10:43 AM kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Hey Carin, I don't think there's any issues merging this PR. The veto'd > aspect was around _requiring_ modern loop

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

Thank you everyone, the vote is closed. I will send the results in a separate announcement. Best Anton пн, 19 нояб. 2018 г. в 15:44, Jim Jagielski : > +1 from me (macOS) > > > On Nov 16, 2018, at 2:52 AM, kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > > > > Thanks for organizing

Splitting Jenkins pipelines - stop changes to Jenkinsfiles!

Hello, we ran into issues around the maximum filesize of the Jenkinsfile a few times already. In order to resolve this issue, I'd like to combine this with some refactors I have planned for quite some time. The idea is basically to move away from one big Jenkinsfile and instead split it into

Re: Should PR-860 (Use modernized range loops where possible) be reverted?

Hey Carin, I don't think there's any issues merging this PR. The veto'd aspect was around _requiring_ modern loop usage, and failing the build if clang tidy detected modern loops could be used but weren't. The original PR included a check for this and would fail any builds not using modern

Re: Should PR-860 (Use modernized range loops where possible) be reverted?

Hi Carin, The discussion [1] was about whether to enable automatic checks on using old behaviour in new PR's. Kellens PR [2] was about modernizing the actual code itself and was not up for voting, thus could not receive any technical veto votes. Per the discussion (as I have understood it), we

Re: Should PR-860 (Use modernized range loops where possible) be reverted?

Hi all I think we have to make the clear separation between the thread votes on "uniformly adopting C++11 range loops in the MXNet project" and a PR which refactored code to be more legible and with improved variable names. Merging that PR doesn't imply that we have to uniformly adopt the

Should PR-860 (Use modernized range loops where possible) be reverted?

My intent was to be helpful, but I think I may have merged this PR yesterday too soon thinking it was approved and ready to merge https://github.com/apache/incubator-mxnet/pull/12356 I didn't see the connected dev discussion