Re: A New API for creating .rec files

This makes a lot of sense to me Anirudh. On Tue, Sep 25, 2018 at 11:38 AM Anirudh Acharya wrote: > Hi, > > During some recent MXNet user surveys, one of the user requests was to have > a im2rec API that will have similar functionality as the im2rec tool( >

Re: Some feedback from MXNet Zhihu topic

Thanks for the detailed feedback Foivos. Just want to dig into the C++ comment. Any more details you could give on how we could improve the readability. Would modernizing the codebase and trying to provide consistent code style help? In regards to documentation was it that it's mostly lacking,

Re: clang-tidy and static code analysis

-awaiting-review -Kellen On Mon, Aug 27, 2018 at 10:02 AM kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Great suggestion Philip, and thanks for the reference. I've run a few > sanitizers locally but didn't see any output that concerned me. Absolutely > on my todo l

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

e get aware of any problems. > > > > The next step will be integration of Python CPU unit tests. There will > be a > > separate email if we got an update on that manner. > > > > Special thanks to Kellen Sunderland for the contribution of this Travis > CI > > pipel

GitHub having issues today

FYI GitHub is having issues today. It's severe enough that it's blocking my ability to validate PRs. I'm sure it will be resolved soon, but it might be a good day to read a few papers ;-). https://status.github.com/messages -Kellen

Re: [VOTE] Release MXNet version 1.3.0.RC0

Tracked down the issue referred to above and it's not a bug. I'll update the ticket. Changing to +1. On Mon, Sep 10, 2018 at 3:00 PM kellen sunderland < kellen.sunderl...@gmail.com> wrote: > -0.1 > > There's one test failure I've run into (details below). Following Indhu's

Re: [VOTE] Release MXNet version 1.3.0.RC0

-0.1 There's one test failure I've run into (details below). Following Indhu's logic I don't think this should block the release as it's not relating to a release feature introduced in this version. I'm trying to use the cpp-package examples as reference code for how to run MXNet models from a

PyPi Usage

Hello MXNet devs, Recently a PyPi maintainer raised a concern about the space used by MXNet releases. Stats for PyPi storage usage can be found here: https://pypi.org/stats/ I'm wondering if we can decrease that usage somehow? Are there a bunch of nightly builds posted there that aren't

Re: Publish MXNet images to DockerHub

folder? Would merging a basic replacement folder like this make sense as a placeholder? https://github.com/KellenSunderland/incubator-mxnet/tree/tensorrt_runtime_docker/docker -Kellen On Thu, Jul 26, 2018 at 4:36 PM kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Awesome. Than

Re: [RESULT][VOTE] Release MXNet version 1.3.0

Hey Roshani, did we only get two votes from committers? Apache releases require a minimum quorum of three approving ipmc members. https://www.apache.org/foundation/voting.html "Votes on whether a package is ready to be released use majority approval -- i.e. at least three PMC members must vote

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

problems exhibits on mac are similar > > Tianqi > On Wed, Sep 5, 2018 at 9:04 AM kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > > > @Tianqi: Yeah there's going to be a lot of trade-offs to using Travis. I > > hope we can get it running fast enough with

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

scratch and that was pretty slow > > > > Tianqi > > > > > > On Wed, Sep 5, 2018 at 8:49 AM kellen sunderland < > > kellen.sunderl...@gmail.com> wrote: > > > > > Great you feel that way Lin, please feel free to contribute if you have > >

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

MXNet converter) > > Best Regards, > > Lin > > On Wed, Sep 5, 2018, 3:02 AM kellen sunderland < > kellen.sunderl...@gmail.com> > wrote: > > > I'm bumping this thread as we've recently had our first serious bug on > > MacOS that would have been caught by

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

as something I'd like to re-enable again as soon as possible. -Kellen On Tue, Jan 9, 2018 at 11:52 AM Marco de Abreu wrote: > Looks good! +1 > > On Tue, Jan 9, 2018 at 10:24 AM, kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > > > I think most were in favour of at

Re: Propose to discontinue supporting Apache MXNet on Windows 7

hat your > competitors > >>> still support? Given MXNet's market share, I wouldn't dream of > dropping a > >>> platform until after the more popular frameworks have already done so. > >>> > >>> I also believe that it is possible to install mor

Re: Propose to discontinue supporting Apache MXNet on Windows 7

t; > a release in advance. > > Steffen > > > > On Thu, Aug 30, 2018 at 12:21 PM Sheng Zha wrote: > > > > > Hi Kellen, > > > > > > Thanks for the explanation. Unfortunately, I don't have the usage data, > > so > > > I refrained from voting

Re: Propose to discontinue supporting Apache MXNet on Windows 7

; > > On Wed, Aug 29, 2018 at 9:14 AM Srivastava, Rohit Kumar < > > > > srivastava@buckeyemail.osu.edu> wrote: > > > > > > > > > +1 > > > > > > > > > > On 8/29/18, 8:39 AM, "sandeep krishnamurthy" < >

Re: Propose to discontinue supporting Apache MXNet on Windows 7

+1 (non-binding) On Wed, Aug 29, 2018, 1:18 AM Anirudh Acharya wrote: > +1 for discontinuing. > > On Tue, Aug 28, 2018 at 4:11 PM Naveen Swamy wrote: > > > +1 to stop supporting Win7 > > > > On Tue, Aug 28, 2018 at 3:54 PM Lin Yuan wrote: > > > > > Dear Community, > > > > > > > > > > > >

Re: clang-tidy and static code analysis

om/dmlc/xgboost/pull/3525 > > > > Hyunsu Cho. > > > > On Sat, Aug 25, 2018, 11:47 AM Hagay Lupesko wrote: > > > > > I really like this proposal. > > > It will help improve the quality of MXNet native code, and maintain a > > > uni

Dockerhub outage had a temporary affect on CI

Hey all, If you noticed an issue using the CI yesterday it seems it was caused by a short-term, planned Docker Hub outage: https://status.docker.com/pages/history/533c6539221ae15e3f31 If you re-trigger your builds today they should go through properly. -Kellen

clang-tidy and static code analysis

Hello all, Inspired by Vanadana, cclaus and the project members who setup the very solid linting tools already in place for MXNet, I'm propose we enable clang-tidy-6.0 in our CI (PR here: https://github.com/apache/incubator-mxnet/pull/12282). clang-tidy is getting to be quite a high-quality,

Re: Release plan - MXNET 1.3

>> Can you please give me more details on the instance type and > >> > >> script you > >> > >> >> ran exactly so that I can try to reproduce it again? > >> > >> >> > >> &

Re: Testing examples in nightly build

I think it would be very beneficial to start fleshing out the nighties. They provide a lot of value at a relatively small cost. Any contributions from the community would be appreciated. Things I could see being beneficial: * Long running tests * In depth flake8/pylint linters * cudamemcheck

Re: Requesting slack access

Welcome to MXNet Per. We're looking forward to having you on the project (and the team). On Tue, Aug 14, 2018 at 11:46 AM Marco de Abreu wrote: > Great, welcome to MXNet! > > Per da Silva schrieb am Di., 14. Aug. 2018, 08:29: > > > Hi Steffen, > > > > Thank you for the warm welcome ^^ > >

Re: Release plan - MXNET 1.3

> On Fri, Aug 10, 2018 at 5:39 AM kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > > > All merged and ready to go from my side Roshani (the TensorRT PR). > > > > I agree with Sina that issue 12116 looks it's a blocker. I'll try and > > reproduce it l

Re: Release plan - MXNET 1.3

sue is a release blocker: > https://github.com/apache/incubator-mxnet/issues/12116 - Sina > > > On 8/8/18, 12:40 PM, "Roshani Nagmote" wrote: > > Thanks, Kellen for letting me know. > > On Wed, Aug 8, 2018 at 12:09 PM kellen sunderland < > kellen.sunderl...

Re: Release plan - MXNET 1.3

know if those needs to be > > >> included. > > >>>>> https://github.com/apache/incubator-mxnet/pull/11636 > > >>>>> https://github.com/apache/incubator-mxnet/pull/11562 > > >>>>> > > >>>>> I al

Re: Release plan - MXNET 1.3

> > > > > > > > Thanks, > > > > > Roshani > > > > > > > > > > > > > > > On Thu, Jul 26, 2018 at 1:34 PM Pedro Larroy < > > > > pedro.larroy.li...@gmail.com> > > > > > wrote:

Re: Release blocker: non-determinstic forward in gluon

I'd agree that we should have a repeatable process for generating artifacts. It would be useful for Apache release reviewers to be able to double check the results we get in CI, and it would help give a consistent experience for users. I'm a little uncomfortable with the idea of generating the

Re: Publish MXNet images to DockerHub

ation > > instructions page only python has docker image installation instruction > > here - > > > > > http://mxnet.incubator.apache.org/install/index.html?platform=Linux=Python=CPU > > Similar instructions need to be there for other bindings too. > > > > O

Re: Publish MXNet images to DockerHub

run services( as Kellen said). > > > On Sun, Jul 22, 2018 at 11:20 AM kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > > > I think it's a good idea Anirudh. It should help users easily get MXNet > up > > and running whether they're running services, follow

Re: Release plan - MXNET 1.3

; > > > 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 Roshan

Re: Publish MXNet images to DockerHub

I think it's a good idea Anirudh. It should help users easily get MXNet up and running whether they're running services, following tutorials, etc. On Sun, Jul 22, 2018 at 8:10 AM Naveen Swamy wrote: > I don't think we need for JVM languages, they have a good dependency > management through

Re: Release plan - MXNET 1.3

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

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

I'd agree with Sheng and Pedro. I would also not put a warning message in place when the function is explicitly called with SSL verification turned off. I would assume if the code author intentionally disables verification that the message being displayed would not provide value. -Kellen On

Re: [LAZY VOTE] Test coverage of PRs

gt; As stated previously, we're going to start with Python and C++ > coverage, > > >> evaluate it over the following days/weeks and then discuss how we > should > > >> move forward. I'm happy to take contributions from the community to > > extend > > >> the

Re: [LAZY VOTE] Test coverage of PRs

-0.1 (non-binding). Looks good, and I like the idea of adding coverage, however I have a few minor issues with this approach: First it seems to use a hosted service, which can disappear / be acquired / change terms at any time. In general I would try and avoid using services like this for

Parallel Inference Proposal

Hello MXNet developers, I’ve recently been speaking with users who’d like to run parallel inference requests with MXNet on their service. They’ll do this on GPUs, and due to resource constraints, they’d like to do this without duplicating their model’s weights in memory. They’d also like run

Re: New Java Inference API

Hey Andrew, thanks for the write-up. I think having a Java binding will be very useful for enterprise users. Doc looks good but two things I'm curious about: How are you planning to handle thread safe inference? It'll be great if you can hide the complexity of dealing with dispatch threading

Re: Fermi Architecture Support (pre-Kepler)

I doubt practically speaking that many pre-Keplar devices would be that useful for MXNet anyway. +1 to dropping them and making our codebase more readable / maintainable. On Tue, Apr 3, 2018 at 12:23 AM, Marco de Abreu < marco.g.ab...@googlemail.com> wrote: > Definitely in favour of dropping

Re: CI Python 3 GPU

Debugging this a bit with Chris. I haven't looked at it closely but it seems like there might be a genuine hang here between CuDNNConvolutionOp::SelectAlgo and a customop lambda invoke. What do you guys think? Stack is here:

Re: [VOTE] Change Scala namespace from dmlc to org.apache

:56 PM, Barber, Christopher < christopher.bar...@analog.com> wrote: > That sounds like a lot of work and it would be easy to get wrong if it is > even feasible. > > On 3/13/18, 11:51 AM, "kellen sunderland" <kellen.sunderl...@gmail.com> > wrote: > >

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

different from either Gluon version > or Scala API version. What a nightmare. > " > > 2018-03-12 16:10 GMT-07:00 kellen sunderland <kellen.sunderl...@gmail.com > >: > > @Rahul + Roshani, I would hear what you're saying if the user had to > worry > > abou

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

@Rahul + Roshani, I would hear what you're saying if the user had to worry about using the native package, but that worry is abstracted from them. The scala package has a dependency on the native library and includes the native lib inside the jar. The correct lib is then bound against at runtime.

Re: Publishing Scala Package/namespace change

ead to maintain. >> >> @Chris, I think we can have two separate votes. >> >> >> 2018-03-11 9:19 GMT-07:00 Chris Olivier <cjolivie...@gmail.com>: >> >> > Ok, so why don’t we have two votes? >> > >> > 1) change namespace is a separate vote si

Re: Publishing Scala Package/namespace change

ules (can be vetoed) > > > > 2) whether to disconnect non-C-API versioning from C-API versioning and > > have parallel versioning of all non-C APIs (process rule, so majority, I > > think is the rule, right?) > > > > -Chris > > > > On Sun, Mar 11, 2018 at 8:

Re: Publishing Scala Package/namespace change

n 'calculate(float)'. > > > > Regarding 'In this case the Scala interface is clearly a separate > > entity from the C API.'. Everything can be seen as a separate entity, > > the mxnet engine, the graph description, operators, python API, gluon > > API, etc. We shoul

RE: Publishing Scala Package/namespace change

+1 (non-binding) to what Marco is describing. +1 (non-binding) to getting the Scala bindings with the namespace change into Maven. The general best practice for SemVer, which is used by most projects that employ SemVer, is to apply SemVer to the public APIs of packages that ship with your

Re: Following semantic versioning

past and so far, it seems possible for Unix > > builds, although it’s going to be messy since the compile would > > generally > > need access to all a large portion of the headers in the source tree, > > since > > the “things needed t

Re: Following semantic versioning

Could we actually just define a mechanism so the libs could register their ops at runtime? No linking required? On Tue, Mar 6, 2018, 8:36 PM Pedro Larroy wrote: > This is a good point. What additional blockers would there be for linking > against a user provided

Re: move entirely to CMakefiles for building MXNet, drop Makefiles

Short term solution sounds good to me Chris. Converting the CI should be pretty easy. One thing we should keep in mind is that there's going to be a bunch of doc's we'll have to update. Warning, slight thread hijack ahead: As a more long term change I was wondering if we had considered using

Re: Meetup in Seattle

+1 to an Apache Meetup in public at that time. It would be great to meet more community members in person. On Thu, Mar 1, 2018, 6:45 AM Isabel Drost-Fromm wrote: > There's also a couple Apache ppl not involved with mxnet and not > subscribed here. Want to invite them as

Re: JIRA notifications on dev@

+1 On Feb 7, 2018 2:49 AM, "Marco de Abreu" wrote: > Lol, at least Link this thread please to show that the community actually > wants this. > > -Marco > > Am 06.02.2018 5:29 nachm. schrieb "Chris Olivier" : > > > I opened a ticket anyway.

[jira] [Commented] (MXNET-7) NDArray cython refactoring

[ https://issues.apache.org/jira/browse/MXNET-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353611#comment-16353611 ] Kellen Sunderland commented on MXNET-7: --- Hey Chris, is the idea here to speed up some nd array

Re: Unit tests removed

Hey Mu + Da, sorry to hear that. I've been working on the CPP tests PR and iterating on it for quite a while. I can assure you getting it merged had nothing to do with this revert from my perceptive. It's actually a task assigned to me for Q1 internally at Amazon. I'm actually completely

Re: [VOTE] Release Apache MXNet (incubating) version 1.1.0.RC0

Thanks to Haibin for putting this release together, and to everyone who has been working on technical debt (bug fixes, flaky test fixes) or RAT issues. I also appreciate the thinking around API changes, and the decision to deprecate rather than make a change in a single release. This release

Re: Release plan - MXNET 1.0.1

and contributor time each PR on something that we ultimately ignore doesn't seem productive. On Thu, Jan 25, 2018 at 4:29 PM, kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Yes this is also what I'd suggest Nan, sorry if I wasn't clear. My > comment was referring to 2. So a

Re: Release plan - MXNET 1.0.1

a new 1.1 branch for the > coming release, if it is necessary to have a maintenance version, we would > cherry-pick the important and backward-compatible fixes to 1.0.x branch > (though ideally this should be done when merging fixes to master ) > > Best, > > Nan > > >

Re: Release plan - MXNET 1.0.1

ectancy that no API changes were introduced, while it > may actually has happened. > > As long as we got no mechanism in place to validate the preconditions to > make this a patch release, we shouldn't act like we guarantee it. > > -Marco > > Am 25.01.2018 2:01 vorm. schrieb

Re: [Discussion] Branch Usage and Release Versioning

+1 (non-binding) to points 1-5. For point 3 I would suggest we come up with a heuristic for support status. For example we announce each release that we are dropping support for all prior releases that A) have less than 5% pip usage and B) are 3 minor releases old or older. On Tue, Jan 23, 2018

Re: Release plan - MXNET 1.0.1

-.5 (non-binding) to releasing as a minor release. If we don't have any breaking API changes, and we haven't added any major features I would tend to release this as a patch release. The reason being that organizations and users will know that they can apply this release without making major

Re: Proposal for treating warnings as errors in Linux & Clang builds (-Werror)

@Christopher: I see your point, but the counter argument would be: "Why should the project run fairly expensive tests (~20 minutes on few GPU instances) for code that will require you to amend your commit anyway?" In normal circumstances I'd completely agree with you and let the full tests run

Re: R Build failure

Lin <hai...@apache.org> wrote: > +1 for using free datasets or datasets without license issues and host > them on s3 buckets to reduce external dependencies. > > On 2018-01-06 15:26, kellen sunderland <kellen.sunderl...@gmail.com> > wrote: > > FYI PRs are currently

Re: CI failure due to offline llvm.org

Doing a few searches I see that llvm.org doesn't appear to be stable enough for CI. I'm going to write something to hopefully make it a little more stable today, while still allowing those at home to have easily reproducible build steps through docker. What I'd propose is

Re: Switch PR validation to PR-merge

+1 On Wed, Jan 10, 2018 at 6:51 PM, Gautam wrote: > +1 > > On Jan 10, 2018 1:25 AM, "Marco de Abreu" > wrote: > > > Hello, > > > > TLDR: We wish to change how PRs are validated, turning off PR-head which > > tests PRs in their current branch,

Re: [DISCUSS] Seeding and determinism on multi-gpu systems.

his would be > > an easy solution that wouldn't change any behaviour in training on > > multi-gpu. > > > > On Tue, Jan 9, 2018 at 10:48 AM, kellen sunderland > > <kellen.sunderl...@gmail.com> wrote: > > > Thanks Asmus, yes this is also the approach I wo

Re: [DISCUSS] Seeding and determinism on multi-gpu systems.

m> Folgendes geschrieben: > > Is it explicitly defined somewhere that random number generators should > always return a deterministic set of numbers given the same seed, or is > that just a side-effect of some hardware not having a better way to > generate random numbers so they use a

[DISCUSS] Seeding and determinism on multi-gpu systems.

Hello MXNet devs, I wanted to see what people thought about the follow section of code, which I think has some subtle pros/cons: https://github.com/apache/incubator-mxnet/blob/d2a856a3a2abb4e72edc301b8b821f0b75f30722/src/resource.cc#L188 Tobi (tdomhan) from sockeye pointed it out to me after he

Re: Increase indentation limit from 100 to 120 characters

#L963 On Sat, Jan 6, 2018 at 12:00 PM, kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Just a note that I don't think Pedro was suggesting the change for Python > or Scala. How would folks feel about changing the limit for just C++? > > On Sat, Jan 6, 2018 at 6:21 AM

R Build failure

FYI PRs are currently failing to build. The R "Matrix Factorization" test is failing to download this dataset: http://files.grouplens.org/datasets/ movielens/ml-100k.zip . The site https://grouplens.org/ appears to be down. Issue here: https://github.com/apache/incubator-mxnet/issues/9332 PR to

Re: CUDA Support [DISCUSS]

only with latest CUDA9 version and NOT CUDA8. > > I am eager to hear alternate viewpoints/corrections from folks other than > Kellen and me. > > Bhavin Thaker. > > On Sat, Jan 6, 2018 at 8:24 AM kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > &g

Re: CUDA Support [DISCUSS]

respective latest > cuDNN version in the MXNet CI since CUDA9 is backward compatible with > earlier Nvidia hardware generations. > > I would like to hear reasons why this would not work. > > I have commented on the github issue as well: > https://github.com/apache/incubator-mx

Re: Commiter access to Jenkins Sevrer

his way, they > can be used in conjunction with unit tests to reproduce a test failure, but > this still needs some discussions and a security review. > > -Marco > > Am 06.01.2018 12:59 nachm. schrieb "kellen sunderland" < > kellen.sunderl...@gmail.com>: > >

Re: Commiter access to Jenkins Sevrer

$(nproc)`. Are there CI tasks (other than Windows) that don't work for people? If so maybe we can help fix those? On Sat, Jan 6, 2018 at 11:50 AM, kellen sunderland < kellen.sunderl...@gmail.com> wrote: > +1, thanks for the work Marco. > > On Sat, Jan 6, 2018 at 12:24 AM, Nave

Re: Increase indentation limit from 100 to 120 characters

Just a note that I don't think Pedro was suggesting the change for Python or Scala. How would folks feel about changing the limit for just C++? On Sat, Jan 6, 2018 at 6:21 AM, Tianqi Chen wrote: > An argument against such change would be the coding style standard is >

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

te: > > I am on vacation starting Thursday. > > On Tue, Dec 12, 2017 at 9:49 AM kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > > > Absolutely, let's do an investigation and see if it's possible to > > virtualize. Would you have time to

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

One suggestion might be to have a presence at more open source conferences. We could also try to form partnerships with more organizations that traditionally contribute back to open source. On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier wrote: > I suggest more

RE: Apache MXNet Development Processes: Proposed update

Sheng’s comments are correct. GitHub will save review comments for ‘outdated’ commits, and they’re surfaced in the interface. I frequently amend then force push (i.e. change history) to address comments in order to keep my commits tidy. It’s always possible to expand a previous version

Re: Apache MXNet Development Processes: Proposed update

+1 (non-binding) to all points. On Dec 18, 2017 11:37 AM, "Pedro Larroy" wrote: > +1 to all mentioned points above > > What about changes that refactor code to make it more readable & > maintainable? My point of view is that this is important to keep the > quality

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

PM, Chris Olivier <cjolivie...@gmail.com> wrote: > googling seems to be full of running OSX (and even open-sourced PureDarwin) > in VMs. One could conceivably run a VM on an EC2 instance, right? > > On Tue, Dec 12, 2017 at 9:01 AM kellen sunderland < > kellen.sunderl...@gmail.c

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

..@gmail.com> > > > wrote: > > > > > > > +1 for #1 and #2 > > > > > > > > I’m working on getting a MacPro to add to CI system. > > > > On Tue, Dec 12, 2017 at 1:43 AM kellen sunderland < > > > > kellen.

[DISCUSS] Build OSX builds in CI (possibly with TravisCI).

Background: TravisCI is a startup providing managed continuous integration services with GitHub integration and YAML based configuration. TravisCI is one of the few CI providers that will build a variety of OSX/MacOS builds for software projects. Their pricing ranges from Free (for open

RE: [VOTE RESULT] Disable Appveyor

Thanks for the votes all. As a summary we have: Binding: Chris Olivier +1 Indhu Bharathi +1 Non-Binding: Kellen Sunderland +1 Marco de Abreu +1 Pedro Larroy +1 Asmus Hertzel +1 Daniel Bay +1 Looks like the vote has passed, and I believe Sheng has already opened a ticket to remove Appveyor

Re: [VOTE] Disable Appveyor

CI. On Dec 7, 2017 11:41 PM, "Indhu" <indhubhara...@gmail.com> wrote: > +1 > > My build is waiting in queue for 13 hours now. > > > On Thu, Dec 7, 2017, 11:26 AM kellen sunderland < > kellen.sunderl...@gmail.com> > wrote: > > > Background

[VOTE] Disable Appveyor

Background: Appveyor is a free-to-use (for opensource) CI system that specializes in providing support for Windows environments. Appveyor is currently running a very simple windows build for MXNet. Specifically we are generating build files via cmake, and then building with Visual Studio 14

Re: Futex

I think Haitao is right given some stacks we've recently looked at. e.g. https://gist.github.com/KellenSunderland/893d11165e19d1efcf5c0fe8e8584600 -Kellen On Thu, Nov 23, 2017 at 7:32 PM, Haitao Wang wrote: > Hi, Chris, > > As far as I know, the mutex implementation in

Re: Protected master needs to be turned off

-0.5 (non-binding). I would propose that if there are pieces of CI that are slowing down development (and I think we can all agree that there are) that we should strip out these problematic CI pieces and open issues for them. We can then assign issues to people and evaluate what should be done

Re: [VOTE] A Separate CI System for Apache MXNet (incubating)

@Sandeep, while I've had good experiences with CodeBuild, I'm not sure if it would address the needs of this project due to lack of instance type options. For example I don't believe they support GPU instances, which are required for a large portion of our build/test process. I'd propose we use

Re: [VOTE] A Separate CI System for Apache MXNet (incubating)

+1 for 1 (non-binding) On Fri, Nov 10, 2017 at 6:37 AM, Chris Olivier wrote: > +1 for 1) — Jenkins > > > On Thu, Nov 9, 2017 at 9:14 PM Naveen Swamy wrote: > > > +1 on 1) > > > > > On Nov 9, 2017, at 8:59 PM, Steffen Rochel >

Re: [DISCUSSION] Adding labels to PRs

I have a weak preference for option #2, as this option really helps make releases easy, and encourages a well thought-through commit process. However a combo of #1 and #3 would also work well, and is less overhead. Note: probably obvious, but whichever mechanism we choose, let's remember to

Re: Running tests in parallel

st never 100% GPU for > tests > > On Mon, Nov 6, 2017 at 6:43 AM kellen sunderland < > kellen.sunderl...@gmail.com> wrote: > > > Hey all, > > > > Just wanted to ask before I dive too deeply on this. Does anyone know why > > tests fail when run in multi

Re: [Proposal] Stabilizing Apache MXNet CI build system

intensive. On Wed, Nov 1, 2017 at 6:40 PM, kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Bhavin: I would add on point 5 that it doesn't alway make sense to attach > ownership for the broken integration test to the PR author. We're planning > extensive integration tes

RE: Improving and rationalizing unit tests

I think you’ve covered the pros/cons of having determinism in your tests. It seems like a potential maintenance effort versus forced code robustness argument to me. I’d suggest you have a separate vote on this topic. For me the main topic that should be focused on is making the CI system fast

Re: CI problems

I've had a similar problem with a PR. Same problem with Caffe on the last build, but I've had a wide variety of problems before this. https://github.com/apache/incubator-mxnet/pull/8125 https://builds.apache.org/blue/organizations/jenkins/incubator-mxnet/detail/PR-8125/12/pipeline On Sun, Oct

RE: Release plan - Apache MXNet (incubating) 0.12.0

Hi Meghna, the Sockeye team and I would love it if we could get this PR merged before the cutoff: https://github.com/apache/incubator-mxnet/pull/8125 It should have a large impact when training MT with MXNet. CI seems to be having issues today. I rebased this morning at ~8am Berlin time, and

Re: who know what version cmake in our windwos ci?

Just to clarify Shiwen, are you proposing to use CMake 3.9 on our CI, or to set the minimum CMake requirements for MXNet users to 3.9? To give us some more context could you provide a link to a document describing what the problem is, or give us the error that will result from using the wrong

RE: Apache MXNet build failures are mostly valid - verify beforemerge

Looking at the email thread it means marking the master branch as protected in GitHub (a functionality they offer): https://help.github.com/articles/about-protected-branches/ Popular open source projects should at a minimum have force push disabled on their master branch to prevent broken

Re: What's everyone working on?

Pedro and I are focusing on a few use cases involving mobile and IoT device development. At the moment we're trying to run machine translation and object detection models on a Jetson TX2 with reasonable performance. We'll probably also look at a few different types of model compression at some

<    1   2