Re: Squash/Merge PRs

-1 We should stick with always using squash. It maintains PR reference in commit history. It is also common practice. If you want to included commits from multiple contributors in a single PR, open a branch and make PRs to that branch. Then only use rebase when merging that branch to master.

Re: users@mxnet

Neither TF nor Pytorch uses mailing lists though. In fact I can't think of any deep learning community that uses mailing lists. Mailing list is an obsolete legacy for old projects. No point in bringing it into new projects. Thanks, Eric On 2018/06/18 18:42:12, Sebastian wrote: > I am puzzled

Re: Reverting pull request

g the situation. > > The CCache/EFS failure lasted for 12 hours and was an error - these things > happen when you run a service. This is not a blame-game. > > -Marco > > [1]: > https://github.com/apache/incubator-mxnet/issues?q=is%3Aopen+is%3Aissue+label%3AFlaky > > On Fri, Jun 1

Re: Reverting pull request

Hi Marco de Abreu, CI has been totally broken recently. It randomly fails for no good reason more often than it passes. For example the ccache/efs failure has been really annoying. Looks like there has been many changes to Jenkins and Docker lately. Do you think we should revert all of the

Re: Vote to stop using JIRA

also one of them is > > > working on > > > > the Memory allocation issue in Scala not as a part of their day > > job; > > > This > > > > is where I find value in managing the project features on JIRA, > >

Vote to stop using JIRA

Hi, Since all of MXNet's development happens on Github, I think it's sufficient to use Github Issues and Github Projects for tracking. There are also many other plugins you can add to Github if issues and projects are not enough. It's very easy to cross reference PRs and issues for tracking.

Re: MXNet C++ package improvements

I see several issues with the design. I've commented in the document but for record here: 1. cpp-package is almost only used for inference. since you are planning a rewrite that's almost certainly non-backward-compatible, we might as well create a new interface that's inference only. 2. The

Re: Request for comments - Keras-MXNet as submodule in MXNet

-1 If you make MXNet a submodule of keras, then you should PR that to keras. If you want something like mxnet.keras, then you should do a full rewrite that only keeps the keras interface. On 2018/03/23 05:49:07, sandeep krishnamurthy wrote: > Hello MXNet

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

We want as few dependencies as possible. CMake alone is enough trouble for our users. We don't want to burden them with other stuff. On 2018/03/06 17:21:15, kellen sunderland wrote: > Short term solution sounds good to me Chris. Converting the CI should be >

Re: Following semantic versioning

One potential problem is with libstdc++. Specifically with vectors. Our operator interface uses vectors, which breaks when core lib and extension are compiled with different compiler version On 2018/03/06 22:45:16, Chris Olivier wrote: > The static init of your module

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

-1 JIRA is ancient and arcane. This adds unnecessary overhead. On 2018/03/03 06:11:12, CodingCat wrote: > This vote passes with 6 +1 votes (6 bindings) and no 0 or -1 votes. > > Binding +1: > Chris Olivier > Indhu Bharathi > Suneel Marthi > Yuan Tang > Marco de Abreu >

Re: Protected master needs to be turned off

Since committers voted for +1. We consider this vote passed. Thanks, Eric On 2017-11-19 12:51, "Eric Xie"<j...@apache.org> wrote: > Hi all, > I'm starting this thread to vote on turning off protected master. The reasons > are: > > 1. Since we turned on protect

Re: 3rdparty packages as submodules

I'm fine with a 3rdparty folder. Not sure about apache legal. On 2017-11-17 10:25, Chris Olivier wrote: > All, > > I often find it desirable to have a method for 3rdparty packages to be > included (possibly optionally) in a 3rdparty directory. We do this with > 'cub'

Re: Protected master needs to be turned off

.com> > > wrote: > > > > > +1 > > > > > > > > > On Sun, Nov 19, 2017 at 12:52 PM Zha, Sheng <zhash...@amazon.com> wrote: > > > > > >> +1 > > >> > > >> Best regards, > > >> -sz > > >

Re: Disable 'required status check' for master

. > > > > > On Tue, Oct 31, 2017 at 1:17 PM, Eric Xie <j...@apache.org> wrote: > > > The number of pending PRs is growing very fast. At the current rate it > > will reach 200 before we can fix jenkins. > > > > Stability is not the only goal. Master

Re: Disable 'required status check' for master

The number of pending PRs is growing very fast. At the current rate it will reach 200 before we can fix jenkins. Stability is not the only goal. Master will be most stable if we don't push anything, but that's not what we want. Committers should be responsible for their commits. Good judgement