Re: assimilation of mshadow into the MXNet codebase

[Tianqi Chen]

As long as we have CLA covering for the majority of the code(which I
believe so), I think we should be good.
Just like the case of Apache only requires iCLA from committers.

The rationale is that normal contributions are already in the form of ALv2,
in the case of a(unlikely) dispute, the community can quickly rewrite the
code(since that is non-majority).

TQ

On Sun, Jul 26, 2020 at 5:49 PM Sheng Zha  wrote:

> Hi Justin,
>
> Thanks, that's a good point. I think we have already received CCLA from
> Intel. I will take that into account when providing the next update.
>
> Regards,
> Sheng
>
> On Sun, Jul 26, 2020 at 5:39 PM Justin Mclean 
> wrote:
>
> > Hi,
> >
> > > Several peoples in below list are from Intel and I have added them into
> > CC.
> >
> > Has Intel signed a CCLA? And if so does it list people who are allowed to
> > contribute to this project? Are there any others on that list who
> > employer’s may need to also sign CCLAs if we don’t have them?
> >
> > Thanks,
> > Justin
>

Re: [DISCUSS] Deprecating and Forbidding Terraform and Other Services by HashiCorp in MXNet

[Tianqi Chen]

I am just trying to send a note about the principle, not trying to give any
opinions about X should do Y.

See also the explaination in the annotated version
https://opensource.org/osd-annotated

Given that particular part of the code is not linked/distribute by the
Apache project, we might be fine.
I think it is important to not having an opinion here and use the principle
to enable maximum collaboration as in the osd principal.

The challenge here is not really about we think, but what the community
members thinks and our willingness to find a resolution. Again I am not
suggesting any action here, but just to reflect on the principle

TQ


On Sun, May 31, 2020 at 11:28 AM Marco de Abreu 
wrote:

> Tianqi, I think that statement can go in both directions. The Chinese
> government is actively restricting companies from operating if they do not
> cooperate with the government and weaken their security. Thus, I would not
> consider HashiCorp to be actively discriminating here.
>
> From that point on it's political and since the policy does not apply to
> us, I think it's better to close the discussion here.
>
> -Marco
>
> Tianqi Chen  schrieb am So., 31. Mai 2020,
> 19:38:
>
> > https://opensource.org/docs/osd
> > > 5. No Discrimination Against Persons or Groups
> >
> > It would be useful to focus on ^ principles, and focus on building better
> > software together.
> >
> > TQ
> >
> > On Sun, May 31, 2020 at 9:33 AM Sheng Zha  wrote:
> >
> > > Hi Marco,
> > >
> > > At the time I started the thread, the specific term related to China
> > reads
> > > as follows:
> > >
> > > PLEASE NOTE THAT THE SOFWARE MAY NOT BE USED, DEPLOYED, OR INSTALLED IN
> > > THE PEOPLE'S REPUBLIC OF CHINA. [1]
> > >
> > > My concern with the above clause is that it starts the practice of
> > > HashiCorp targeting a group of the community resides in a specific
> > region.
> > > I'm worried that they could change terms of use at any moment that
> could
> > > render the normal usage illegal and our community members liable.
> > >
> > > The situation has changed as HashiCorp indeed revised the specific
> clause
> > > to include only Vault enterprise version. From the reply I think you
> only
> > > read the updated version. Since the current version of their term of
> use
> > > doesn't affect our project anymore, I'm OK to leave it as is.
> > >
> > > -sz
> > >
> > > [1] https://pbs.twimg.com/media/EZLJJwjUYAM8Xk-?format=jpg=large
> > >
> > > On 2020/05/31 09:58:08, Marco de Abreu 
> wrote:
> > > > The statement is specifically about HashiCorp Vault enterprise
> edition
> > -
> > > > speak a single module of their enterprise suite which is about
> > credential
> > > > encryption.
> > > >
> > > > I didn't read further, but my first guess is that they are not
> offering
> > > it
> > > > in China since the Chinese government - as far as I can recall - is
> > > > restricting the usage of encryption methods to those, which they
> > consider
> > > > weak and exploitable.
> > > >
> > > > From that point on, it becomes more a political question. I
> personally
> > am
> > > > quite concerned about a government using their power to undermine
> > > security
> > > > of software.
> > > >
> > > > Since this statement is only about vault enterprise edition and we're
> > not
> > > > using vault at all, I'd leave it as is. Supporting such a horrible
> > > practice
> > > > by "boycotting" HashiCorp in general would send the wrong signals
> from
> > > an
> > > > open source communities point of view.
> > > >
> > > > -Marco
> > > >
> > > > Sheng Zha  schrieb am So., 31. Mai 2020, 05:08:
> > > >
> > > > > Dear community,
> > > > >
> > > > > Yesterday, HashiCorp added to their terms of evaluation the clause
> > that
> > > > > forbids usage of the enterprise version of any HashiCorp software
> in
> > > the
> > > > > People's Republic of China [1]. While this does not affect the
> usage
> > > of the
> > > > > community version, it does signal the potential legal risk to many
> of
> > > our
> > > > > community members in China. In light of this recent development,
> I'm
> > > > > initiating discussion on deprecating the usage o

Re: [DISCUSS] Deprecating and Forbidding Terraform and Other Services by HashiCorp in MXNet

[Tianqi Chen]

https://opensource.org/docs/osd
> 5. No Discrimination Against Persons or Groups

It would be useful to focus on ^ principles, and focus on building better
software together.

TQ

On Sun, May 31, 2020 at 9:33 AM Sheng Zha  wrote:

> Hi Marco,
>
> At the time I started the thread, the specific term related to China reads
> as follows:
>
> PLEASE NOTE THAT THE SOFWARE MAY NOT BE USED, DEPLOYED, OR INSTALLED IN
> THE PEOPLE'S REPUBLIC OF CHINA. [1]
>
> My concern with the above clause is that it starts the practice of
> HashiCorp targeting a group of the community resides in a specific region.
> I'm worried that they could change terms of use at any moment that could
> render the normal usage illegal and our community members liable.
>
> The situation has changed as HashiCorp indeed revised the specific clause
> to include only Vault enterprise version. From the reply I think you only
> read the updated version. Since the current version of their term of use
> doesn't affect our project anymore, I'm OK to leave it as is.
>
> -sz
>
> [1] https://pbs.twimg.com/media/EZLJJwjUYAM8Xk-?format=jpg=large
>
> On 2020/05/31 09:58:08, Marco de Abreu  wrote:
> > The statement is specifically about HashiCorp Vault enterprise edition -
> > speak a single module of their enterprise suite which is about credential
> > encryption.
> >
> > I didn't read further, but my first guess is that they are not offering
> it
> > in China since the Chinese government - as far as I can recall - is
> > restricting the usage of encryption methods to those, which they consider
> > weak and exploitable.
> >
> > From that point on, it becomes more a political question. I personally am
> > quite concerned about a government using their power to undermine
> security
> > of software.
> >
> > Since this statement is only about vault enterprise edition and we're not
> > using vault at all, I'd leave it as is. Supporting such a horrible
> practice
> > by "boycotting" HashiCorp in general would send the wrong signals  from
> an
> > open source communities point of view.
> >
> > -Marco
> >
> > Sheng Zha  schrieb am So., 31. Mai 2020, 05:08:
> >
> > > Dear community,
> > >
> > > Yesterday, HashiCorp added to their terms of evaluation the clause that
> > > forbids usage of the enterprise version of any HashiCorp software in
> the
> > > People's Republic of China [1]. While this does not affect the usage
> of the
> > > community version, it does signal the potential legal risk to many of
> our
> > > community members in China. In light of this recent development, I'm
> > > initiating discussion on deprecating the usage of HashiCorp software
> and
> > > services and forbidding their usage in MXNet infrastructure until
> situation
> > > changes.
> > >
> > > I believe that the community cannot be traded for the technological
> > > convenience. Currently, we have part of our CI and GitHub labeling
> robot
> > > bootstrapping logic that relies on Terraform, a service provided by
> > > HashiCorp [2]. Since all its usage that I found are for bootstrapping
> on
> > > AWS, replacing them with CloudFormation is feasible and likely
> > > straightforward.
> > >
> > > Your input is appreciated.
> > >
> > > Regards,
> > > Sheng
> > >
> > > [1] https://www.hashicorp.com/terms-of-evaluation
> > > [2]
> > >
> https://github.com/apache/incubator-mxnet-ci/search?q=terraform_q=terraform
> > >
> > >
> >
>

Re: Issue with releases / feedback from ASF board

[Tianqi Chen]

>
> I’m not aware of any other project that uses CUDU code.
>

I want to point out that most machine learning and analytics related
projects will likely need to involve (and likely distribute) CUDA code,
this would include some of the current TLPs.

Here are some examples using search:
- Arrow https://arrow.apache.org/docs/python/cuda.html
- SystemML https://systemml.apache.org/docs/1.2.0/gpu
- Singa
https://svn.apache.org/repos/infra/websites/production/singa/content/docs/gpu.html

TQ



>
> 1. https://mxnet.apache.org/get_started/?
> 2. https://github.com/apache/incubator-mxnet/releases
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Severe legal issues with releases on repository.apache.org

[Tianqi Chen]

Are we really sure fortran compiler is the issue ? For example, gcc was GPL
but has an exception for compiled-linked binaries using libc, so that the
result binary won't be affected by GPL.

TQ

On Tue, May 12, 2020 at 2:47 PM Lausen, Leonard 
wrote:

> On Tue, 2020-05-12 at 13:05 -0700, Zach Kimberg wrote:
> > I would also like to ask how we use libgfortran? Since it is category X,
> we
> > should not be depending on it for any of the core functionality in MXNet.
> > It can only have an "optional feature" (
> > https://www.apache.org/legal/resolved.html#optional) at most.
> Furthermore,
> > libgfortran seems to be under the full GPL (
> > https://github.com/gcc-mirror/gcc/blob/master/libgfortran/libgfortran.h)
> > instead of the LGPL, so I don't know if we are even allowed to even have
> it
> > as an optional dependency.
>
> OpenBLAS's LAPACK implementation relies on a Fortran compiler.
> https://github.com/xianyi/OpenBLAS#dependencies The binaries on
> repository.apache.org are of the MXNet OpenBLAS variant.
> gfortran is typically the default choice for Fortran compiler.
>
> Two options if we like to distribute official ASF convenience binaries:
>
> 1) We can build OpenBLAS without LAPACK, though the operators relying on
>
> https://github.com/apache/incubator-mxnet/blob/master/src/operator/c_lapack_api.h
> are unavailable in such build.
>
> 2) Investigate recent LLVM based Fortran compilers, though as far as I
> understand they are not yet production ready:
>
> https://www.phoronix.com/scan.php?page=news_item=LLVM-Lands-FLANG-F18-Finally
> Maybe there are other alternatives.
>
> Best regards
> Leonard
>

Re: Severe legal issues with releases on repository.apache.org

[Tianqi Chen]

I agree, In the meanwhile. @Leonard I think we should ask trademark@apache
whether they would approve the use of

repo names: mxnet-cu80 mxnet-cu10 etc, given that
- they are distributed by individual contributors(as individuals and not as
ASF PPMC members),
- marked as thirdparty binary
- Build from the original ASF source with no modifications, while with an
"optional build config" that enables CUDA acceleration support, which
abides the rules in https://www.apache.org/foundation/marks/downstream.html

TQ

On Sun, May 10, 2020 at 8:06 AM Markus Weimer  wrote:

> On Sat, May 9, 2020 at 10:50 PM Tianqi Chen 
> wrote:
> >
> > Seems the conclusion so far is only release source through apache and
> > release the binary builds as third party(as a different community, a
> > company or individual)
>
> Yes, that is the precedent established in multiple projects. I think
> it might still be worthwhile to pursue an exception from nvidia,
> though. Do we have any nvidia employees on the list that can inquire
> about that?
>
> Markus
>

Re: Severe legal issues with releases on repository.apache.org

[Tianqi Chen]

Seems the conclusion so far is only release source through apache and
release the binary builds as third party(as a different community, a
company or individual)

TQ

On Sat, May 9, 2020 at 7:39 PM Lausen, Leonard 
wrote:

> They actually statically link some libraries such as libcudnn. But even
> removing
> that won't necessarily help. Compiling with nvcc and including cuda headers
> during compilation incorporates parts of the Cuda SDK into libmxnet.so, and
> makes it per the formulation of Cuda EULA subject to certain
> ASF-incompatible
> limitations.
>
> For more background on licensing of binaries, you can check the FAQ of GCC
> [1]:
>
> > [...] if these libraries were simply distributed only under the terms of
> the
> > GPL, all the object code that GCC produces would have to be distributed
> under
> > the same terms. [...] Therefore, these libraries have always had license
> > exceptions that allow people to distribute the object code GCC produces
> under
> > any license.
>
> Maybe NVidia is willing to grant a similar exception, so that libmxnet.so
> can
> remain Apache Licensed even containing code compiled with nvcc, but
> currently
> there's no such exception.
>
> Best regards
> Leonard
>
> [1]: https://www.gnu.org/licenses/gcc-exception-3.1-faq.html
>
>
> On Fri, 2020-05-08 at 22:48 -0700, Chris Olivier wrote:
> > do the gpu builds actually include the nvidia cuda libraries such as
> > libcudart.so or just link to them and expect them to be on the machine?
> >
> >
> > On Fri, May 8, 2020 at 1:50 PM Lausen, Leonard  >
> > wrote:
> >
> > > Hi all,
> > >
> > > repository.apache.org is an official Apache Software Foundation
> release
> > > channel
> > > and the MXNet project has been publishing convenience binaries via that
> > > channel
> > > since quite a while. Unfortunately it appears that no-one has
> initiated a
> > > license review of these convenience binaries, and unfortunately they
> are
> > > incompatible with the ASF requirements. They should have never been
> > > uploaded.
> > >
> > > I recently reached out to Legal to inquire about this issue [1] and
> Legal
> > > team
> > > recommends to remedy the situation ASAP.
> > >
> > > Two issues, out of the potentially larger set of all issues.
> > >
> > > 1) There are GPU builds (mxnet-full_2.11-linux-x86_64-gpu)
> incorporating
> > > the
> > > CUDA SDK and possibly cuDNN, placing the resulting libmxnet.so under
> the
> > > CUDA
> > > EULA and cuDNN SLA. This EULA and SLA contain many restrictions, making
> > > them
> > > Category-X licenses [1]. No Apache project must under any circumstance
> > > redistribute such binaries.
> > >
> > > 2) All builds redistribute libgfortran.so, which is part of the GNU
> Fortran
> > > compiler, part of GCC and subject to the GPL. The GPL is also a
> Category-X
> > > license and the same restrictions apply.
> > >
> > > I see the following two potential remedies:
> > >
> > > 1) Ask the Infra team to delete all MXNet releases on
> > > repository.apache.org
> > >
> > > 2) Ask the Infra team to delete all MXNet GPU releases on
> > > repository.apache.org
> > > and provide replacement releases without libgfortran.so and other
> > > potentially
> > > Category-X files (I found libmkl_ml.so in one of the JARs..)
> > >
> > > If no-one steps up to do 2) or no-one suggests a better option, I
> > > recommend we
> > > go for option 1). Let's start discussing the options. Once discussion
> has
> > > settled, I'll initiate a lazy consensus or vote session.
> > >
> > > Note that these license rules apply to MXNet as part of the ASF.
> > > Third-parties
> > > (individuals or companies) may redistribute binary builds of MXNet
> > > incorporating
> > > Category-X licenses, IF they are appropriately labeled and no ASF
> > > trademarks or
> > > branding is infringed.
> > >
> > > As for the GPU builds, NVidia or Amazon may be willing to provide
> > > third-party
> > > GPU builds. I opened another ticket with Jira to see if such
> third-parties
> > > could
> > > provide them and what considerations would need to be taken into
> account.
> > > [3]
> > > This is similar to the Pypi releases, are third-party releases and not
> > > performed
> > > by the MXNet project (though also for them some legal questions remain
> > > open; in
> > > particular our Website does not disclaim that these are third-party
> > > releases).
> > >
> > > Best regards
> > > Leonard
> > >
> > > [1]: https://issues.apache.org/jira/browse/LEGAL-516
> > > [2]: https://www.apache.org/legal/resolved.html#category-x
> > > [3]: https://issues.apache.org/jira/browse/LEGAL-515
> > >
>

Re: Workflow proposal

[Tianqi Chen]

While the idea of staging seems to be reasonable.
Most OSS projects choose not to do so because having a complicated staging
will likely confuse the contributors, and increase the change of
divergence(between dev and master).

Given that we have a release model, so in some sense the release itself
serves as a staging pt.
A good approach would simply setup the nightly if necessary strive to fix
regressions and make sure the formal release addresses the issues.

TQ

On Wed, Mar 11, 2020 at 5:32 PM Pedro Larroy 
wrote:

> Hi
>
> I talk to some people about this and they thought it would be a good idea,
> so sharing it here:
>
> I would propose to use a staging or "dev" branch into which nightly &
> performance tests are done periodically and then this branch is merged to
> master. The goal of this workflow would be to avoid having regressions and
> nightly failures creeping into master. PRs would get merged into dev and
> dev promoted periodically / nightly into master.
>
> The names can be swapped as well, between dev and master, so PRS get merged
> into master and it doesn't change the workflow, and staging is the branch
> where nightly changes are merged to.
>
> Have this been considered?
>
> Pedro.
>

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Tianqi Chen]

Thanks @hzfan I would also high recommending taking a close look at the TVM's 
object protocol, and try to push most of the things through the Object 
eventually(Create temporary support for legacy cases like TShape is fine, but 
eventually pushing things as object will have a greater uniformity, and brings 
benefit such as putting everything into a container)

-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-578451034

Re: Stop redistributing source code of 3rdparty dependencies to avoid licensing issues

[Tianqi Chen]

I don't have an opinion, but would like to list pros and cons of doing so.

The pro of doing so is that it indeed simplifies the release process, as
these additional dependencies becomes category-B level dependencies as in
https://www.apache.org/legal/resolved.html

The con of doing so is that it brings additional burden to the users of the
software to check the license of these dependencies, in some sense,
including these information in the
license actually gives an extra level of transparency.

The copyright message in some of the dependencies are a bit unfortunate,
one potential way to run the check is to write a python script to go
through the files and detect the line Copyright and cross match and add
them.

Note that good models to follow are
- hadoop: https://github.com/apache/hadoop/tree/trunk/licenses
- flink: https://github.com/apache/flink

Each of the repo have a licenses folder that contains licenses, and things
points to them.

I am not a lawyer, but the case for ps-lite seems can be resolved as long
as we can confirm these files follows Apache-2.0, as
https://www.apache.org/licenses/LICENSE-2.0 only requires us to redistribute
the license and anything in the NOTICE, but we do not have the obligation
to list all the copyright messages in the source content.

TQ

On Fri, Jan 17, 2020 at 11:10 AM Yuan Tang  wrote:

> +1
>
> On Fri, Jan 17, 2020 at 1:59 PM Chris Olivier 
> wrote:
>
> > +1
> >
> > On Fri, Jan 17, 2020 at 10:19 AM Lausen, Leonard
>  > >
> > wrote:
> >
> > > Dear MXNet community,
> > >
> > > as per recent mail on gene...@incubator.apache.org [1] there are a
> > number
> > > of
> > > licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I believe
> > > there
> > > has been no release so far without any licensing issues, which is a
> > > blocker to
> > > MXNet graduating from it's incubating status. One contributing factor
> is
> > > that we
> > > bundle 3rdparty source code in our releases [2].
> > >
> > > One key factor is that 3rdparty projects don't always enforce licensing
> > > best
> > > practice in the way we do. For example, 3rdparty/ps-lite doesn't
> enforce
> > > license
> > > headers in the source files and there has been confusion about the
> > license
> > > of
> > > recent contributions by ByteDance (See [1]).
> > >
> > > To avoid such licensing issues in MXNet releases a simple solution is
> to
> > > stop
> > > distributing the 3rdparty code in our source releases. Instead, we can
> > > adapt our
> > > buildsystem to download 3rdparty code as part of the build
> configuration
> > > process. CMake makes this very easy with the FetchContent module [3].
> > >
> > > For development purpose involving changes to the 3rdparty source or
> build
> > > systems that can't access the internet, there are easy means for
> > > specifying the
> > > location of local sources (instead of downloading), via the
> > > FETCHCONTENT_SOURCE_DIR_ variable [4].
> > >
> > > Would there be any concerns about such approach? Obviously it can only
> be
> > > fully
> > > implemented as soon as the CMake build system is feature complete and
> the
> > > Makefile build can be dropped. (Note that the Makefile build is being
> > > deprecated
> > > and removed as part of MXNet 2 roadmap [5])
> > >
> > > Best regards
> > > Leonard
> > >
> > > [1]:
> > >
> > >
> >
> https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E
> > > [2]: See the .tar.gz files at
> > > https://incubator.apache.org/clutch/mxnet.html
> > > [3]: https://cmake.org/cmake/help/latest/module/FetchContent.html
> > > [4]: https://cmake.org/pipermail/cmake/2019-June/069709.html
> > > [5]: https://github.com/apache/incubator-mxnet/issues/16167
> > >
> >
>

Re: [DISCUSS] Enforce tighter control on API related changes

[Tianqi Chen]

I wonder if it is possible to just use the RFC mechanism for most API
change discussions.

Note that while API compatibility is important, having a clear RFC
mechanism would likely strike a balance between the need to evolve APIs
(e.g. 2.0) and stability of the project

TQ

On Mon, Jan 13, 2020 at 4:38 PM Lin Yuan  wrote:

> Dear Community,
>
> Recently, there were some changes to C APIs that broke another downstream
> project Horovod: https://github.com/apache/incubator-mxnet/issues/17292.
> Since we do not have integration tests for downstream project, it becomes
> critical for us to update APIs with extreme caution.
>
> I would like to propose the following mechanism for us to maintain a clean
> and robust APIs: including both C API and Python API at the moment.
>
> (1) Any PR involving change of APIs should be approved by at least one of
> the committers from a "API Committee" before it can be merged. I will
> explain how to form this committee at the end of email
>
> (2) Any PR that contains API change should clearly state this in PR title.
> Otherwise, committer can reject the PR
>
> API Committee:
> - This committee should consist of both seasoned MXNet developers and
> users.
> - Committee members should have a comprehensive view of MXNet APIs to make
> sure their usage are consistent across stack.
> - Committee members review PRs that involve API change with extra caution.
> - Committee members are required to attend the roadmap discussion for each
> new release.
> - For API breaking changes, committe members should reach consensus before
> the change is made.
>
> Any other suggestion is welcome here.
>
> Best,
>
> Lin
>

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Tianqi Chen]

re the need for explicit type checking code in TVM FFI. 

Actually there is no explicit code for type checking as they are generated 
automatically via template expansion(on the receiving end), also we also have a 
"strong typed" signature that wraps the packed function interface, which gives 
you compile time type checking 
https://github.com/apache/incubator-tvm/blob/master/include/tvm/runtime/packed_func.h#L191
 

For dynamic language side(python) the exposed function is still type erased(as 
python is a dynamic language). 

Note that the view dynamic vs static typed language does not really apply to 
this case, because the main goal(exposing to python) means type-erasure(as 
python is dynamically typed). The main goal would be how to reduce the number 
of abstraction layers.

> Also these microbenchmarks are nice, but we also need to consider the
> overhead in typical workloads and see if it's still significant.

If we apply reasoning, most API cost is going to be FFI cost + exec cost, and I 
think the conclusion so far is we want FFI cost to be around 1e-7s to 1e-6s, 
which is the limit of any cost .


-- 
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-569382845

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Tianqi Chen]

@larroy indeed every solution has trade-offs, and these tradeoffs are discussed 
in the above posts when we compare solutions, and they are backed by benchmarks 
:) it would be great if you can also suggest potential tradeoffs here.

When you expose an API from typed language(c++) to a dynamic language(python), 
you have to type erase it, given that the python functions don't have the type, 
and you have to pass the information along.  

The only difference is where you do the type checking(that the python type 
corresponds to the right c++ type), and translation(translating to the c++ 
type).

For example, in the case of pybind, the erasure is done implicitly when you 
call the python function, then checking and translation happens when you call 
into the c++ function.

In the case of creating a C API for each feature and wrap things in the python 
side, the type checking is done in the python side, and translation as well.

In the case of tvm ffi, the type translation is done in the python/cython side, 
 while the type checking is done in the c++. 

To dive deeper into the tradeoffs for PackedFunc calling convention. The 
convention erases the type by having the type code stored into the arguments. 
This brings additional cost of passing arguments into heap, as opposed to 
registers. So they might not be designed for inline functions that needs to 
happen at the order of 1e-9s, however, for API functions that needs to run 
around 1e-7 or even 1e-8 level, this convention is pretty good.

In terms of the calling cost, it really depends on whether the caller and 
callee are strongly typed.
- If caller is strongly typed, then assigning type code is O(1)
- If caller is a dynamic type(like python) then we need to have a dispatcher to 
dispatch and select the right type code
- If callee is strongly typed, then the cost of checking is O(1) by just check 
the code to be the correct one 
- If the callee is dynamic type, then a dispatching need to happen, which have 
another level of hashtable lookup O(1)

As we can see, the only place where dispatching is necessary is the dynamic 
type handling case. Even in these cases, if there is a strong need of 
specialization, we can directly force the type by running checking on the 
caller, and pass in the right type code (the engineering burden is the same as 
wrapping the C API). However, the benchmark suggests that the dynamic 
dispatching cost is reasonable, and satisfies the API speed.

Coming back to the tradeoff, the main tradeoff here is the engineering burden 
to keep an hourglass design(with fixed set of API) vs efficiency. While my post 
did not suggest that TVM's ffi is a silver bullet, it does works pretty well 
for our use cases. hope it helps


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-569139957

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Tianqi Chen]

@hzfan thanks for implementing a poc:) However, these is a subtle but important 
difference which worth discusses here :) I will use cython-ffi to refer to the 
above approach, and tvm-ffi to refer to tvm's approach

- In cython-ffi, both data structure and functions are exposed, this means a in 
order to grow the set of functions, we need to expand the set of C API. In 
another words, we need to grow the set of FFI API as we add more functions
- In the tvm-ffi, the set of C API is fixed, and only data structure 
constructions are exposed to the cython side, given that a set of supported 
data structures are also fixed. In this way, we do not have to grow the set of 
FFI API as we add functions.
- Another subtle point is that we are passing data structure across dll 
boundaries. In the case of cython-ffi, it could be a c++ container(Tuple). 
TVM's object structure is designed to be C ABI compatible, which allows us to 
construct in one dll and pass to another, however it is not necessarily true 
for all c++ classes. There is a potential danger when passing c++ container 
across DLL boundaries(when two dll has different allocator, calling push_back 
in another dll could cause error). 

The difference again boils down to the design point of what is a clear cut of 
FFI conventions. Ideally, it would be: a stable set of C API and container 
structures that does not change over time.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-568777082

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Tianqi Chen]

After some thoughts along the direction, I find a better and fun answer to the 
above question: support tuple/ellipsis/slice in tvm ffi effectively.

I quickly hacked up a POC in https://github.com/tqchen/tvm/tree/pyffi that 
supports the following benchmark script(disclaimer: it is only a POC so not 
intended for use or fully optimized, but it demonstrates all the technical 
flows necessary to make a fully functioning FFI).

```python
import timeit
import tvm
nop = tvm._api_internal._nop

setup = """
import tvm
nop = tvm._api_internal._nop
"""
timer = timeit.Timer(setup=setup,
  stmt='nop((None,..., slice(0, 100, 2)))')
timer.timeit(1)
num_repeat = 1000
print("tvm.tuple_slice_ellipsis_combo:", timer.timeit(num_repeat) / num_repeat)


setup = """
import numpy as np
"""

timer = timeit.Timer(setup=setup,
  stmt='np.empty((1,2,1))')
timer.timeit(1)
print("numpy.emmpty:", timer.timeit(num_repeat) / num_repeat)

setup = """
import tvm
nop = tvm._api_internal._nop
"""
timer = timeit.Timer(setup=setup,
  stmt='nop("mystr")')
timer.timeit(1)
num_repeat = 1000
print("tvm.str_arg:", timer.timeit(num_repeat) / num_repeat)
```

On my laptop(macbook 13inch), the results are as follows
```
$ TVM_FFI=cython python benchmark_ffi.py
tvm.tuple_slice_ellipsis_combo: 4.6157324e-07
numpy.emmpty: 2.701659998834e-07
tvm.str_arg: 2.339079997714e-07
```

##  What is Implemented in the POC 

In the POC, we introduced specific objects for Ellipsis, Slice and 
Tuple(already supported in ADT). During a PackedFunc call, a python 
tuple/ellipsis/slice was  converted into the object that is supported by the 
backend. We implemented a cython version(the previous recursive conversion was 
in python) to back it up. 

The reason that we are able to create Object in the cython side is because all 
TVM object has been recently converted to be POD-C compatible, so the object 
can be created in the cython side without crossing DLL boundary and passed to 
the c++ backend.

We can see from the benchmark that the cost of such deep-copy was at a 
reasonable level. We also only used the default memory allocator, so there 
could be space for further improvements.

##  Discussions

Please also see tradeoff discussions in the last post. As we can see, the main 
difference here is where to do the conversion, and whether do we do lazy/deep 
copy:

- In the case of pybind: conversion is happened in the c++ side, data 
structures are lazily created.
- In the case of the POC: conversion is happened in cython, data structures are 
deeply translated into another in-memory format.

The laziness certainly avoids a copy in cases where we do not necessarily need 
to book-keep the created argument. On the other hand, supporting a common data 
structure in the c++ side means the binding can potentially be reused by other 
language frontends.










-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-568325041

Re: [apache/incubator-mxnet] [RFC][mxnet 2.0][item 10.1] MXNet Imperative Op Invocation Overhead (#17097)

[Tianqi Chen]

The following fast-path can be addressed in the TVM FFI:
- ```tuple``, ```list``` via translation in python/cython side (see benchmark 
above)
- ```str``` is already fast (seem benchmark above)
- ```Context``` can be quite fast if the object is a tvm object, around same 
mangitude as passing NDArray
- ```np.dtype``` can get around by by str conversion, or introduce a type 
structure, TVM FFI support DLDataType natively
- None: natively supported by FFI

The following items needs to be discussed
- py_slice, Ellipsis Can be supported by adding pyobject support, however that 
introduces dispatching into the FFI layer(making the function not accessible to 
other language frontends). Would be interesting to discuss alternatives



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17097#issuecomment-568234198

Re: [DISCUSS] Remove amalgamation

[Tianqi Chen]

The main trade off is that you can do it as long as the all the dependency
is contained easy to build. If you start to involve things like cuda code
you want to switch to formal build system. That is why I explained most
usecases is for a small runtime component

On Sat, Sep 28, 2019 at 10:48 AM Chris Olivier 
wrote:

> This seems similar to sqlite which offers (maybe now by default?) a single
> c file that is the whole DB engine and makes it quite attractive as a local
> db option.
>
> I have no strong opinion on whether or not to keep amalgamation, but I
> wasn’t actually aware of this use-case for mxnet and I recall how much I
> liked sqlite for this.
>
> On Sat, Sep 28, 2019 at 10:17 AM Tianqi Chen 
> wrote:
>
> > To give a complete picture. I will talk a bit about my experience on
> using
> > the all-in-one file approach and a few examples in the tvm project.
> >
> > Currently, tvm uses all-in-one build for its lightweight runtime in cases
> > where we want a separate build system and do not want to bother to use
> > CMake, this include
> >
> > - Standalone deployment:
> > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> > - Android projects where we need to use NDK for cross compilation.
> > - iOS where we need to use XCode.
> >
> > In all these cases, all-in-one build provide the benefit of easy to
> > incorporate into the target project. However, we only use all-in-one
> build
> > for the "minimum runtime" that is necessary to run a model. But will not
> > include components that compiles and optimizes the model as things will
> get
> > out of hand pretty quickly and in those cases, having a build system
> > out-weights the gains of the single file.
> >
> > So if there is a minimum runtime that MXNet wants to incorporate into the
> > users' env and the developers do not want to code up a CMake recipe for
> > that, it is a possible route. And in that case, I would still suggest to
> > move away from the current approach that create a single file but follow
> > the approach in the above link. In both cases, the current amalgamation
> is
> > not fulfilling its function so I think it is fine to remove and add new
> > ones with thoughts if necessary
> >
> > TQ
> >
> > On Sat, Sep 28, 2019 at 9:49 AM Tianqi Chen 
> > wrote:
> >
> > > The main use of amalgamation(aka all in one file build) for cases where
> > it
> > > is hard to setup a Make system. Most user knows how to include a single
> > > file into their project, but it is relatively harder to incorporate an
> > > entire build system.
> > >
> > > As a result, all-in-one file runtime is still being quite widely used
> and
> > > I personally liked the approach, I just suggested that the current
> > approach
> > > may not be the best way to go and creates some maintenance burden.
> > >
> > > See the link of an example project that uses new all-in-one approach
> that
> > > i mentioned(which illustrates the usecase of all-in-one file as well)
> > > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> > >
> > > TQ
> > >
> > > On Sat, Sep 28, 2019 at 3:46 AM Marco de Abreu <
> marco.g.ab...@gmail.com>
> > > wrote:
> > >
> > >> Do we have a good knowledge and overview over all the use cases that
> use
> > >> Amalgamation? At least from my perspective I don't feel well informed
> > >> about
> > >> the blast radius.
> > >>
> > >> -Marco
> > >>
> > >> Junru Shao  schrieb am Sa., 28. Sep. 2019,
> > >> 09:14:
> > >>
> > >> > As Tianqi and Sheng mentioned, given the fact that we are able to do
> > >> > deployment in a possibly better way (correct me if I was wrong), I
> > would
> > >> > love to +1 to Pedro’s proposal.
> > >> >
> > >> > In the meantime, as a healthy open source community, I also agree
> with
> > >> > Naveen’s point that we should do more homework for both our
> developers
> > >> and
> > >> > customers. IMHO, for example, it would be super helpful if Pedro may
> > >> bring
> > >> > up some documentation describing what is the “best practice” of
> using
> > >> the
> > >> > alternative of amalgamation, if our community agree to deprecate it.
> > >> >
> > >> > Thank you guys so much for the discussion!
> > >> >
> > >> > Junru
> >

Re: [DISCUSS] Remove amalgamation

[Tianqi Chen]

To give a complete picture. I will talk a bit about my experience on using
the all-in-one file approach and a few examples in the tvm project.

Currently, tvm uses all-in-one build for its lightweight runtime in cases
where we want a separate build system and do not want to bother to use
CMake, this include

- Standalone deployment:
https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
- Android projects where we need to use NDK for cross compilation.
- iOS where we need to use XCode.

In all these cases, all-in-one build provide the benefit of easy to
incorporate into the target project. However, we only use all-in-one build
for the "minimum runtime" that is necessary to run a model. But will not
include components that compiles and optimizes the model as things will get
out of hand pretty quickly and in those cases, having a build system
out-weights the gains of the single file.

So if there is a minimum runtime that MXNet wants to incorporate into the
users' env and the developers do not want to code up a CMake recipe for
that, it is a possible route. And in that case, I would still suggest to
move away from the current approach that create a single file but follow
the approach in the above link. In both cases, the current amalgamation is
not fulfilling its function so I think it is fine to remove and add new
ones with thoughts if necessary

TQ

On Sat, Sep 28, 2019 at 9:49 AM Tianqi Chen 
wrote:

> The main use of amalgamation(aka all in one file build) for cases where it
> is hard to setup a Make system. Most user knows how to include a single
> file into their project, but it is relatively harder to incorporate an
> entire build system.
>
> As a result, all-in-one file runtime is still being quite widely used and
> I personally liked the approach, I just suggested that the current approach
> may not be the best way to go and creates some maintenance burden.
>
> See the link of an example project that uses new all-in-one approach that
> i mentioned(which illustrates the usecase of all-in-one file as well)
> https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
>
> TQ
>
> On Sat, Sep 28, 2019 at 3:46 AM Marco de Abreu 
> wrote:
>
>> Do we have a good knowledge and overview over all the use cases that use
>> Amalgamation? At least from my perspective I don't feel well informed
>> about
>> the blast radius.
>>
>> -Marco
>>
>> Junru Shao  schrieb am Sa., 28. Sep. 2019,
>> 09:14:
>>
>> > As Tianqi and Sheng mentioned, given the fact that we are able to do
>> > deployment in a possibly better way (correct me if I was wrong), I would
>> > love to +1 to Pedro’s proposal.
>> >
>> > In the meantime, as a healthy open source community, I also agree with
>> > Naveen’s point that we should do more homework for both our developers
>> and
>> > customers. IMHO, for example, it would be super helpful if Pedro may
>> bring
>> > up some documentation describing what is the “best practice” of using
>> the
>> > alternative of amalgamation, if our community agree to deprecate it.
>> >
>> > Thank you guys so much for the discussion!
>> >
>> > Junru
>> >
>> > On Fri, Sep 27, 2019 at 17:00 Tianqi Chen 
>> > wrote:
>> >
>> > > The original amalgamation tries to generate a single file for
>> compilation
>> > > via a script.  This is largely un-necessary, having a file that
>> include
>> > the
>> > > dependent files and compile that one is relatively easy and sometimes
>> > more
>> > > robust(without expanding everything into a single file).
>> > >
>> > > I think it might makes sense to deprecate and remove the current one
>> > given
>> > > that it is no longer properly functioning. If someone is interested,
>> > create
>> > > another deployment example that is more standalone without the file
>> > > expansion. Here is an reference of the "new style" used in the tvm
>> > project
>> > > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
>> > >
>> > > TQ
>> > >
>> > > On Fri, Sep 27, 2019 at 4:49 PM Sheng Zha 
>> wrote:
>> > >
>> > > > As an alternative to amalgamation, could we simply ask users to
>> > > statically
>> > > > link to libmxnet.a, and then prune the symbol table to get rid of
>> the
>> > > > binary of unused functions? Though I don't know the full context of
>> > > > amalgamation, based on my knowledge on this feature I'm not aware of
>> > any
>> > > > diff

Re: [DISCUSS] Remove amalgamation

[Tianqi Chen]

The main use of amalgamation(aka all in one file build) for cases where it
is hard to setup a Make system. Most user knows how to include a single
file into their project, but it is relatively harder to incorporate an
entire build system.

As a result, all-in-one file runtime is still being quite widely used and I
personally liked the approach, I just suggested that the current approach
may not be the best way to go and creates some maintenance burden.

See the link of an example project that uses new all-in-one approach that i
mentioned(which illustrates the usecase of all-in-one file as well)
https://github.com/dmlc/tvm/tree/master/apps/howto_deploy

TQ

On Sat, Sep 28, 2019 at 3:46 AM Marco de Abreu 
wrote:

> Do we have a good knowledge and overview over all the use cases that use
> Amalgamation? At least from my perspective I don't feel well informed about
> the blast radius.
>
> -Marco
>
> Junru Shao  schrieb am Sa., 28. Sep. 2019, 09:14:
>
> > As Tianqi and Sheng mentioned, given the fact that we are able to do
> > deployment in a possibly better way (correct me if I was wrong), I would
> > love to +1 to Pedro’s proposal.
> >
> > In the meantime, as a healthy open source community, I also agree with
> > Naveen’s point that we should do more homework for both our developers
> and
> > customers. IMHO, for example, it would be super helpful if Pedro may
> bring
> > up some documentation describing what is the “best practice” of using the
> > alternative of amalgamation, if our community agree to deprecate it.
> >
> > Thank you guys so much for the discussion!
> >
> > Junru
> >
> > On Fri, Sep 27, 2019 at 17:00 Tianqi Chen 
> > wrote:
> >
> > > The original amalgamation tries to generate a single file for
> compilation
> > > via a script.  This is largely un-necessary, having a file that include
> > the
> > > dependent files and compile that one is relatively easy and sometimes
> > more
> > > robust(without expanding everything into a single file).
> > >
> > > I think it might makes sense to deprecate and remove the current one
> > given
> > > that it is no longer properly functioning. If someone is interested,
> > create
> > > another deployment example that is more standalone without the file
> > > expansion. Here is an reference of the "new style" used in the tvm
> > project
> > > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> > >
> > > TQ
> > >
> > > On Fri, Sep 27, 2019 at 4:49 PM Sheng Zha  wrote:
> > >
> > > > As an alternative to amalgamation, could we simply ask users to
> > > statically
> > > > link to libmxnet.a, and then prune the symbol table to get rid of the
> > > > binary of unused functions? Though I don't know the full context of
> > > > amalgamation, based on my knowledge on this feature I'm not aware of
> > any
> > > > difference in the end result, compared to the code-inlining approach
> > that
> > > > amalgamation takes.
> > > >
> > > > -sz
> > > >
> > > > On 2019/09/12 17:29:02, Naveen Swamy  wrote:
> > > > > so the original email suggesting to remove was after all
> self-serving
> > > :)
> > > > >
> > > > > let's encourage if someone wants to maintain and make use of the
> > > original
> > > > > work and make it better.
> > > > >
> > > > > -1 to remove at this point
> > > > >
> > > > > P.S: I suggest to do some due diligence before bringing topics up
> for
> > > > > discussion.
> > > > >
> > > > > On Wed, Sep 11, 2019 at 8:10 AM Lv, Tao A 
> > wrote:
> > > > >
> > > > > > Sorry to chime in.
> > > > > >
> > > > > > There is a PR to fix amalgamation. I was pinged several times to
> > > merge
> > > > it
> > > > > > but I don't think I have enough knowledge to do that. So it would
> > be
> > > > great
> > > > > > if someone from this thread can help to review.
> > > > > >
> > > > > > https://github.com/apache/incubator-mxnet/pull/15303
> > > > > >
> > > > > > thanks,
> > > > > > -tao
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Marco de Abreu 
> > > > > > Sent: Wednesday, September 1

Re: [DISCUSS] Remove amalgamation

[Tianqi Chen]

The original amalgamation tries to generate a single file for compilation
via a script.  This is largely un-necessary, having a file that include the
dependent files and compile that one is relatively easy and sometimes more
robust(without expanding everything into a single file).

I think it might makes sense to deprecate and remove the current one given
that it is no longer properly functioning. If someone is interested, create
another deployment example that is more standalone without the file
expansion. Here is an reference of the "new style" used in the tvm project
https://github.com/dmlc/tvm/tree/master/apps/howto_deploy

TQ

On Fri, Sep 27, 2019 at 4:49 PM Sheng Zha  wrote:

> As an alternative to amalgamation, could we simply ask users to statically
> link to libmxnet.a, and then prune the symbol table to get rid of the
> binary of unused functions? Though I don't know the full context of
> amalgamation, based on my knowledge on this feature I'm not aware of any
> difference in the end result, compared to the code-inlining approach that
> amalgamation takes.
>
> -sz
>
> On 2019/09/12 17:29:02, Naveen Swamy  wrote:
> > so the original email suggesting to remove was after all self-serving :)
> >
> > let's encourage if someone wants to maintain and make use of the original
> > work and make it better.
> >
> > -1 to remove at this point
> >
> > P.S: I suggest to do some due diligence before bringing topics up for
> > discussion.
> >
> > On Wed, Sep 11, 2019 at 8:10 AM Lv, Tao A  wrote:
> >
> > > Sorry to chime in.
> > >
> > > There is a PR to fix amalgamation. I was pinged several times to merge
> it
> > > but I don't think I have enough knowledge to do that. So it would be
> great
> > > if someone from this thread can help to review.
> > >
> > > https://github.com/apache/incubator-mxnet/pull/15303
> > >
> > > thanks,
> > > -tao
> > >
> > > -Original Message-
> > > From: Marco de Abreu 
> > > Sent: Wednesday, September 11, 2019 9:38 PM
> > > To: dev@mxnet.incubator.apache.org
> > > Subject: Re: [DISCUSS] Remove amalgamation
> > >
> > > Is Amalgamation only used on Android though? Are there any other use
> cases?
> > >
> > > -Marco
> > >
> > > Pedro Larroy  schrieb am Mi., 11. Sep.
> 2019,
> > > 11:57:
> > >
> > > > Hi Anirudh
> > > >
> > > > Appreciate your feedback and sorry if my email came across that way
> to
> > > > you, I think you might miss some context. I don't think calling
> > > > something hacky is anything bad and isn't supposed to be the topic of
> > > > the discussion. It was reported as not working by users, hence the
> > > > original thread. It was a request for opinions from people who might
> > > > actually have tried to work in Mxnet on Android.
> > > >
> > > > Thanks.
> > > >
> > > > Pedro.
> > > >
> > > >
> > > > On Tuesday, September 10, 2019, Anirudh Subramanian
> > > >  > > > >
> > > > wrote:
> > > > > Hi Pedro,
> > > > >
> > > > > I don't see anything "destructive" with Chris asking for
> > > > > justification
> > > > for
> > > > > you calling something "hacky". The only email in this thread where
> I
> > > > > see
> > > > ad
> > > > > hominems and disrespectful comments is your email.
> > > > >
> > > > > On Sat, Sep 7, 2019, 10:18 PM Pedro Larroy
> > > > >  > > > >
> > > > > wrote:
> > > > >
> > > > >> Apache mentors should have a look at these reincident harassment
> > > > >> and destructive behaviors which demotivate contributions and take
> > > > >> action. It takes only one bad apple to ruin a community.
> > > > >>
> > > > >> The mobile solution that is known to work as of know is cross
> > > > >> compiling with "ci/build.py -p build.android_armv8" or
> > > > >> "build.android_armv7". The only advantage of amalgamation is to
> > > > >> provide a smaller binary that we
> > > > could
> > > > >> accomplish with the C preprocessor.
> > > > >>
> > > > >> My technical contributions speak for themselves, including porting
> > > > >> MXNet
> > > > to
> > > > >> Android and ARM and helping many users run MXNet in Jetson,
> > > > >> Raspberry Pi and Android amongst many other topics. I have never
> > > > >> been disrespectful
> > > > to
> > > > >> anyone. I'm entitled to my own technical opinions about
> > > > >> amalgamation or
> > > > any
> > > > >> other piece of code whatsoever, that's no personal disrespect to
> > > > >> anyone
> > > > and
> > > > >> perfectly valid. If you are not interested in this project
> anymore,
> > > > >> do
> > > > us
> > > > >> all a favor and stop trolling and being toxic. If you want my
> > > > >> respect,
> > > > step
> > > > >> up your technical contributions, be positive and encourage others,
> > > > >> this including commits, I haven't seen for many months, please be
> > > > >> positive
> > > > and
> > > > >> constructive. This scorched-earth attitude is only reflecting bad
> > > > >> on
> > > > you.
> > > > >> I'm certainly not interested in your ad-hominems or unasked for
> > > > technical
> > > > >> advice, which to be honest,  

Re: [RFC] Integrate TVM into Apache MXNet

[Tianqi Chen]

Thanks yizhi,In the future, It might make sense to automatically mirror the
github issues with certain prefix(eg RFC) into dev@

TQ

On Fri, Jul 5, 2019 at 12:18 PM YiZhi Liu  wrote:

> Kindly remind people take a look at the posted RFC:
> https://github.com/apache/incubator-mxnet/issues/15465 and free free
> to leave your questions and suggestions
>
> --
> Yizhi Liu
> Bay Area, the United States
>

Re: [VOTE] Remove conflicting OpenMP from CMake builds

[Tianqi Chen]

In a situation like this, I would suggest a DISCUSS thread is more proper
before the voting one.
As the tension can generally be high in a voting thread and it is hard to
make a technical decision without previous discussions and pros/cons being
listed.

Tianqi

On Fri, Jun 14, 2019 at 4:59 PM 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 3rdparty and uses the system
> provided one which might resolve a number of difficult to debug issues
> and possible undefined behaviour.
>
> https://github.com/apache/incubator-mxnet/pull/12160
>
> See the comments in the thread for more details but in short, linking
> with multiple openmp versions seems to lead to undefined behaviour,
> plus it would simplify not having to deal with a custom openmp version
> and rely on the platform provided one.
>
> This is expected to simplify builds and address a number of problems.
> Seems it doesn't cause any performance degradation, (the Gluon tests
> run almost 4x faster in my 64 core machine).
>
> There has been in depth study of performance implications by
> contributors like Stanislav Tsukrov and Anton Chernov.  All the
> concerns and comments from the reviewers have been addressed and we
> can't keep asking open ended questions to block PRs. Reviewers are
> expected to be proactive and responsive to contributors so we keep
> encouraging active contributors.
>
> please vote to merge this PR accordingly:
>
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
> If we observe regressions reported by any internal performance systems
> or by contributors the PR can be reverted easily. So it's not a one
> way door. But it will be useful to try this in master for a while.
>
> Thank you.
>
> Pedro.
>

Re: Does internal quality matters to users?

[Tianqi Chen]

k
> > > experimentation and research but please try to understand my
> > > perspectives coming from a software engineering background and helping
> > > maintain MXNet for thousands of users and teams using it in
> > > production. Let's also consider how many issues we have open and our
> > > bandwidth to deal with additional complexity.
> > >
> > > To your pros and cons I would like to add and emphasize that currently
> > > the heavy use of dynamic attributes in the graph using dmlc::any has
> > > two very negative consequences, at least for MXNet:
> > >
> > > 1 - Makes the data structures using dmlc::any almost impossible to
> > > debug, as they are just binary.
> > > 2 - Makes the code more difficult to understand because there's no
> > > declaration in a data structure of the data fields it uses and its
> > > responsibilities. We are basically shoving all kinds of stuff using
> > > dmlc::any.
> > > 3 - You get no help from the IDE to navigate and refactor as another
> > > consequence.
> > >
> > > I would really like you to give me solutions to these problems or at
> > > least acknowledge them and tell me why do we have to pay those
> > > tradeoffs instead of just dismissing them as engineering taste.
> > >
> > > The more I work with MXNet the more I wish debugging was easier, and
> > > reading and refactoring the code, and those fields would be declared
> > > and typed in their corresponding data structures, for MXNet I don't
> > > think this would affect anything in regards the python bindings since
> > > they go through the typed C API anyway.
> > >
> > > Maybe we can get some inspiration from LLVM as they have bindings for
> > > many languages to work with the AST and have very clean APIs for the
> > > compilation steps. It's also OK to have an initial dynamic codebase
> > > for research and experimentation and then "cure" them into a solid
> > > maintainable one with more types and more robust...
> > >
> > > Pedro.
> > >
> > >
> > >
> > >
> > >
> > > On Fri, May 31, 2019 at 9:31 AM Tianqi Chen 
> wrote:
> > > >
> > > > A good infrastructure design has a long way to go and has a profound
> impact on the project itself. That is why we always want to rethink if the
> interface can be better done, and think about the next possible
> infrastructure to make things better, Refactoring is certainly part of it.
> > > >
> > > > There are usually two types of refactoring we refers to :
> > > > 1) The major design change, in terms of class relations, data
> structures (e.g. numpy support, adding compilation to new hardware)
> > > > 2) The specific choice of API, programming style(more types or
> type-erased program)
> > > >
> > > > (1) affects the long term support of the project, introduces new
> features if necessary and need a lot of thoughts into that. I believe the
> general IR, compilation and numpy support belongs to that category.
> > > >
> > > > I would particularly like to talk about (2).
> > > > Because there is no unified correct answer in software engineering,
> different developers may prefer different views on a certain problem.
> > > > Some of them have things to do with the taste developers. The change
> could favor certain aspect of the project, but not necessarily another part.
> > > > Refactoring wrt these sometimes does require a more thoughtful
> conversation and make a reasonable compromise.
> > > >
> > > > For example, we have a recent discussion about whether to introduce
> more typing into the code base, to the extent that the base data structure
> could be templatized.
> > > > - The Pros of this approach
> > > > - It introduces more typing and compile-time error
> message(instead of runtime checking), could help developers to find problem
> earlier.
> > > > - The Cons of the approach:
> > > >- Having a template in the base data structure causes ABI
> problem(which code generated by DLL A vs DLL B) and will have potential
> future issues.
> > > >- Template sometimes confuses some developers.
> > > >- For serialization, it is hard to anticipate all kinds of
> classes and it is easier to have one class(any) that handles polymorphism.
> > > >- Because of most frontends(python) are dynamic, it is easier to
> interface them with a type-erased API.
> > > >
> &g

Re: Does internal quality matters to users?

[Tianqi Chen]

> Re that particular case.
>
> The shape of vector will be typed after being fetched and won’t affect the
> general effort for programming. Getting the shape vector out contains
> around one line of code.
>
> The str to any map is defined to enable future compatibility of the
> general set of attributes. While it is possible to specialize such kind of
> attributes, this will likely make the set of code processing one kind of
> attributes differ from another.
>
> In summary, there won’t really be any problem keeping the any storage of
> the shape vector, as long as it is properly documented.
>
> Tianqi
>
> On Tue, Jun 11, 2019 at 11:07 AM Pedro Larroy <
> pedro.larroy.li...@gmail.com> wrote:
>
>> To put a recent specific example and focus the discussion (there are
>> many as there are attributes), the shapes in the graph are a vector of
>> Shape set as an attribute using dmlc::any so this makes it very
>> difficult to debug the shapes when you have a graph object. I would
>> have it as a typed attribute to the graph, as we always need the
>> vector of shapes and operate on it while doing shape inference.
>>
>> On Tue, Jun 11, 2019 at 10:18 AM Pedro Larroy
>>  wrote:
>> >
>> > Thanks for the good discussion.
>> >
>> > I actually wasn't referring particularly to our conversations in
>> > github with respect of the refactors, but it's nice from you to bring
>> > them up. And it's ok to disagree in small things, hopefully we can
>> > align in the big ones.
>> >
>> > I understand that for TVM you might have different constraints with
>> > how dynamic you want to be for mutating the graph and doing quick
>> > experimentation and research but please try to understand my
>> > perspectives coming from a software engineering background and helping
>> > maintain MXNet for thousands of users and teams using it in
>> > production. Let's also consider how many issues we have open and our
>> > bandwidth to deal with additional complexity.
>> >
>> > To your pros and cons I would like to add and emphasize that currently
>> > the heavy use of dynamic attributes in the graph using dmlc::any has
>> > two very negative consequences, at least for MXNet:
>> >
>> > 1 - Makes the data structures using dmlc::any almost impossible to
>> > debug, as they are just binary.
>> > 2 - Makes the code more difficult to understand because there's no
>> > declaration in a data structure of the data fields it uses and its
>> > responsibilities. We are basically shoving all kinds of stuff using
>> > dmlc::any.
>> > 3 - You get no help from the IDE to navigate and refactor as another
>> > consequence.
>> >
>> > I would really like you to give me solutions to these problems or at
>> > least acknowledge them and tell me why do we have to pay those
>> > tradeoffs instead of just dismissing them as engineering taste.
>> >
>> > The more I work with MXNet the more I wish debugging was easier, and
>> > reading and refactoring the code, and those fields would be declared
>> > and typed in their corresponding data structures, for MXNet I don't
>> > think this would affect anything in regards the python bindings since
>> > they go through the typed C API anyway.
>> >
>> > Maybe we can get some inspiration from LLVM as they have bindings for
>> > many languages to work with the AST and have very clean APIs for the
>> > compilation steps. It's also OK to have an initial dynamic codebase
>> > for research and experimentation and then "cure" them into a solid
>> > maintainable one with more types and more robust...
>> >
>> > Pedro.
>> >
>> >
>> >
>> >
>> >
>> > On Fri, May 31, 2019 at 9:31 AM Tianqi Chen 
>> wrote:
>> > >
>> > > A good infrastructure design has a long way to go and has a profound
>> impact on the project itself. That is why we always want to rethink if the
>> interface can be better done, and think about the next possible
>> infrastructure to make things better, Refactoring is certainly part of it.
>> > >
>> > > There are usually two types of refactoring we refers to :
>> > > 1) The major design change, in terms of class relations, data
>> structures (e.g. numpy support, adding compilation to new hardware)
>> > > 2) The specific choice of API, programming style(more types or
>> type-erased program)
>> > >
>> > > (1) affects 

Re: Does internal quality matters to users?

[Tianqi Chen]

A good infrastructure design has a long way to go and has a profound impact
on the project itself. That is why we always want to rethink if the
interface can be better done, and think about the next possible
infrastructure to make things better, Refactoring is certainly part of it.

There are usually two types of refactoring we refers to :
1) The major design change, in terms of class relations, data structures
(e.g. numpy support, adding compilation to new hardware)
2) The specific choice of API, programming style(more types or type-erased
program)

(1) affects the long term support of the project, introduces new features
if necessary and need a lot of thoughts into that. I believe the general
IR, compilation and numpy support belongs to that category.

I would particularly like to talk about (2).
Because there is no unified correct answer in software engineering,
different developers may prefer different views on a certain problem.
Some of them have things to do with the taste developers. The change could
favor certain aspect of the project, but not necessarily another part.
Refactoring wrt these sometimes does require a more thoughtful conversation
and make a reasonable compromise.

For example, we have a recent discussion about whether to introduce more
typing into the code base, to the extent that the base data structure could
be templatized.
- The Pros of this approach
- It introduces more typing and compile-time error message(instead of
runtime checking), could help developers to find problem earlier.
- The Cons of the approach:
   - Having a template in the base data structure causes ABI problem(which
code generated by DLL A vs DLL B) and will have potential future issues.
   - Template sometimes confuses some developers.
   - For serialization, it is hard to anticipate all kinds of classes and
it is easier to have one class(any) that handles polymorphism.
   - Because of most frontends(python) are dynamic, it is easier to
interface them with a type-erased API.

As we can see there are pros and cons of bringing in more typing to the
change, and there is no unified answer.
One good example of a nice infrastructure design trade-off is DLPack
https://github.com/dmlc/dlpack/blob/master/include/dlpack/dlpack.h
This is a base data structure adopted by MXNet, Pytorch, Chainer, and many
other frameworks unanimously.
It is a type-erased data structure that erases the data type, and memory
allocator from the data structure and is designed to exchange tensor(coming
from different memory allocators) across DLL boundaries.
As you can see this is a good example of type-erased data structures.

When we are having this kind of questions. It is important to have a good
conversation. Sometimes we have to make tradeoffs rather than bend
everyone-else to our will. This is what open source is about.
I would also like to give some examples of conversations and how design
decisions are resolved. It comes from the TVM community's recent discussion
about VM design.
I directly paste the github issue conversation here for the sake of
clarity(note that all the conversations are also mirrored to dev@tvm).
The background is that the community want to bring a virtual machine that
can execute dynamic operations more effectively.

- The initial proposal, made by one of the committers gave a detailed
design based on Stack VM https://github.com/dmlc/tvm/issues/2810
   - As you can see that there are quite some discussions about whether we
want to use a different set of design, in this case, a register-based
version.
   - The conversation evolves, and while the community members disagree on
some cases, also agrees with each other on the particular tradeoffs.
- After some discussions, the committers bring a tradeoff design that tries
to consolidate the needs of both sides and this is the final solution being
adopted  https://github.com/dmlc/tvm/issues/2915
I would like to particularly highlight the fact that: 1) there are
disagreements in the development process. 2) developers work together to
understand each others' needs and then make consensus on a perhaps better
design.

There are two other particular conversations between Pedro and myself,
which are during his contributions.
- https://github.com/dmlc/tvm/pull/3037 In this case, I raised the concern
about API consistency, and Pedro brings up a reason why he thinks it is a
better idea, I agreed and we merged the PR
- https://github.com/dmlc/tvm/pull/3108 In this other case, there are
technical reasons for going both sides for the case of MXNet, we have
listed pros/cons about both sides and have a constructive conversation.
Eventually, I decided to not merge the PR after weighing in all the cases.

I believe both are useful conversations, and while Pedro and I disagree
sometimes, we do agree on many other cases. The most crucial part is about
having a constructive conversation.
To summarize, I do refactoring and making things better is certainly
important to make the project 

Re: [Proposal] New operator graph for MXNet

[Tianqi Chen]

gt; > > > I really appreciate that a diligent and talented engineer eagerly
> wants
> > > to
> > > > improve our system, and am very thankful that you have done so much
> for
> > > our
> > > > community. However, I do want to mention some points that I believe I
> > > > should mention.
> > > >
> > > > While I agree with Tianqi that every design has its pros and cons, I
> > > would
> > > > love to emphasize that a *good taste* of system design is to optimize
> > the
> > > > bottleneck, enhance expressiveness (and usability), i.e. to do what
> > needs
> > > > doing, rather than *trivial nits* that are irrelevant to either
> > > performance
> > > > or expressiveness. Generally speaking, typed or untyped, shared_ptr
> or
> > > > unique_ptr, won't affect the overall performance when it comes to
> deep
> > > > learning workload, specially when we have an async scheduler that
> does
> > > good
> > > > latency hiding in MXNet - to me, these are not major issues that are
> > > worth
> > > > re-designing our entire system.
> > > >
> > > > To benefit users - real-world ML practitioners, the most thing I
> would
> > > love
> > > > to mention is that dataflow graph-based representation is
> increasingly
> > > > incapable of modern neural networks, because the increasingly
> appeared
> > > > structures like arbitrary control flow (w/ continue, break, etc),
> > > > recursion, type conjunction and disjunction, etc. These issues will
> be
> > > our
> > > > priority to address, which is brought by Relay, which addresses all
> > these
> > > > pain points.
> > > >
> > > > Another minor thing I would love to humbly mention is that, for sake
> of
> > > our
> > > > brand, it is our responsibility to be professional about
> terminologies
> > > when
> > > > writing an official proposal on Confluence. As one of the numerous
> > > > examples, the title of the proposal really shocks me for a while,
> > > something
> > > > like "operators graph" blah blah so weird. Educate me if I were
> wrong,
> > > but
> > > > compiler community would prefer the term "intermediate
> representation",
> > > and
> > > > distributed system community would prefer "dataflow graph". If you
> > don't
> > > > have knowledge in these fields, a better way for efficient
> > communication
> > > is
> > > > to get yourself first familiarize the most basic concepts and then do
> > > > discussion. This is a way to save your own valuable time as well.
> > > >
> > > > Again, thank you so much for your hard work, and hope that we could
> > work
> > > > together to win customers in the future :-)
> > > >
> > > > Thanks,
> > > > Junru
> > > >
> > > >
> > > > On Tue, May 14, 2019 at 8:03 PM Tianqi Chen <
> tqc...@cs.washington.edu>
> > > > wrote:
> > > >
> > > > > The core part of the proposal is to move the graph to be much more
> > > > strongly
> > > > > typed template class.
> > > > > I think this is mainly a point of engineering taste, and both sides
> > > have
> > > > > pros and cons, let me list them before I share my thoughts on this
> > > issue:
> > > > >
> > > > > - Typed fields certainly enjoy more compile-time type checking, on
> > the
> > > > > other hand, it is hard to expose
> > > > >template of explosive possibilities to frontend languages.
> > > > > - More type-erased fields provide runtime flexibility to store
> > > > polymorphic
> > > > > types as well as extensible attributes for graph optimization
> > > > >   - It is hard to use a virtual class to expose every possible
> > > attribute
> > > > > that an operator might have, such as inlining, storage pattern,
> > > gradient
> > > > > etc..
> > > > >   - The nature of supporting a growing set of operator attribute
> > > > requires a
> > > > > type-erased attrs field.
> > > > > - In contrast to your argument(typing is a blocker to features),
> > > > > type-erased or typed code can both get to the same feature except

Re: [Proposal] New operator graph for MXNet

[Tianqi Chen]

The core part of the proposal is to move the graph to be much more strongly
typed template class.
I think this is mainly a point of engineering taste, and both sides have
pros and cons, let me list them before I share my thoughts on this issue:

- Typed fields certainly enjoy more compile-time type checking, on the
other hand, it is hard to expose
   template of explosive possibilities to frontend languages.
- More type-erased fields provide runtime flexibility to store polymorphic
types as well as extensible attributes for graph optimization
  - It is hard to use a virtual class to expose every possible attribute
that an operator might have, such as inlining, storage pattern, gradient
etc..
  - The nature of supporting a growing set of operator attribute requires a
type-erased attrs field.
- In contrast to your argument(typing is a blocker to features),
type-erased or typed code can both get to the same feature except, except
that
  typed code gets more compile-time errors while type-erased get some of
them in runtime.
- Templatized data structures will likely introduce additional metal
burdens to developers and are not really suitable as a core data structure
   - Because they imply an explosive number of possible data structures,
while the core data structure should be a single one.

Now my view(as an MXNet PMC member) on typed vs type-erased style: If MXNet
is a pure C++ project, I might take more of the typed approach.
However, MXNet itself is a project that takes python/scala/clojure and
other frontend languages.
The introduction of more typing may not align with the original goal as the
tradeoffs I listed above.

This proposal is really a drastic change of what NNVM does, as well as the
optimization passes, and given the scope, in your analogy, "a new vehicle
to solve all the problems"
rather than a minor patch. It will take a lot of engineering effort to
bring in new features and adapting the existing ones.
Because of that, it does merit a discussion about how shall we think about
the future MXNet2.0.

Technically Relay is a serious candidate. Of course relay, as well as its
core, is in C++ but maintains the multi-language first principle, that is
why the example code was in python.
See more related discussion comparing NNVMv1 and relay:
https://discuss.tvm.ai/t/any-materials-of-relay-for-beginners/2392/5

I think the ideal graph data structure candidate for MXNet2.0 should have
natural support for:
- Native support of function, module, and recursions
- Control flows
- The ability of interpolation with multi-language frontend, e.g. being
able to prototype graph optimizations in python/scala/clojure if needed.

Adding these support needs significant engineering effort, and I do hope we
only have to do it once. While I don't want to force any conclusion here,
I do think Relay is one such candidate.

Tianqi


On Tue, May 14, 2019 at 5:58 PM Pedro Larroy 
wrote:

> Hi Tianqi
>
> Thanks for the quick response.
>
> Could you point to examples where graph.h is being exposed which would
> not be possible with what I propose? I don't think my proposal is
> having any impact in language bindings, and the way I describe it
> doesn't affect having or not having higher language bindings. Please
> elaborate so I can understand your concern.  Maybe code examples where
> the graph attributes are being changed from Python?  I don't think we
> have this on MXNet. This is such a core foundation for MXNet, that I
> don't think we should compromise on it because other project not
> directly related to MXNet might want to expose some untyped graph and
> Node attributes.  The current status makes maintaining the code very
> painful and also is preventing desired features such as higher order
> gradients to be developed. I have heard from you many times how speed
> is critical for us to innovate in this quickly changing field.
>
> My proposal is limited to the graph and wouldn't change the way
> operators are registered and arguments are processed for operators for
> example.
>
>
> Regarding the second point, the documentation about Relay in the web
> which I found for example:
>
> https://docs.tvm.ai/dev/relay_add_op.html#
>
> Is somebody working on making Imperative::Backward use this API? this
> would be a big change which I'm not aware of. And using an IR is of a
> much bigger scope than the change I'm proposing here for example.
>
> I think I'm having difficulty understanding what are the arguments
> here. I'm saying I need to change one piece of my car and what you are
> selling me is a new vehicle here?  Or your suggestion that we use
> Relay for the graph passes in MXNet?
>
> I would like to see C++ code examples, Python examples are not
> sufficient when we talk about the core MXNet.
>
> Pedro.
>
>
>
>
>
>
> On Tue, 

Re: [Proposal] New operator graph for MXNet

[Tianqi Chen]

Thanks for the proposal. Let me share some of my thoughts:

Specific comments on the proposal
---
The heavy use of generic in the Graph type was a huge departure from
type-erased data structure which was presented in the previous design.
While we understand the advantage of typed language(more compile-time
checking) and type-erased types(more dynamism) the heavy use of
the template will actually make the project solely C++ focused, making it
hard to expose intermediate(templatized) data structure to
other languages like python/scala/clojure.

While I fully understand some of the lessons taught in programming
C++(reduce shared_ptr, more typing etc.)
We need to think about the context of MXNet project and **the need to
support multi-language as a first-class**.
Some of the type-erased types are design trade-offs made to support these
features, and we need to think more
carefully instead of just applying "rules for C++" which may bring problems.

Future of NNVM
--
Given that this thread touched upon what we should do for better
computational graph handling. I would recommend also to take a look at
NNVMv2 -- relay.

Relay addresses many of the wish-lists in the proposal already, such as
operator fusion, high order gradient, offload to hardware, isolated
compilation, deployment on edge and accelerators etc.
Relay also address problems not yet being mentioned in the proposal,
including control flow and dynamic runtime, automatic layout optimization
etc.

Tianqi

On Tue, May 14, 2019 at 5:06 PM Sheng Zha  wrote:

> Hi Pedro,
>
> Thanks for taking the inititaive. Skimming through the design doc, I
> didn't see comparison with existing solutions such as relay in tvm, which
> is already a dependency of mxnet already. Could you elaborate on comparison
> with existing solutions in the design doc too?
>
> -sz
>
> On 2019/05/14 23:49:30, Pedro Larroy 
> wrote:
> > Hi dev@
> >
> > As a result of my deep dives on the graph machinery I have created a
> > new proposal to improve the operator graph in MXNet.
> >
> > This would mean superseding the use of NNVM Graph in MXNet and having
> > a new implementation that we can use to simplify a lot of code and do
> > powerful graph manipulation and passes such as operator fusion and
> > other optimizations.
> >
> > As it would be a change with big impact and ramifications, your
> > thoughts and feedback on the document would be highly appreciated so
> > we can take potential future interesting use cases:
> >
> >
> https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0
> >
> > Pedro.
> >
>

Re: [MXNET 2.0 Wishlist] [DISCUSS] Backend choices during runtime

[Tianqi Chen]

+1.

While I like slack, personally,  I don't think we should treat slack as
public-archive. "everything that happens (also) happens in dev@"

Tianqi



On Fri, Apr 12, 2019 at 1:19 AM Marco de Abreu 
wrote:

> I'd prefer if we keep discussions on the dev-list instead of slack - feel
> free to open another thread.
>
> -Marco
>
> Pedro Larroy  schrieb am Fr., 12. Apr. 2019,
> 02:24:
>
> > I will respond in slack, so we don't derail the original thread's
> > topic with my points.
> >
> > Looking forward to your proposal.
> >
> > On Thu, Apr 11, 2019 at 1:00 PM Junru Shao 
> > wrote:
> > >
> > > I don't have idea about the following issues:
> > >
> > > 1) Reducing the abuse of inlined code moving more logic to
> implementation
> > > files and improve scoping which will also speed up compilation
> > > 2) Reduce runtime of some unit tests
> > > 3) Improve MXNet startup time
> > >
> > > Will be super interested to hear about your ideas :-)
> > >
> > >
> > > On Thu, Apr 11, 2019 at 12:52 PM Junru Shao 
> > wrote:
> > >
> > > > We have a systematic solution to go without ABI headache. I am
> > struggling
> > > > with some errants, and will share our proposal here as soon as I
> could.
> > > > This will be very interesting topic to discuss. Let's work hard
> > together
> > > > and make it perfect :-)
> > > >
> > > > On Thu, Apr 11, 2019 at 12:43 PM Pedro Larroy <
> > > > pedro.larroy.li...@gmail.com> wrote:
> > > >
> > > >> Thanks Marco for raising this issue. I think we can certainly do
> some
> > > >> improvements in modularization and build. At the same time Tianqi's
> > > >> point of view is important to consider and on point. I see a high
> risk
> > > >> of overengineering in such endeavor.
> > > >>
> > > >> I also see increased complexity, difficulty debugging, C++ ABI
> > > >> headaches, API compatibility, crashes inside a binary module, etc.
> > > >> which I don't want to deal with as a developer or even as an MXNet
> > > >> user. Does somebody have answers to these problems?
> > > >>
> > > >> If somebody thinks they have a good solution, by all means propose a
> > > >> design in the wiki, I think we are all open. Personally I see
> several
> > > >> other lower hanging fruits which need our attention:
> > > >>  * Simplifying our build logic,
> > > >>  * Cuda selection in CMake,
> > > >>  * Reducing the abuse of inlined code moving more logic to
> > > >> implementation files and improve scoping which will also speed up
> > > >> compilation, (some units take more than 5 minutes to build and lots
> of
> > > >> RAM in a top of the line CPU core)
> > > >>  * Reduce runtime of some unit tests
> > > >> And other  improvements in our codebase that would bring immediate
> > > >> benefits without the risks of overengineering of a plugin system. I
> > > >> also question our bandwidth for such an endeavor.
> > > >>  * Improve MXNet startup time.
> > > >>  * Thread safety
> > > >>
> > > >> I would say, let's apply the KISS principle, let's make the project
> > > >> fast to build, easy to work on, well documented and easy to
> contribute
> > > >> to before building the next Netscape browser. Otherwise we could
> save
> > > >> ourselves this exercise and switch to Rust directly.
> > > >>
> > > >> Pedro.
> > > >>
> > > >>
> > > >>
> > > >> On Mon, Apr 8, 2019 at 9:42 AM Tianqi Chen <
> tqc...@cs.washington.edu>
> > > >> wrote:
> > > >> >
> > > >> > Just to clarify. I am not questioning the usefulness of the
> > separation.
> > > >> > Just want to highlight the technical challenges here based on our
> > past
> > > >> > experiences.
> > > >> >
> > > >> > Crossing DLL boundaries in C++ can create quite a lot of problems,
> > > >> > especially some of the dependencies used a different version of
> the
> > > >> > compiler, follows static packaging or simply because of the
> dynamic
> > > >> linking
> > > >> > difference in windows. These problems c

Re: [MXNET 2.0 Wishlist] [DISCUSS] Refine the InferStorageType and memory planning pass

[Tianqi Chen]

Such kind of conversion can be viewed as an enhanced version of
AlterOpLayout in the TVM relay Pass

On Tue, Apr 9, 2019 at 8:03 PM Lv, Tao A  wrote:

>
> Thank you Tianqi and Sam for the kind suggestions.
>
> @Tianqi,
>
> Can you please point me to the code of this pass or do you think anyone
> from TVM community can help to educate me on this? I'm very happy to learn
> from that.
>
> Just one note, we are not only doing layout transformation but also want
> to have more memory for layout transformation.
> For example, (N=32, C=3, H=256, W=256) will be padded to (N=32, C=16,
> H=256, W=256) on channel dimension then convert (N=32, C=16, H=256, W=256)
> to nchw16c so we can leverage corresponding optimal computation kernels.
> That's why we also need changes to the memory planning pass.
>
>
> @Sam,
>
> Yes, definitely we're treating MKL-DNN as an accelerator on CPU.
> Previously we used it to accelerate certain critical operators in MXNet in
> certain situations, eg. FP32 convolution/deconvolution/fullyConnected, etc.
> But along with the evolving of both MXNet and MKL-DNN, we started to do
> more which might not supported by MXNet in original CPU implementation,
> such as quantization and graph fusion. So MKL-DNN backend is also changing
> from a simple `accelerator` to a `default` backend on CPU. And I totally
> agree with you that we need think more about the software architecture for
> maintainability, testability and readability - that's why I sent out this
> proposal to get more ideas from the community.
>
>
> -tao
>
> -Original Message-
> From: Skalicky, Sam [mailto:sska...@amazon.com.INVALID]
> Sent: Wednesday, April 10, 2019 2:24 AM
> To: dev@mxnet.incubator.apache.org
> Subject: Re: [MXNET 2.0 Wishlist] [DISCUSS] Refine the InferStorageType
> and memory planning pass
>
> I agree with Tianqi. We should let MKLDNN partitipate in memory planning
> by first having a separate NNVM pass and then using that info in the
> regular memory planning phase.
>
> Its starting to sound like MKLDNN should be treated like an accelerator
> rather than an operator library. As it has explicit needs and can provide
> acceleration when given extra capabilities in MXNet like having input to
> the memory planning NNVM pass. It also has special tensor formatting needs
> and conversions that could be best architected in another way than they
> currently are.
>
> We need to think about how we want to architect this for maintainability,
> testability, and readability.
>
> Sam
>
>
> > On Apr 9, 2019, at 11:11 AM, Tianqi Chen 
> wrote:
> >
> > The layout transformation should really be a separate optimization
> > pass rather than memory planning. As is done in the TVM stack. If we
> > want to do a clean slate solution, I would recommend looking into that
> instead.
> >
> > TIanqi
> >
> > On Tue, Apr 9, 2019 at 1:46 AM Lv, Tao A  wrote:
> >
> >>
> >>
> >> Hi dev,
> >>
> >>
> >>
> >> As we're discussing the roadmap for MXNet 2.0, I would like to start
> >> a thread about refining the InferStorageType and memory planning pass
> >> in MXNet and hope it can happen as a part of the 2.0 release.
> >>
> >>
> >>
> >> Thanks to @eric-haibin-lin, part of the proposal has already been
> >> discussed in issue #13598 [1].
> >>
> >>
> >>
> >> As mentioned in the description of issue #13598, there are several
> >> drawbacks of the existing flow. Please allow me to quote them here:
> >> *the selection of MKL/CPU/GPU/CUDNN implementation happens after
> >> graph attribute inference and memory planning, memory planning is
> >> thus not aware of the implementation that will be used for execution
> >> in the future, which may result in sub-optimal result. For example,
> >> the memory inplace option may vary depending on the accelerator
> >> backend (the new version of CUDNN enables x/dx inplace for
> _backward_conv).
> >> *some sparse operator need to access dtype/shape information to
> >> decide which implementation to invoke for execution, and whether to
> >> perform fallback. This information is not yet exposed in the existing
> >> infer storage type interface.
> >>
> >>
> >>
> >> Besides, the existing memory planning pass calculates and afterwards
> >> allocates memory strictly according to the input/output tensor shapes
> >> (which can be got from operators' arithmetic formulas through
> InferShape).
> >> That's not true anymore when we come to accelerators lik

Re: [MXNET 2.0 Wishlist] [DISCUSS] Backend choices during runtime

[Tianqi Chen]

Just to clarify. I am not questioning the usefulness of the separation.
Just want to highlight the technical challenges here based on our past
experiences.

Crossing DLL boundaries in C++ can create quite a lot of problems,
especially some of the dependencies used a different version of the
compiler, follows static packaging or simply because of the dynamic linking
difference in windows. These problems could make this direction move less
appealing compared to focusing effort on other things.

Technically, as a first step, it is possible to make dependencies change
not change the global header files and via registration so that changing
certain component won't trigger a global recompile in CMake. This is also a
required step toward some modularity.

For plugins, solutions that use C ABI can be used for certain plugin
modules.

Some of the discussion has been tied to what the interface should look
like. I think we should use different threads for these and puts in more
thoughts.

Tianqi



On Sun, Apr 7, 2019 at 4:39 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> I think we can make some incremental progress.  My thoughts were along the
> lines of plugins (thinking about what happens with the VLC project).  At
> process launch time we could gather some information about our execution
> environment (either through configuration, or by convention looking at our
> folder structure and libraries available).  We could then later load the
> components we need after understanding if we're using a CUDA backend and
> what operators or subgraph components we would need.  Advantages would be
> that we would move a lot of the current conditional compile logic to
> runtime, and automate a lot of it.  It would also make packaging binaries
> for targeted environments a little easier.  As an example we could compile
> once, then remove CUDA focused libraries for systems that are going to run
> on CPUs.
>
> On Sun, Apr 7, 2019 at 2:45 PM Tianqi Chen 
> wrote:
>
> > While I personally like the idea. This can be something that is fairly
> > technical challenging and I would caution against this idea vs pushing
> for
> > good features and just allow runtime configuration.
> >
> > The main problem here is due to the C++ ABI. There is no standard c++ ABI
> > across compilers, which means resorting to runtime DLL and dynamic
> loading
> > brings all sorts of technical problems, especially when multiple modules
> > depend on the same third dependency(CUDA runtime).
> > There is no good to go solution can be made here, especially given the
> > explosion of the backend variants and dependencies in C++.
> > A partial solution could be achieved, through the sole use of C ABI.
> > Combing this with code generation can result in some simplifications and
> > enable some runtime loadable module. TVM does this, and perhaps MXNet
> could
> > reuse some of that component for operator libraries. Similarly, having a
> > customizable operator library that is loadable via C ABI might be
> possible.
> >
> > So to summarize, while I really like the idea of dynamically loadable
> > modules. My past experience suggests that this will bring a lot of
> > additional engineering burden and technical debts without significant
> > benefit. I would suggest starting by supporting something simple like a
> > plugin module, before moving toward the general direction.
> >
> > Tianqi
> >
> > On Sun, Apr 7, 2019 at 1:31 PM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > Strongly support the idea of runtime loadable components in MXNet.
> > There's
> > > no reason (other than perhaps engineering effort) we can't have a
> single
> > > compilation of MXNet that finds dependencies and chooses execution
> paths
> > > intelligently (or based on configuration) at runtime.
> > >
> > > On Thu, Apr 4, 2019 at 12:29 PM Marco de Abreu 
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I'd like to start a discussion about something that I've noticed
> being
> > > > troublesome to maintain in the current version: Backend choices being
> > > made
> > > > at compile time.
> > > >
> > > > Right now, the different backends and accelerators (CPU, cuda, mkl,
> AWS
> > > > elastic inference, (future) AMD, openblas,TVM, etc) are all scattered
> > > > across the different layers of MXNet. On one hand, we have compile
> time
> > > > flags that decide which backends are being compiled into the binary,
> > > while
> > > > at the same time choices can be made in the frontend during 

Re: [MXNET 2.0 Wishlist] [DISCUSS] Backend choices during runtime

[Tianqi Chen]

While I personally like the idea. This can be something that is fairly
technical challenging and I would caution against this idea vs pushing for
good features and just allow runtime configuration.

The main problem here is due to the C++ ABI. There is no standard c++ ABI
across compilers, which means resorting to runtime DLL and dynamic loading
brings all sorts of technical problems, especially when multiple modules
depend on the same third dependency(CUDA runtime).
There is no good to go solution can be made here, especially given the
explosion of the backend variants and dependencies in C++.
A partial solution could be achieved, through the sole use of C ABI.
Combing this with code generation can result in some simplifications and
enable some runtime loadable module. TVM does this, and perhaps MXNet could
reuse some of that component for operator libraries. Similarly, having a
customizable operator library that is loadable via C ABI might be possible.

So to summarize, while I really like the idea of dynamically loadable
modules. My past experience suggests that this will bring a lot of
additional engineering burden and technical debts without significant
benefit. I would suggest starting by supporting something simple like a
plugin module, before moving toward the general direction.

Tianqi

On Sun, Apr 7, 2019 at 1:31 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Strongly support the idea of runtime loadable components in MXNet.  There's
> no reason (other than perhaps engineering effort) we can't have a single
> compilation of MXNet that finds dependencies and chooses execution paths
> intelligently (or based on configuration) at runtime.
>
> On Thu, Apr 4, 2019 at 12:29 PM Marco de Abreu 
> wrote:
>
> > Hello,
> >
> > I'd like to start a discussion about something that I've noticed being
> > troublesome to maintain in the current version: Backend choices being
> made
> > at compile time.
> >
> > Right now, the different backends and accelerators (CPU, cuda, mkl, AWS
> > elastic inference, (future) AMD, openblas,TVM, etc) are all scattered
> > across the different layers of MXNet. On one hand, we have compile time
> > flags that decide which backends are being compiled into the binary,
> while
> > at the same time choices can be made in the frontend during runtime.
> >
> > At the moment, we have a lot of conditional build logic that picks
> > different parts. With the addition of MKLML and later MKLDNN the clear
> > separation of CPU and GPU got kind of broken up. While we have some
> places
> > where each code lives, in the end we resort to some files containing a
> lot
> > of conditional logic for the different backends (sorry I can't provide
> > links right now since I'm on mobile). To me this seems like a residue of
> > the fast development style from the early days (more processor statement
> > and less object orientation) while also having organic growth with new
> > accelerators. When I see how much AMD had to hack to fit in their
> > implementation, it seemed like we have to make this part more developer
> > friendly.
> >
> > At the moment, every new flavour of MXNet has to be entirely recompiled.
> > This makes it hard for users to figure out which options to use, while it
> > makes it harder for us to test since the overhead to test every single
> > combination of compile parameters would be overwhelming.
> >
> > I'd propose to have a clear class hierarchy based structure for
> > accelerators, operators and memory management. This structure can then be
> > implemented by the different backends. To reduce the compile burden, we
> > would introduce dynamic loading and split the different backends into
> > modules. These could then be developed, maintained and compiled on their
> > own and then placed in a "module" folder to be loaded at runtime. Adding
> a
> > new accelerator would be a matter of placing the precompiled binary into
> > the folder. The detailed configuration of that Backend would then be done
> > on runtime - the user shouldn't worry at the point of downloading mxnet
> > whether they want mkl, MKLDNN, mkl, openblas, atlas, TVM, cuda or what
> ever
> > else there is. I have an idea how we could help the user choosing, but
> > that's outside the scope of this proposal.
> >
> > This would allow us to have a "core" MXNet that takes care of the engine,
> > scheduling, communication and all the other crucial parts. On the other
> > hand we could make MXNet less of a monolith and have clear interfaces.
> This
> > would also act as a forcing function because the different parts wouldn't
> > be intermingled but have to follow the common interface.
> >
> > Of course this comes with the question what these interfaces would look
> > like. For operators, I'd like to propose getting inspiring (or fully
> > adapting) ONNX. For memory management and other Backend specific things
> we
> > could look at the current implementations and find a common ground.
> >
> > Back when I 

Re: assimilation of mshadow into the MXNet codebase

[Tianqi Chen]

Technically, mshadow is sufficient for MXNet. Adopting other libraries (
eigen or xtensor) will unnecessarily increase the codebase complexity
without any additional gains.

Given that mshadow is only used by mxnet. I do support donating it into
mxnet codebase.
To respect the original mshadow community. I would recommend starting a
community RFC In the mshadow github issue for a week, before we start the
migrating process.
Also, I would recommend a rebase merge just like the case of MXNet.jl code
base to preserve the contribution history.

Tianqi


On Fri, Apr 5, 2019 at 9:25 PM Alfredo Luque
 wrote:

> Do you have a link to both of these proposals?
>
> On Fri, Apr 5, 2019 at 20:14 Anirudh Acharya 
> wrote:
>
> > Hi Pedro,
> >
> > mshadow is mostly used for tensor arithmetic. There have been discussions
> > about including it within mxnet. I think it is a good idea.
> >
> > As a more long term solution using libraries like eigen to perform linear
> > algebra operations was also suggested by anirudh2290@. I think xtensor(
> > https://github.com/QuantStack/xtensor ) can also be a candidate here.
> >
> > -
> > Anirudh
> >
> >
> > On Fri, Apr 5, 2019 at 7:03 PM Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> > wrote:
> >
> > > Hi
> > >
> > > Some developers have noticed that working in mshadow is cumbersome as
> > > it's a 3rdparty subrepo.
> > >
> > > Since mshadow is a bunch of headers which don't have much of
> > > independent tests / library functionality, me and other developers
> > > believe that it would be good to assimilate this code in the
> > > repository for ease of contribution and changes without having to go
> > > trough contortions to test PRs that modify mshadow.
> > >
> > > Would anybody oppose this change?
> > >
> > > Thanks and have a nice weekend.
> > >
> > > Pedro.
> > >
> >
>

Re: [MXNET 2.0 Wishlist] [DISCUSS] Single build system

[Tianqi Chen]

I am in favor of using CMake. And I personally think CMake is not something
that has to be introduced in a 2.0. It can simply be part of a minor
release.

Tianqi

On Thu, Apr 4, 2019 at 10:31 AM Kellen Sunderland  wrote:

> Hello MXNet devs,
>
> I'd like to start a thread discussing what our build system should look
> like in MXNet 2.0.  I'd propose that although the current make system has
> served us well in the past, we remove it along with the bump to 2.0.  The
> end goal I'd like to see is that we have a clean build system, without a
> bunch of conditional logic that makes contributing and testing MXNet a
> simpler process.  Additionally I'd propose we target a minimum cmake
> version of 3.7 for reasons described below.
>
> First I'd like to give some context on why I'd propose we don't just switch
> to cmake, but we also target a relatively new version (version 3.7 from
> Nov, 2016) of cmake.  The largest benefits in making this change would
> apply to CUDA builds where cmake itself has quite inconsistent
> functionality between versions.  One persistent annoyance I've had with
> cmake is that we've had conditional logic for the FindCUDA command which at
> one point targeted some modern cmake features, but then in subsequent
> versions of cmake the way these features works was tweaked, and now I find
> these cmake features are consistently broken to the point that I require a
> bunch of -D defines to compile properly or to use an IDE.  An additional
> CUDA related issue is that every time there's a new SM added to NVCC we
> have to make a few source changes to support it.  I could see this being
> problematic for users who may suddenly realize that due to their
> compilation settings, they may not actually be enabling the features they
> think they are with their shiny new GPUs.
>
> As an alternative if we, for example, target cmake 3.7 at a minimum, and we
> want to find cuda and then build a list of reasonable PTX/BINS we could use
> the following command[1]:
>
> 
> FindCUDA(...)
> ...
> CUDA_SELECT_NVCC_ARCH_FLAGS(ARCH_FLAGS 3.0 3.5+PTX 5.2(5.0) Maxwell)
>   LIST(APPEND CUDA_NVCC_FLAGS ${ARCH_FLAGS})
> 
>
> Simple, concise, and it would help to make the building experience more
> consistent across platforms, build environments and IDEs (looking at you
> CLion).  We'd of course need to do a little experimentation work to make
> sure that this does indeed work as intended, and can replace the currently
> complex findCuda logic we have in our build systems, but for the sake of
> the proposal let's assume these cmake commands do indeed work consistently
> as documented from cmake 3.7 onwards.
>
> To give users a chance to update their tooling I'd also suggest we begin
> warning users at least a release in advance that make based builds will be
> deprecated in MXNet 2.0 so they can begin migrating to cmake.  I'd also
> want to display deprecation messages for unused cmake flags (such as the
> profiler flag) for a release before the 2.0 release, and then remove them
> in 2.0.
>
> Of course not all users have cmake 3.7 on their systems, some of our
> employers force use to use ridiculously outdated linux distributions.  The
> good news for these users is that if we can offer Docker compilation with
> an image that has a supported version of cmake and we should be able to
> build a portable binary that work even with very old distributions of
> Linux.  Additionally installing cmake from source is also fairly
> straightforward [2] and works quite well on older distros in my experience.
>
> Looking forward to hearing what others think.  Any preferred build systems
> that you all would want to use?  Is cmake the right system to centralize
> on?  If so, is version 3.7 a reasonable minimum version to target?  Is the
> 2.0 release a good point at which we can think about simplifying build
> logic?
>
> 1: https://cmake.org/cmake/help/v3.7/module/FindCUDA.html
> 2: https://github.com/Kitware/CMake
>

Re: Podling Report Reminder - April 2019

[Tianqi Chen]

It would be great if the PPMC coordinate and prepare the report

On Tue, Apr 2, 2019 at 4:00 PM Hagay Lupesko  wrote:

> Is anyone working on the podling report?
> I'm happy to take care of that if no one else is planning to do it.
>
> Cheers,
> Hagay
>
> On Fri, Mar 29, 2019 at 4:06 PM  wrote:
>
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 17 April 2019, 10:30 am PDT.
> > The report for your podling will form a part of the Incubator PMC
> > report. The Incubator PMC requires your report to be submitted 2 weeks
> > before the board meeting, to allow sufficient time for review and
> > submission (Wed, April 03).
> >
> > Please submit your report with sufficient time to allow the Incubator
> > PMC, and subsequently board members to review and digest. Again, the
> > very latest you should submit your report is 2 weeks prior to the board
> > meeting.
> >
> > Candidate names should not be made public before people are actually
> > elected, so please do not include the names of potential committers or
> > PPMC members in your report.
> >
> > Thanks,
> >
> > The Apache Incubator PMC
> >
> > Submitting your Report
> >
> > --
> >
> > Your report should contain the following:
> >
> > *   Your project name
> > *   A brief description of your project, which assumes no knowledge of
> > the project or necessarily of its field
> > *   A list of the three most important issues to address in the move
> > towards graduation.
> > *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of
> > *   How has the community developed since the last report
> > *   How has the project developed since the last report.
> > *   How does the podling rate their own maturity.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > https://wiki.apache.org/incubator/April2019
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > Mentors
> > ---
> >
> > Mentors should review reports for their project(s) and sign them off on
> > the Incubator wiki page. Signing off reports shows that you are
> > following the project - projects that are not signed may raise alarms
> > for the Incubator PMC.
> >
> > Incubator PMC
> >
>

Re: [DISCUSS] Rebrand Gluon to MXNet imperative or something MXNet.

[Tianqi Chen]

> Today there is a big initiative to publicize MXNet.


It would be great such initiative can be(and should be) brought to dev@..



>
> On Fri, Mar 22, 2019 at 6:08 PM Junru Shao 
> wrote:
>
> > Probably we should figure out how to explain MXNet Gluon to customers. In
> > this case, I agree with @Mu that
> >
> > 1) MXNet Gluon provides high-level API like what Keras gives to
> TensorFlow.
> >
> > 2) MXNet Gluon supports hybridization, which unifies both symbolic and
> > imperative programming style.
> >
> > Also, about toolkits, we could mention
> >
> > 3) GluonNLP and GluonCV are two awesome libraries in their respective
> > domain, both of which are built on MXNet Gluon. They not only provide an
> > awesome exemplary codebase for customers to learn the best way to use
> MXNet
> > Gluon, but also come with the state-of-the-art models and training
> > techniques out-of-the-box.
> >
> > Any other ideas?
> >
> >
> > On Fri, Mar 22, 2019 at 5:54 PM Pedro Larroy <
> pedro.larroy.li...@gmail.com
> > >
> > wrote:
> >
> > > +1 to MXNet Gluon given the feedbacks and explanations from everyone so
> > > far.
> > >
> > > On Fri, Mar 22, 2019 at 5:09 PM Junru Shao 
> > > wrote:
> > > >
> > > > I feel like MXNet Gluon is a good name. You don't lose customers who
> > have
> > > > been familiar with MXNet, nor lose customers who are used to MXNet
> > > symbolic.
> > > >
> > > > On Fri, Mar 22, 2019 at 5:07 PM Davydenko, Denis <
> > > > dzianis.davydze...@gmail.com> wrote:
> > > >
> > > > > As subject suggests this is a proposal for re-branding of Gluon to
> > > align
> > > > > it with MXNet. One of the common things undertaken for re-branding
> > > > > exercises is renaming. That's what my thinking behind suggesting
> new
> > > name
> > > > > for Gluon. I am sincerely curious what would be alternatives to
> > rebrand
> > > > > Gluon to align it with MXNet without changing its name.
> > > > >
> > > > >
> > > > > On 3/22/19, 4:57 PM, "Mu Li"  wrote:
> > > > >
> > > > > Are you proposing to rename Gluon? I think Pedro's opinion is
> > > about a
> > > > > better way to communicate what's Gluon and how it's related to
> > > MXNet.
> > > > >
> > > > > On Fri, Mar 22, 2019 at 4:54 PM Davydenko, Denis
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > I support idea of putting brands of MXNet and Gluon closer
> > > together.
> > > > > I
> > > > > > agree with your argument, Mu, but MXNet is quite far away
> from
> > TF
> > > > > place at
> > > > > > this time so I don’t know how well that argument is
> > transferable
> > > > > from TF
> > > > > > position to MXNet position.
> > > > > >
> > > > > > MXNet Imperative is definitely too restrictive of a name, we
> > can
> > > > > come up
> > > > > > with better one... MXNet-M for example, stands for
> > MXNet-Modified
> > > > > (military
> > > > > > connotation). If naming is the only thing we need to figure
> > out -
> > > > > that is a
> > > > > > good place to be in __
> > > > > >
> > > > > > --
> > > > > > Thanks,
> > > > > > Denis
> > > > > >
> > > > > > On 3/22/19, 4:48 PM, "Mu Li"  wrote:
> > > > > >
> > > > > > Gluon is about imperative neural network training and
> data
> > > > > loading.
> > > > > > ndarray
> > > > > > is another large imperative module. Besides, Gluon also
> > > supports
> > > > > > symbolic
> > > > > > execution after hybridizing.  mxnet imperative might not
> > be a
> > > > > good
> > > > > > name for
> > > > > > it. Another choice is high-level API, that's how TF talks
> > > about
> > > > > Keras.
> > > > > >
> > > > > > On Fri, Mar 22, 2019 at 4:38 PM Yuan Tang <
> > > > > terrytangy...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > On Fri, Mar 22, 2019 at 7:29 PM Lin Yuan <
> > > apefor...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > +1.
> > > > > > > >
> > > > > > > > Just to give some of my real experience:
> > > > > > > > 1) I advertised a recent GluonNLP blog and many
> > > responses are
> > > > > > "This seems
> > > > > > > > nice. So is Gluon a new library to replace MXNet?"
> > > > > > > > 2) We visited customers in a unicorn company who
> showed
> > > > > interests
> > > > > > in
> > > > > > > MXNet
> > > > > > > > but none of the engineers knew the relationship
> between
> > > > > > GluonNLP/GluonCV
> > > > > > > > and MXNet
> > > > > > > > 3) When integrating MXNet to Horovod and adding
> > > examples, I
> > > > > > received
> > > > > > > > comments like "What is Gluon? Is it a new library in
> > > > > addition to
> > > > > > MXNet?"
> > > > > > > >
> > > > > > > > Everyone is talking about PyTorch nowadays, but not
> > > Caffe2
> > > > > anymore
> > > > > > > although
> > > > > 

Re: [DISCUSS] Rebrand Gluon to MXNet imperative or something MXNet.

[Tianqi Chen]

I am not involved in GluonCV/NLP so I cannot speak for the corresponding
community.  I think it is great that GluonCV/NLP as a package has brought
quite a lot of users to MXNet, it is up to the respective community to make
the decision of their branding.

Tianqi

On Fri, Mar 22, 2019 at 6:06 PM Lin Yuan  wrote:

> @Junru Thanks for the clarification. Given that we already have courseware
> and books with Gluon, it makes sense to brand “Mxnet Gluon” with Gluon
> being the high level API of mxnet
>
> @Tianqi what’s the roadmap of GluonNLP/GluonCV? Are they positioned to be
> high level API of MXnet or some plug-and-play components that could
> potentially be put on top of other frameworks in the future? If the former,
> should we always highlight Mxnet whenever we advertise GluonNLP?
>
> Thanks
>
> Lin
>
> On Fri, Mar 22, 2019 at 5:41 PM Tianqi Chen 
> wrote:
>
> > Change the name gluon will result in a significant problem of backward
> > compatibility for many of the current users, and that would be a huge -1
> > for the current community.
> > One possibility is to do that is to have a clear roadmap of 2.0(which
> gives
> > the message of non-backward compatible) and we can discuss which features
> > consolidate, but perhaps that will require a bit more thoughts and
> > coordinated effort.
> >
> > Tianqi
> >
> > On Fri, Mar 22, 2019 at 5:39 PM Junru Shao 
> > wrote:
> >
> > > @Tianqi For sure GluonCV and GluonNLP should go with the current name.
> No
> > > reason to change.
> > >
> > > @Lin If customers are interested, I guess we could say they are awesome
> > > toolkits built on top of MXNet Gluon API, and perfect illustration to
> > write
> > > clever and powerful code on the top of it.
> > >
> >
>

Re: [DISCUSS] Rebrand Gluon to MXNet imperative or something MXNet.

[Tianqi Chen]

Change the name gluon will result in a significant problem of backward
compatibility for many of the current users, and that would be a huge -1
for the current community.
One possibility is to do that is to have a clear roadmap of 2.0(which gives
the message of non-backward compatible) and we can discuss which features
consolidate, but perhaps that will require a bit more thoughts and
coordinated effort.

Tianqi

On Fri, Mar 22, 2019 at 5:39 PM Junru Shao  wrote:

> @Tianqi For sure GluonCV and GluonNLP should go with the current name. No
> reason to change.
>
> @Lin If customers are interested, I guess we could say they are awesome
> toolkits built on top of MXNet Gluon API, and perfect illustration to write
> clever and powerful code on the top of it.
>

Re: [DISCUSS] Rebrand Gluon to MXNet imperative or something MXNet.

[Tianqi Chen]

BTW it would be great if some of the specific user feedback can be found in
public archive, as per Apache principle, so things can be directly referred
to.
It would be great to get some of the customers mentioned in the post onto
the public medium such as the to discuss forum or user list as well.



On Fri, Mar 22, 2019 at 5:18 PM Junru Shao  wrote:

> dev list seems to be reordering my post...To clarify, I am opposed to
> renaming or making it disappear because of potential distraction, but
> suggest using MXNet Gluon instead of Gluon, which looks more aligned.
>
> On Fri, Mar 22, 2019 at 5:08 PM Junru Shao 
> wrote:
>
> > I feel like MXNet Gluon is a good name. You don't lose customers who have
> > been familiar with MXNet, nor lose customers who are used to MXNet
> symbolic.
> >
> > On Fri, Mar 22, 2019 at 5:07 PM Davydenko, Denis <
> > dzianis.davydze...@gmail.com> wrote:
> >
> >> As subject suggests this is a proposal for re-branding of Gluon to align
> >> it with MXNet. One of the common things undertaken for re-branding
> >> exercises is renaming. That's what my thinking behind suggesting new
> name
> >> for Gluon. I am sincerely curious what would be alternatives to rebrand
> >> Gluon to align it with MXNet without changing its name.
> >>
> >>
> >> On 3/22/19, 4:57 PM, "Mu Li"  wrote:
> >>
> >> Are you proposing to rename Gluon? I think Pedro's opinion is about
> a
> >> better way to communicate what's Gluon and how it's related to
> MXNet.
> >>
> >> On Fri, Mar 22, 2019 at 4:54 PM Davydenko, Denis
> >> 
> >> wrote:
> >>
> >> > I support idea of putting brands of MXNet and Gluon closer
> >> together. I
> >> > agree with your argument, Mu, but MXNet is quite far away from TF
> >> place at
> >> > this time so I don’t know how well that argument is transferable
> >> from TF
> >> > position to MXNet position.
> >> >
> >> > MXNet Imperative is definitely too restrictive of a name, we can
> >> come up
> >> > with better one... MXNet-M for example, stands for MXNet-Modified
> >> (military
> >> > connotation). If naming is the only thing we need to figure out -
> >> that is a
> >> > good place to be in __
> >> >
> >> > --
> >> > Thanks,
> >> > Denis
> >> >
> >> > On 3/22/19, 4:48 PM, "Mu Li"  wrote:
> >> >
> >> > Gluon is about imperative neural network training and data
> >> loading.
> >> > ndarray
> >> > is another large imperative module. Besides, Gluon also
> supports
> >> > symbolic
> >> > execution after hybridizing.  mxnet imperative might not be a
> >> good
> >> > name for
> >> > it. Another choice is high-level API, that's how TF talks
> about
> >> Keras.
> >> >
> >> > On Fri, Mar 22, 2019 at 4:38 PM Yuan Tang <
> >> terrytangy...@gmail.com>
> >> > wrote:
> >> >
> >> > > +1
> >> > >
> >> > > On Fri, Mar 22, 2019 at 7:29 PM Lin Yuan <
> apefor...@gmail.com
> >> >
> >> > wrote:
> >> > >
> >> > > > +1.
> >> > > >
> >> > > > Just to give some of my real experience:
> >> > > > 1) I advertised a recent GluonNLP blog and many responses
> >> are
> >> > "This seems
> >> > > > nice. So is Gluon a new library to replace MXNet?"
> >> > > > 2) We visited customers in a unicorn company who showed
> >> interests
> >> > in
> >> > > MXNet
> >> > > > but none of the engineers knew the relationship between
> >> > GluonNLP/GluonCV
> >> > > > and MXNet
> >> > > > 3) When integrating MXNet to Horovod and adding examples,
> I
> >> > received
> >> > > > comments like "What is Gluon? Is it a new library in
> >> addition to
> >> > MXNet?"
> >> > > >
> >> > > > Everyone is talking about PyTorch nowadays, but not Caffe2
> >> anymore
> >> > > although
> >> > > > the latter is still serving as a backend component. Maybe
> we
> >> > should also
> >> > > > doubledown on one brand?
> >> > > >
> >> > > > Lin
> >> > > >
> >> > > > On Fri, Mar 22, 2019 at 4:02 PM Pedro Larroy <
> >> > > pedro.larroy.li...@gmail.com
> >> > > > >
> >> > > > wrote:
> >> > > >
> >> > > > > Hi dev@
> >> > > > >
> >> > > > > We heard feedback from users that the Gluon name is
> >> confusing.
> >> > Some of
> >> > > > > them don't even know it's MXNet and it's unclear the
> >> > relationship with
> >> > > > > MXNet
> >> > > > >
> >> > > > > Would it make sense to rebrand Gluon to just MXNet or
> >> MXNet
> >> > > > > imperative? Diluting brands and names is never a good
> >> idea.
> >> > > > >
> >> > > > > There's also gluonhq which is related to JavaFX which
> >> adds to the
> >> > > > > confusion, search engine friendliness is not high as
> well.
> >> > > > >

Re: [DISCUSS] Rebrand Gluon to MXNet imperative or something MXNet.

[Tianqi Chen]

I think GluonCV and GluonNLP are useful domain specific libraries that
build on top of MXNet. And it is perfectly fine to go with the current
established names.

Tianqi

On Fri, Mar 22, 2019 at 4:57 PM Mu Li  wrote:

> Are you proposing to rename Gluon? I think Pedro's opinion is about a
> better way to communicate what's Gluon and how it's related to MXNet.
>
> On Fri, Mar 22, 2019 at 4:54 PM Davydenko, Denis 
> wrote:
>
> > I support idea of putting brands of MXNet and Gluon closer together. I
> > agree with your argument, Mu, but MXNet is quite far away from TF place
> at
> > this time so I don’t know how well that argument is transferable from TF
> > position to MXNet position.
> >
> > MXNet Imperative is definitely too restrictive of a name, we can come up
> > with better one... MXNet-M for example, stands for MXNet-Modified
> (military
> > connotation). If naming is the only thing we need to figure out - that
> is a
> > good place to be in __
> >
> > --
> > Thanks,
> > Denis
> >
> > On 3/22/19, 4:48 PM, "Mu Li"  wrote:
> >
> > Gluon is about imperative neural network training and data loading.
> > ndarray
> > is another large imperative module. Besides, Gluon also supports
> > symbolic
> > execution after hybridizing.  mxnet imperative might not be a good
> > name for
> > it. Another choice is high-level API, that's how TF talks about
> Keras.
> >
> > On Fri, Mar 22, 2019 at 4:38 PM Yuan Tang 
> > wrote:
> >
> > > +1
> > >
> > > On Fri, Mar 22, 2019 at 7:29 PM Lin Yuan 
> > wrote:
> > >
> > > > +1.
> > > >
> > > > Just to give some of my real experience:
> > > > 1) I advertised a recent GluonNLP blog and many responses are
> > "This seems
> > > > nice. So is Gluon a new library to replace MXNet?"
> > > > 2) We visited customers in a unicorn company who showed interests
> > in
> > > MXNet
> > > > but none of the engineers knew the relationship between
> > GluonNLP/GluonCV
> > > > and MXNet
> > > > 3) When integrating MXNet to Horovod and adding examples, I
> > received
> > > > comments like "What is Gluon? Is it a new library in addition to
> > MXNet?"
> > > >
> > > > Everyone is talking about PyTorch nowadays, but not Caffe2
> anymore
> > > although
> > > > the latter is still serving as a backend component. Maybe we
> > should also
> > > > doubledown on one brand?
> > > >
> > > > Lin
> > > >
> > > > On Fri, Mar 22, 2019 at 4:02 PM Pedro Larroy <
> > > pedro.larroy.li...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi dev@
> > > > >
> > > > > We heard feedback from users that the Gluon name is confusing.
> > Some of
> > > > > them don't even know it's MXNet and it's unclear the
> > relationship with
> > > > > MXNet
> > > > >
> > > > > Would it make sense to rebrand Gluon to just MXNet or MXNet
> > > > > imperative? Diluting brands and names is never a good idea.
> > > > >
> > > > > There's also gluonhq which is related to JavaFX which adds to
> the
> > > > > confusion, search engine friendliness is not high as well.
> > > > >
> > > > > Pedro.
> > > > >
> > > >
> > >
> >
> >
> >
>

Re: Call for Ideas and Approaches to Community Building

[Tianqi Chen]

what happens (also) happens in the mail-list.

If there is a certain things or person’s contribution is only known by
colleagues, it is a indication of things that should be improved toward
more apache way.

Tianqi

On Thu, Mar 7, 2019 at 4:42 AM Isabel Drost-Fromm  wrote:

> On Wed, Mar 06, 2019 at 10:03:57PM -0800, Steffen Rochel wrote:
> > I agree with Tianqi on "One approach toward building a more diverse
> > community is to acknowledge the fact that we want to encourage
> interactions
> > in the Apache way beyond our physical cycle." However, I disagree with
> his
> > suggestion regarding "One principle to toward that is to encourage PMC
> > members only nominate committers from other organizations" for the
> > following reasons: [...]
>
> I spent quite some time digging remembering that a similar topic had been
> discussed somewhere at the ASF at some point in time with many whys, pros
> and
> cons towards contributor employer diversity - finally found a long and
> winding
> thread there:
>
>
> https://lists.apache.org/thread.html/7a7412316ddbe1d43f5fb3d3703ea25a6b26e56de602e27e175785c0@1337815698@%3Cgeneral.incubator.apache.org%3E
>
>
> There is one answer in there from Roy Fielding which has a similar story
> to the
> one that you are describing, Steffen. My main takeaway of what was
> discussed
> back then: "Diversity is only a warning sign that means we need to check
> for
> decisions made in our forums and advise accordingly."
>
> The questions I personally tend to ask myself: How easy is it to follow the
> project from just subscribing to it's mailing lists (remember the "if it
> didn't
> happen on the mailing list, it didn't happen"), get active, get involved,
> be
> treated as a fellow project member and be voted in as committer and PMC
> member.
>
> For a more condensed text on the topic of "ASF projects are made of
> individuals"
> you might also want to check out the ASF guidelines over there:
> https://www.confluent.io/apache-engineering-guidelines/
> https://www.confluent.io/apache-guidelines
>
> Related material was published at ApacheCon :
> https://www.youtube.com/watch?v=uFNE0IpKOxU
>
> There's also lovely content that was recently produced over at
> dev@community:
>
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.g4a86a2ca5a_0_69
>
>
> Isabel
>
>

Re: Call for Ideas and Approaches to Community Building

[Tianqi Chen]

It is important for a contribution to be visible publically, and being able
to get identifications from PMC members  that you do not interact daily is
a way to do that.

It also boils down to the trust, on whether fellow PMC members think it is
appropriate to entrust others to do the nomination. I personally would love
to collaborate with my fellow PMC members, and in the case that I was not
trusted, refrain from doing things

Anyway, as I said, I just want to share this way of positive community
building, and see what the community thinks

Tianqi

On Wed, Mar 6, 2019 at 12:15 PM Anirudh Acharya 
wrote:

> Having only non-organization PMC members nominate new committers could
> un-level the playing field.
> 1. Many times contributions might not require a contributor to have direct
> 1:1 discussion with PMC members outside his org.
> 2. It would give inordinate power/responsibility to the few non-Amazon
> active PMC members.
>
> Just my 2 cents.
>
>
> Thanks
> Anirudh
>
> On Wed, Mar 6, 2019 at 7:10 AM Isabel Drost-Fromm 
> wrote:
>
> >
> >
> > Am 2. März 2019 15:13:23 MEZ schrieb Carin Meier :
> > >I wanted to kickoff a discussion about community building. There was an
> > >excellent blog post from the Apache Beam Community on this
> > >https://blogs.apache.org/comdev/entry/an-approach-to-community-building
> >
> > Needless to say I really love that blog post.
> >
> > Other than that there are a couple of question you might ask yourself as
> a
> > community:
> >
> > How easy is it to patriciate as an outsider, how much communication is
> > happening outside of dev@?
> >
> > How explicit are you about how inclusive you want to be? See also
> > https://youtu.be/LgB1s3buccI
> >
> > How explicit are you about where you need help (including and beyond
> > coding)?
> >
> > How explicit are you with downstream users that some of the inner
> workings
> > of Apache projects are build around a scratch your own itch casual
> > contributions that ideally should be rewarded the same way as full-time
> > contributions (
> > https://blogs.apache.org/foundation/entry/success-at-apache-for-love )?
> >
> > I think you want to enable as many ppl as possible - typically only ten
> > percent of your users turn into contributor, of those only ten percent
> > trend to be repeat contributors... at least in my experience.
> >
> > Just some ideas,
> > Isabel
> > --
> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >
>

Re: Call for Ideas and Approaches to Community Building

[Tianqi Chen]

Thanks, Carin for bringing this topic up.

I have suggested this several times. But would like to do it again. One
approach toward building a more diverse community is to acknowledge the
fact that we want to encourage interactions in the Apache way beyond our
physical cycle.

One principle to toward that is to encourage PMC members only nominate
committers from other organizations, so it encourages interactions and
gives incentives overall for general participation. This way does not
prevent people from getting nominated (The PMC member who is non-colleague
will nominate the person with merit), and also encourage broad
participation (I can tell my fellows to participate in community discussion
because it is really up to other PMC members to propose them). Of course,
this requires some trust in the community toward positive community
building, which may or may not doable here. But nevertheless, I think it is
a good principle.

Tianqi

On Sat, Mar 2, 2019 at 9:13 AM Carin Meier  wrote:

> I wanted to kickoff a discussion about community building. There was an
> excellent blog post from the Apache Beam Community on this
> https://blogs.apache.org/comdev/entry/an-approach-to-community-building
>
> In it they wanted to improve their contributor/committer base in the
> following ways which resonate with our project as well, quoting from the
> article:
>
> 
> 1. We could use more committers to review all the code being contributed,
> in part due to recent departure of a few committers
>
> 2. We want our contributor-base (hence committer-base) to be more spread
> across companies and backgrounds. This is a core value of the Apache
> Software Foundation. In particular, the project's direction should not be
> dominated by any company, and the project should be able to survive the
> departure of a major contributor or all contributors from a particular
> employer. Eventually, we hope that our user base is active and diverse
> enough that this happens naturally. But we are not there yet, so instead we
> have to work hard to build our community around the software we already
> have.
> 
>
>
> They outlined some of the steps that they took to achieve positive results
> in the article, which I encourage everyone to read.
>
> Every community is different, however, so things that worked well in their
> community might not be as effective as in ours. I wanted to kick off a
> discussion for ideas that people had here on community building for MXNet.
>
> Ideas and thoughts on this are most welcome.
>
> - Carin
>

[Announcement] New Committer -- Lin Yuan

[Tianqi Chen]

Dear Community:

Please join me to welcome Lin Yuan(@apeforest) as a new committer of
Apache(incubating) MXNet!

He has contributed to various improvements, including better compatibility
of larger arrays across the codebase.

Commits: https://github.com/apache/incubator-mxnet/commits?author=apeforest
https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+author%3Aapeforest


Reviews:
https://github.com/apache/incubator-mxnet/pulls?utf8=%
E2%9C%93=reviewed-by%3Aapeforest

dev@ activitivity
https://lists.apache.org/list.html?*@mxnet.apache.org:lte=6M:Lin%20Yuan

Tianqi

Re: Proposal for a recurrent architecture meeting and long term direction

[Tianqi Chen]

Hi Pedro:

Can you give a summary of takeaways, and possible decision proposal that
might affect the technical directions?

Thanks!
Tianqi

On Sat, Jan 19, 2019 at 7:36 AM Pedro Larroy 
wrote:

> Hi Isabel. We talked with Timur about graphcore accelerators, and
> seems other people also missed the meeting.
>
> For next meeting I will send an agenda of topics to discuss in advance.
>
> Thanks.
>
> Pedro.
>
> On Thu, Jan 17, 2019 at 2:43 PM Isabel Drost-Fromm 
> wrote:
> >
> > On Mon, Jan 14, 2019 at 08:03:42PM +0100, Pedro Larroy wrote:
> > > If you wish to join the monthly architecture meeting today, please
> > > join the hangout below:
> > >
> > > https://hangouts.google.com/call/ZXXqJ0ZL5m_dcHOVIeTcAEEE
> >
> > Likely I've missed the mail - can you point me to the summary of the
> above
> > meeting?
> >
> >
> > Isabel
>

Re: Order of includes in cpplint

[Tianqi Chen]

I think this is a nit and it is hard to argue which one is best, everyone
has their own preference.
In this case, Google C style is a simple convention that everyone can refer
to, and I would suggest we just stick with that convention

Tianqi

On Tue, Jan 8, 2019 at 2:44 PM Pedro Larroy 
wrote:

> Hi MXNet community
>
> cpplint seems to complain when the order of includes is not  [own,
> system, other]
>
> But the general best practice in C++ is [own, project, 3rd party,
> system] for the reasons explained in this stackoverflow answer:  (
> https://stackoverflow.com/questions/614302/c-header-order )
>
> A contribution to cpplint could be made to make this configurable:
>
> https://github.com/cpplint/cpplint/blob/master/cpplint.py#L605
>
> Thoughts?
>
> Pedro.
>

Re: Order of includes in cpplint

[Tianqi Chen]

On Tue, Jan 8, 2019 at 2:44 PM Pedro Larroy 
wrote:

> Hi MXNet community
>
> cpplint seems to complain when the order of includes is not  [own,
> system, other]
>
> But the general best practice in C++ is [own, project, 3rd party,
> system] for the reasons explained in this stackoverflow answer:  (
> https://stackoverflow.com/questions/614302/c-header-order )
>
> A contribution to cpplint could be made to make this configurable:
>
> https://github.com/cpplint/cpplint/blob/master/cpplint.py#L605
>
> Thoughts?
>
> Pedro.
>

Re: [Annoucement] New Committer -- Iblis Lin

[Tianqi Chen]

Welcome Iblis! Thank you for making MXNet.jl awesome.

Tianqi

On Mon, Jan 7, 2019 at 9:47 AM Chiyuan Zhang  wrote:

> Welcome Iblis! Thank you very much for your hard work and continuous
> efforts on the Julia branch lately!
>
> Best,
> Chiyuan
>
> On Sat, Jan 5, 2019 at 12:13 PM Carin Meier  wrote:
>
> > Please join me in welcoming Iblis Lin as a new committer.
> >
> > He has been a long time contributor to the Julia package, is responsible
> > for bringing into the main MXNet repo, and is the current maintainer.
> >
> > https://github.com/apache/incubator-mxnet/commits?author=iblis17
> >
> > - Carin Meier
> >
>

[Annoucement] New Committer -- Da Zheng

[Tianqi Chen]

Dear Community:

Please join me to welcome Da Zheng as a new committer of the MXNet.

Da is the main author of MKL-DNN integration and recently he champions the
control flow support. He is one of the few "explorer style" contributors of
the community, who we desperately need in this fast change environment of
the deep learning system landscape.

PRs https://github.com/apache/incubator-mxnet/commits?author=zheng-da
reviews  
*https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+reviewed-by%3Azheng-da+
*
dev@  https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=3y:da-
zheng

Tianqi

Re: Proposal for a recurrent architecture meeting and long term direction

[Tianqi Chen]

I feel that online meeting may not address most of the issues get raised in
a short amount of time(1h) and still suffers the problem of not being
publically archivable.

Maybe we can not try more asynchronous way? (RFC discussion in issues.
and/or discuss @dev). Just my two cents and I am not blocking the proposal

Tianqi


On Fri, Dec 14, 2018 at 5:34 AM Pedro Larroy 
wrote:

> Hi MXNetters
>
> To address the project growth and increased contributions I'm
> proposing a monthly meeting / hangout to have community discussions
> about MXNet architecture and mid / longer term technical directions
> that require coordination beyond single PRs.
>
> TOPICS:
>
> The goal of this series is to address topics including but not limited to:
>  - How to best integrate features that have a big impact on the project
>  - Discussion about long term technical direction
>  - Addressing of technical debt / refactoring needed.
>  - Other architectures / framework support. Ex. ARM, Cuda etc.
>  - Build system improvements and tooling such as code coverage, static
> analysis etc.
>  - Performance discussions.
>  - Live discussion to address exceptional PRs with complex changes
> that are better discussed live than in written form.
>
> FREQUENCY:
>
> I propose to make this meeting on the second Monday of the month at
> 11am PST /  20pm CET
>
> So the tentative date for the first one would be on January 14th.
>
> If you think this arbitrary date is not good, please say so. In this
> case we can proceed to make a doodle to find a slot that works for the
> interested parties.
>
> I have opened a group calendar for our meetings, hangouts and other
> events related to MXNet.
>
>
> https://calendar.google.com/calendar/embed?src=6co88bqo3n4bjsbt1qrqmsvj4o%40group.calendar.google.com
>
> Pedro.
>

Re: [DISCUSS] About the PR merging policy

[Tianqi Chen]

I think it is fine as long as we act on good faith. I will normally respect
code review comments from anyone who might be able to give reasonable
comments, and beg to differ with good technical reasoning. Normally
contributions happen in a way that things won't get blocked in small
features.

For major changes, RFC discussion would be  helpful to resolve the case

Tianqi

On Tue, Dec 11, 2018 at 4:18 PM Qing Lan  wrote:

> Hi all,
>
> Recently I self-merged my PR without getting approvals from other
> committers https://github.com/apache/incubator-mxnet/pull/13617 and only
> contributors approval. I apologize to the community and thank Marco for
> pointing out the problem. I took a lesson that we should at least have one
> committer’s approval to merge the code. However, I just found this section
> is missing in the CWiki
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member.
> So I would like to discuss in here:
>
> How to conduct the PR reviewing/merging. How many approvals (Committers
> and Contributors) we should get in order to merge?
>
> How to deal with disagreement in the discussion (e.g a
> contributor/committer request a change)?
>
> Please don’t hesitate to share your thoughts!
>
> Thanks,
> Qing
>

[Announcement] New Committer -- Rahul Huilgol

[Tianqi Chen]

Let us welcome Rahul Huilgol as a new Committer of MXNet. He has
contributed to many fronts, including the FP16 support, distributed
training and mixed precision support of MXNet. He has a breadth of
knowledge across multiple modules of the system and would be valuable
member of the committer team

PRs https://github.com/apache/incubator-mxnet/commits?author=rahul003
Reviews
https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+reviewed-by%3Arahul003
dev@
https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=3y:rahul003


Tianqi

[Announcement] New Committer -- Aaron Markham

[Tianqi Chen]

Let us welcome Aron Markham as a new committer of MXNet. Aaron has been
actively working on improving documents and website of MXNet
PRs  
*https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+reviewed-by%3Aaaronmarkham
*
reviews  
*https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+reviewed-by%3Aaaronmarkham+
*
dev@  https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=3y:

*aaronmarkham*

Tianqi

Re: Adding AMD CPU to CI

[Tianqi Chen]

+1 for nightly for pre-release suit, but not the CI that triggered in every
test.  The best engineering practice is not to add things, but to remove
things so that there is nothing can be removed.

In terms of MLDNN, since it is an Intel product, I doubt optimizing for AMD
CPUs is its goal, adding CI to guard against backward compatibility is a
bit overkill even. Since the AMD CPU user would likely disable this feature
and use the original CPU version of the project.

At least we can contribute to reducing the carbon footprint and slows down
the global warming :)

Tianqi

On Fri, Nov 30, 2018 at 9:38 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Regarding cost, yes we could run this nightly or simply make it run an
> existing test suite that would make sense rather than having it duplicate a
> suite.
>
> On Fri, Nov 30, 2018 at 9:26 AM Kumar, Vikas 
> wrote:
>
> > I don't think there is any downside to this proposal. I think a basic
> > sanity CI testing on AMD processors will give extra boost to our tests.
> > This adds to developer productivity and they have one less thing to worry
> > about. Developers have spent time in past where they had to manually test
> > on AMD  processors, MKLDNN being the recent instance. It's good to have
> > those test in CI pipeline.
> > All I see is benefit. If the $ cost is not too high for basic sanity
> > testing, we should do this, until and unless some strong downside is
> called
> > out.
> >
> > +1
> >
> >
> > On 11/29/18, 5:37 PM, "Anirudh Subramanian" 
> > wrote:
> >
> > Instruction set extensions support like AVX2, AVX512 etc. can vary
> > between
> > AMD and Intel and there can also be a time lag between when Intel
> > supports
> > it versus when AMD supports it.
> > Also, in the future this setup may be useful in case MXNet supports
> AMD
> > GPUs and AWS also happens to have support for it.
> >
> > Anirudh
> >
> >
> > On Thu, Nov 29, 2018 at 4:29 PM Marco de Abreu
> >  wrote:
> >
> > > I think it's worth a discussion to do a sanity check. While
> > generally these
> > > instructions are standardized, we also made the experience with ARM
> > that
> > > the theory and reality sometimes don't match. Thus, it's always
> good
> > to
> > > check.
> > >
> > > In the next months we are going to refactor our slave creation
> > processes.
> > > Chance Bair has been working on rewriting Windows slaves from
> > scratch (we
> > > used images that haven't really been updated for 2 years - we still
> > don't
> > > know what was done on them) and they're ready soon. In the
> following
> > > months, we will also port our Ubuntu slaves to the new method
> (don't
> > have a
> > > timeline yet). Ideally, the integration of AMD instances will only
> > be a
> > > matter of running the same pipeline on a different instance type.
> In
> > that
> > > Case, it should not be a big deal.
> > >
> > > If there are big differences, that's already a yellow flag for
> > > compatibility, but that's unlikely. But in that case, we would have
> > to make
> > > a more thorough time analysis and whether it's worth the effort.
> > Maybe,
> > > somebody else could also lend us a hand and help us with adding AMD
> > > support.
> > >
> > > -Marco
> > >
> > > Am Fr., 30. Nov. 2018, 01:22 hat Hao Jin 
> > > geschrieben:
> > >
> > > > f16c is also an instruction set supported by both brands' recent
> > CPUs
> > > just
> > > > like x86, AVX, SSE etc., and any difference in behaviors (quite
> > > impossible
> > > > to happen or it will be a major defect) would most likely be
> > caused by
> > > the
> > > > underlying hardware implementation, so still, adding AMD
> instances
> > is not
> > > > adding much value here.
> > > > Hao
> > > >
> > > > On Thu, Nov 29, 2018 at 7:03 PM kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > > > Just looked at the mf16c work and wanted to mention Rahul
> > clearly _was_
> > > > > thinking about AMD users in that PR.
> > > > >
> > > > > On Thu, Nov 29, 2018 at 3:46 PM kellen sunderland <
> > > > > kellen.sunderl...@gmail.com> wrote:
> > > > >
> > > > > > From my perspective we're developing a few features like
> mf16c
> > and
> > > > MKLDNN
> > > > > > integration specifically for Intel CPUs.  It wouldn't hurt to
> > make
> > > sure
> > > > > > those changes also run properly on AMD cpus.
> > > > > >
> > > > > > On Thu, Nov 29, 2018, 3:38 PM Hao Jin  > wrote:
> > > > > >
> > > > > >> I'm a bit confused about why we need extra functionality
> > tests just
> > > > for
> > > > > >> AMD
> > > > > >> CPUs, aren't AMD CPUs supporting roughly the same
> instruction
> > sets
> > > as
> > > > > the
> > > > > >> Intel ones? In the very impossible case that something
> > working 

Re: Adding AMD CPU to CI

[Tianqi Chen]

I still think it is overkill to add AMD CPU to the CI, given the additional
cost it could bring and little additional information we can get out from
it.

A middle group is to add AMD CPU to a nightly build or final sweep before
release. If there is a case that we find that AMD CPU really makes a
difference, then we add it to the CI

Tianqi

On Thu, Nov 29, 2018 at 6:29 PM Hao Jin  wrote:

> For CPUs, the supported instruction sets may also vary between the same
> manufacturer's different product lines of the same generation (Skylake-SP
> versus Skylake).
> For the same instruction set, the two manufacturers should both have a
> working version of the hardware implementation. If any of the
> implementations does not work, then the chip would not even be considered
> functioning properly.
> If some AMD CPUs only support up to AVX2 instruction sets, they would just
> function in the same way as an Intel CPU that supports up to AVX2
> instruction sets. The performance may vary, but the capability and behavior
> of the two chips would be the same when given the same machine code.
> For AMD GPUs it's a totally different story, as AMD GPUs do not share the
> same instruction sets with the NVIDIA ones, thus testing on AMD GPUs(if we
> do have support for them) would definitely add values.
> Hao
>
> On Thu, Nov 29, 2018 at 8:37 PM Anirudh Subramanian  >
> wrote:
>
> > Instruction set extensions support like AVX2, AVX512 etc. can vary
> between
> > AMD and Intel and there can also be a time lag between when Intel
> supports
> > it versus when AMD supports it.
> > Also, in the future this setup may be useful in case MXNet supports AMD
> > GPUs and AWS also happens to have support for it.
> >
> > Anirudh
> >
> >
> > On Thu, Nov 29, 2018 at 4:29 PM Marco de Abreu
> >  wrote:
> >
> > > I think it's worth a discussion to do a sanity check. While generally
> > these
> > > instructions are standardized, we also made the experience with ARM
> that
> > > the theory and reality sometimes don't match. Thus, it's always good to
> > > check.
> > >
> > > In the next months we are going to refactor our slave creation
> processes.
> > > Chance Bair has been working on rewriting Windows slaves from scratch
> (we
> > > used images that haven't really been updated for 2 years - we still
> don't
> > > know what was done on them) and they're ready soon. In the following
> > > months, we will also port our Ubuntu slaves to the new method (don't
> > have a
> > > timeline yet). Ideally, the integration of AMD instances will only be a
> > > matter of running the same pipeline on a different instance type. In
> that
> > > Case, it should not be a big deal.
> > >
> > > If there are big differences, that's already a yellow flag for
> > > compatibility, but that's unlikely. But in that case, we would have to
> > make
> > > a more thorough time analysis and whether it's worth the effort. Maybe,
> > > somebody else could also lend us a hand and help us with adding AMD
> > > support.
> > >
> > > -Marco
> > >
> > > Am Fr., 30. Nov. 2018, 01:22 hat Hao Jin 
> > > geschrieben:
> > >
> > > > f16c is also an instruction set supported by both brands' recent CPUs
> > > just
> > > > like x86, AVX, SSE etc., and any difference in behaviors (quite
> > > impossible
> > > > to happen or it will be a major defect) would most likely be caused
> by
> > > the
> > > > underlying hardware implementation, so still, adding AMD instances is
> > not
> > > > adding much value here.
> > > > Hao
> > > >
> > > > On Thu, Nov 29, 2018 at 7:03 PM kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > > > Just looked at the mf16c work and wanted to mention Rahul clearly
> > _was_
> > > > > thinking about AMD users in that PR.
> > > > >
> > > > > On Thu, Nov 29, 2018 at 3:46 PM kellen sunderland <
> > > > > kellen.sunderl...@gmail.com> wrote:
> > > > >
> > > > > > From my perspective we're developing a few features like mf16c
> and
> > > > MKLDNN
> > > > > > integration specifically for Intel CPUs.  It wouldn't hurt to
> make
> > > sure
> > > > > > those changes also run properly on AMD cpus.
> > > > > >
> > > > > > On Thu, Nov 29, 2018, 3:38 PM Hao Jin  wrote:
> > > > > >
> > > > > >> I'm a bit confused about why we need extra functionality tests
> > just
> > > > for
> > > > > >> AMD
> > > > > >> CPUs, aren't AMD CPUs supporting roughly the same instruction
> sets
> > > as
> > > > > the
> > > > > >> Intel ones? In the very impossible case that something working
> on
> > > > Intel
> > > > > >> CPUs being not functioning on AMD CPUs (or vice versa), it would
> > > > mostly
> > > > > >> likely be related to the underlying hardware implementation of
> the
> > > > same
> > > > > >> ISA, to which we definitely do not have a good solution. So I
> > don't
> > > > > think
> > > > > >> performing extra tests on functional aspect of the system on AMD
> > > CPUs
> > > > is
> > > > > >> adding any values.
> > > > > >> Hao
> > > > > >>
> > > > > >> On Thu, Nov 29, 

Re: Adding AMD CPU to CI

[Tianqi Chen]

I am not sure if it is necessary, as AMD CPU also supports x86, and it
would not add additional information

Tianqi

On Thu, Nov 29, 2018 at 3:35 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> +1
>
> On Thu, Nov 29, 2018 at 2:50 PM Seth, Manu 
> wrote:
>
> > +1
> >
> > On 11/29/18, 2:39 PM, "Alex Zai"  wrote:
> >
> > What are people's thoughts on having AMD machines tested on the CI?
> AMD
> > machines are now available on AWS.
> >
> > Best,
> > Alex
> >
> >
> >
>

Re: You've been removed from the The Apache Software Foundation team mxnet committers

[Tianqi Chen]

Hmm, this does not sound right. I have no idea what is going on. As far as
I know, only apache infra have the admin right to the org. You are still in
the roster https://whimsy.apache.org/roster/ppmc/mxnet

Tianqi

On Thu, Nov 29, 2018 at 2:45 PM Sergey Kolychev <
sergeykolychev.git...@gmail.com> wrote:

> Hello there,
> Could please any mentors help me understand why this happened and how to
> revert this change ?
> Thanks in advance.
> I'm in process of helping to release 1.4.0 version of MXNet and it likely
> relate to the release branch I created and pushed today.
> -- Forwarded message -
> From: The Apache Software Foundation 
> Date: Thu, Nov 29, 2018 at 2:31 PM
> Subject: You've been removed from the The Apache Software Foundation team
> mxnet committers
> To: Sergey Kolychev 
>
>
> You’ve been removed from the mxnet committers team on the The Apache
> Software Foundation organization.
>
> Cheers & Octocats,
> GitHub Support
>

Re: Redesign of the MXNet document site

[Tianqi Chen]

I like the conciseness of the new website. Thanks, Mu and Aron for bringing
this

Tianqi

On Mon, Nov 26, 2018 at 11:56 AM Mu Li  wrote:

> Dear Community,
>
> I have been working with several Amazon folks in the past few weeks for a
> major update of the document website. Now we have a minimal demo at
> https://beta.mxnet.io/ and would like to ask for feedback.
>
> What's new:
>
> 1. A new theme based on the material design that looks modern
> 2. Re-orged all tutorials and APIs.
> 3. All tutorials are notebooks that are evaluated during building.
> 4. Each API has a separate page
> 5. Enabled disqus in almost every page to make comment easier.
>
> Please check this page 
> for more details.
>
> In addition, to accelerate developing, I created a separate repo for it and
> enabled a CI. You can check the roadmap
>  for the progress when it can
> be merged back into MXNet.
>
> Please note that there are a bunch of tutorials haven't ported from the
> original site yet, and the API section also has a lot of TODOs. I guess it
> will last for a few months. But I would like to ask suggestions earlier for
> 1) how to improve the current content organization, 2) how to simplify the
> process to find information, and 3) how we can improve the current theme.
>
> Please check the demo at https://beta.mxnet.io/, the github repo is at
> https://github.com/mli/new-docs. You can reply to this thread for
> suggestions or just leave comments at the bottom of each page.
>
> Thank you
> Mu
>

[Anouncement] New Committer: Kellen Sunderland

[Tianqi Chen]

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
https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+reviewed-by%3AKellenSunderland
dev@  https://lists.apache.org/list.html?d...@mxnet.apache.org:lte=3y:Kellen
%20Sunderland

Please join me to welcome Kellen to the team!

Tianqi
- On behalf of Apache MXNet(incubating) PMC

Re: [VOTE] Separating PMC and Committership

[Tianqi Chen]

+1

On Mon, Nov 5, 2018 at 8:29 AM Carin Meier  wrote:

> This is a procedural vote on whether to separate the committer and PPMC
> levels in the project. The current state is that a user is considered as
> both a committer and a PPMC member at the same time. This vote is to change
> that to be able to invite a person in as a committer separately from a PPMC
> member.
>
> Document reference:
>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
>
> Discussion thread:
>
> https://lists.apache.org/thread.html/9c6ecda02e081aa6b689c92badc9dcf05ced6fb3691fd370471773d1@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
>  for a
> modifying factor.)
>
> The vote will run until Friday Nov 9th at 6:00 am EST
>
> Thanks,
> Carin
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Tianqi Chen]

Also from https://www.apache.org/foundation/how-it-works.html there is no
mention of the word "privileges", maybe "right" is a better term.

I feel there is some wisdom in choose not to emphasize the entitlements
being given in the role. After all, the PMC/committership is given by the
community, and the main job of PMC/committer is to use the power serve the
community well. And we should choose wisely as our actions have
consequences, and the community is watching

Tianqi

On Mon, Oct 29, 2018 at 10:03 PM Tianqi Chen  wrote:

> As far as I recall from what Jim said
>
> "The ASF strives for consensus, and votes and voting are used, primarily,
> to gauge that. It's not used to divide a community; it's used to UNITE it.
> Voting is used when collaboration and consensus building *FAILS*. It should
> be rare."
>
> In this context, we all agree that when a veto vote occurs everyone should
> respect it and not kick a dead horse.  On the other hand, the
> PMC/committers should be cautious when using this power, as the community
> should always encourage reach consensus via reasonable technical discussion
> first.
>
> As with all the ML models, every guideline can be interpreted in an
> adversarial fashion but I hope we can have a goodwill to build toward a
> positive sum collaboration.
>
> Tianqi
>
>
>
> On Mon, Oct 29, 2018 at 9:01 PM Naveen Swamy  wrote:
>
>> The committer/PMC privileges is derived from
>> https://www.apache.org/foundation/how-it-works.html.
>>
>> The term abuse is very subjective (in this case) - If an opinion or Vote
>> is
>> against something they prefer, it can be termed as Abuse. I would expect
>> those who differ with the vote to take that as feedback, if there are
>> corrections to be made in the understanding, they respectfully clarify
>> that
>> misunderstanding.
>>
>> I agree with Chris, we have seen in the past where discussions have gone
>> on
>> and on for a long time when there were disagreements until people gave up,
>> This leads to frustration and less participation by members - this is also
>> an ultimate productivity killer. You can see why some of the discuss
>> threads go quiet and die.
>>
>> I am all for discussion and reaching consensus but at some point one must
>> realize its just kicking a dead horse and turns into an endurance contest
>> rather than a discussion. We should be careful on the expectations we set
>> in regard to how we reach consensus.
>>
>>
>> On Mon, Oct 29, 2018 at 6:18 PM Chris Olivier 
>> wrote:
>>
>> > well, if something needs consensus to pass, then saying “you need to
>> keep
>> > discussing until consensus is reached” seems like it could be abused by
>> > someone who was just willing to not accept a verdict and continues to
>> push,
>> > right? And if someone were to walk away saying “I don’t want to discuss
>> > this any further”, which is fair in that situation, then they’re the
>> “bad
>> > guy”? While it sounds like a noble persuit, I just feel like this could
>> be
>> > abused.
>> >
>> > On Mon, Oct 29, 2018 at 5:53 PM Carin Meier 
>> wrote:
>> >
>> > > Chris,
>> > >
>> > > Is there are rewording that you would find more acceptable? Again, we
>> can
>> > > have more time to edit and revise the document. There is not a time
>> limit
>> > > on this. I might have been too hasty to start the vote thinking the
>> > > discussion was wrapped up.
>> > >
>> > > - Carin
>> > >
>> > > On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier 
>> > > wrote:
>> > >
>> > > > or another example if something is downvoted, this also implies that
>> > > after
>> > > > a vote is over, it’s approprorate to continue pushing the subject
>> > trying
>> > > to
>> > > > just wear everyone down even though the outcome is clear. We’ve seen
>> > this
>> > > > before, actually.
>> > > >
>> > > > On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier <
>> cjolivie...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > -1 “strive to meet consensus”? This seems to imply the consensus
>> is
>> > the
>> > > > > natural expected state. So in the case where someone submits that
>> we
>> > > > should
>> > > > > start a nuclear war, then our bylaws would state that we should
>> all
>> > try
>&g

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Tianqi Chen]

As far as I recall from what Jim said

"The ASF strives for consensus, and votes and voting are used, primarily,
to gauge that. It's not used to divide a community; it's used to UNITE it.
Voting is used when collaboration and consensus building *FAILS*. It should
be rare."

In this context, we all agree that when a veto vote occurs everyone should
respect it and not kick a dead horse.  On the other hand, the
PMC/committers should be cautious when using this power, as the community
should always encourage reach consensus via reasonable technical discussion
first.

As with all the ML models, every guideline can be interpreted in an
adversarial fashion but I hope we can have a goodwill to build toward a
positive sum collaboration.

Tianqi



On Mon, Oct 29, 2018 at 9:01 PM Naveen Swamy  wrote:

> The committer/PMC privileges is derived from
> https://www.apache.org/foundation/how-it-works.html.
>
> The term abuse is very subjective (in this case) - If an opinion or Vote is
> against something they prefer, it can be termed as Abuse. I would expect
> those who differ with the vote to take that as feedback, if there are
> corrections to be made in the understanding, they respectfully clarify that
> misunderstanding.
>
> I agree with Chris, we have seen in the past where discussions have gone on
> and on for a long time when there were disagreements until people gave up,
> This leads to frustration and less participation by members - this is also
> an ultimate productivity killer. You can see why some of the discuss
> threads go quiet and die.
>
> I am all for discussion and reaching consensus but at some point one must
> realize its just kicking a dead horse and turns into an endurance contest
> rather than a discussion. We should be careful on the expectations we set
> in regard to how we reach consensus.
>
>
> On Mon, Oct 29, 2018 at 6:18 PM Chris Olivier 
> wrote:
>
> > well, if something needs consensus to pass, then saying “you need to keep
> > discussing until consensus is reached” seems like it could be abused by
> > someone who was just willing to not accept a verdict and continues to
> push,
> > right? And if someone were to walk away saying “I don’t want to discuss
> > this any further”, which is fair in that situation, then they’re the “bad
> > guy”? While it sounds like a noble persuit, I just feel like this could
> be
> > abused.
> >
> > On Mon, Oct 29, 2018 at 5:53 PM Carin Meier 
> wrote:
> >
> > > Chris,
> > >
> > > Is there are rewording that you would find more acceptable? Again, we
> can
> > > have more time to edit and revise the document. There is not a time
> limit
> > > on this. I might have been too hasty to start the vote thinking the
> > > discussion was wrapped up.
> > >
> > > - Carin
> > >
> > > On Mon, Oct 29, 2018 at 8:50 PM Chris Olivier 
> > > wrote:
> > >
> > > > or another example if something is downvoted, this also implies that
> > > after
> > > > a vote is over, it’s approprorate to continue pushing the subject
> > trying
> > > to
> > > > just wear everyone down even though the outcome is clear. We’ve seen
> > this
> > > > before, actually.
> > > >
> > > > On Mon, Oct 29, 2018 at 5:41 PM Chris Olivier  >
> > > > wrote:
> > > >
> > > > > -1 “strive to meet consensus”? This seems to imply the consensus is
> > the
> > > > > natural expected state. So in the case where someone submits that
> we
> > > > should
> > > > > start a nuclear war, then our bylaws would state that we should all
> > try
> > > > to
> > > > > agree to start a nuclear war.
> > > > >
> > > > > On Mon, Oct 29, 2018 at 4:41 PM Tianqi Chen 
> > wrote:
> > > > >
> > > > >> Hi Carin:
> > > > >> Sorry for the last minute request, but given the way we write
> > down
> > > > the
> > > > >> PMC, committer privileges, I feel we need to add an additional
> line:
> > > > >>
> > > > >>- "PMC/committer should strive to be diplomatic and reach
> > consensus
> > > > >> with
> > > > >> discussion when possible."
> > > > >>
> > > > >>Since I don't really want us to give an impression of abusing
> > veto
> > > > >> rights.
> > > > >>
> > > > >> Thanks!
> > > > >> Tianqi
> > > &g

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Tianqi Chen]

Hi Carin:
Sorry for the last minute request, but given the way we write down the
PMC, committer privileges, I feel we need to add an additional line:

   - "PMC/committer should strive to be diplomatic and reach consensus with
discussion when possible."

   Since I don't really want us to give an impression of abusing veto
rights.

Thanks!
Tianqi

On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:

> This vote is to adopt the document
>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to replace the current document
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>
> The dev discussion thread is here
>
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
>  for a
> modifying factor.)
>
> The vote will run until Friday Nov 2nd at 6:00 am EST
>
> Thanks,
> Carin
>

Re: [VOTE] - Adopt "Become a Committer and PPMC Member" Document

[Tianqi Chen]

+1

Tianqi

On Mon, Oct 29, 2018 at 3:47 PM Carin Meier  wrote:

> This vote is to adopt the document
>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to replace the current document
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>
> The dev discussion thread is here
>
> https://lists.apache.org/thread.html/e61ffa26af374de7a99c475d406e462a00b26cfc1155e232198dd53e@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
>  for a
> modifying factor.)
>
> The vote will run until Friday Nov 2nd at 6:00 am EST
>
> Thanks,
> Carin
>

Re: Apache MXNet Scala nightly-build now available on Apache Nexus

[Tianqi Chen]

This is a great step for the community

Tianqi

On Mon, Oct 29, 2018 at 10:39 AM YiZhi Liu  wrote:

> Hi,
>
>
>
> I am happy to announce that the availability of the experimental
> nightly-build Scala package on Maven in Nexus. The nightly-builds,
> currently published as 1.3.1-SNAPSHOT version, include the latest changes
> from the master branch from apache/incubator-mxnet GitHub repo and refresh
> every day. Furthermore, we completely overhauled the MXNet library shipped
> inside and adopted the binary build logic used for Python pip, so now Scala
> users can also enjoy the portable MXNet with fully loaded features.
> Currently, the supported artifacts are:
>
> - mxnet-full_2.11-linux-x86_64-cpu (Linux-CPU)
>
> - mxnet-full_2.11-linux-x86_64-gpu (Linux-GPU, CUDA 9.0)
>
> - mxnet-full_2.11-osx-x86_64-cpu (OSX-CPU)
>
>
>
> FAQ:
>
> - What's new in the nightly Scala packages compared to the previous Scala
> Maven artifacts?
>
> Most notably, better usability, more supported features, and better
> platform compatibility. The new packages now support Ubuntu 14.04 and
> Amazon Linux and support the same broad set of features as the existing pip
> packages. Besides, users are no longer required to install all the
> dependencies to use the nightly Scala packages as the included MXNet
> libraries are fully loaded. For the list of supported platforms and
> features, see [1].
>
>
>
> - What's different in the build approach compared to what's in the previous
> Scala Maven packages?
>
> The previous Scala Maven packages (1.2, 1.2.1, 1.3) were built with the
> same build commands that regular users would use when building from source
> [2]. This naive approach limits the compatibility to only similar
> environments as where the packages were built (which was Ubuntu 16.04 for
> Linux, and OSX 10.13 for OSX). As a result, users cannot use it on more
> CentOS or Amazon Linux and may suffer the problem of mismatching of
> dependency versions due to the difference in their environment.
>
> On the other hand, Python users have long been enjoying portable and fully
> loaded MXNet packages from pip. The MXNet libraries in pip packages are
> built in more controlled environments with compatibility in mind.
> Dependencies for extended features are statically linked and masked so that
> no additional steps are needed.
>
> Now, in the new Scala nightly packages, the same approach as pip is used
> for building the MXNet library so that the Scala users can benefit from the
> same great features.
>
>
>
> - How do I get the new nightly packages?
>
> You can find the packages on Apache (Snapshots) repository [3] including
> pom files and jars, which you can download and add to your projects.
> Alternatively, you can configure your pom.xml to use the Maven repository.
> Remember to add repository config:
>
> 
>
>   
>
> Apache Snapshot
>
> https://repository.apache.org/content/groups/snapshots
>
>   
>
> 
>
>
>
> - What's the support level of the Scala nightly packages?
>
> This package is currently experimental, so use at your own risk. While the
> first nightly packages are already manually verified on several platforms,
> and the automated publish pipeline runs unit tests and integration tests on
> OSX and Ubuntu 14.04 before publishing, the testing is currently limited.
>
>
>
> - How can I help?
>
> We call on all MXNet Scala community to test out the new nightly packages.
>
>
>
> - I found a problem in using the package. What should I do?
>
> Please report this in the Github issue in [1].
>
>
>
> - What's next?
>
> There are several more things to be done:
>
> 1. We are adding more comprehensive support for GPU versions for different
> CUDA versions.
>
> 2. We are adding more tests on more platforms. We are currently examining
> the MXNet's Jenkins CI solution for supporting more platforms.
>
> 3. As we recognize that the build logic benefits the community, we plan to
> open source the build scripts in the mxnet main repo. See progress at [5].
>
>
>
> Qing Lan, Zach Kimberg, Sheng Zha, and I worked together to make this
> happen. Thanks to Sheng Zha for sharing the pip build logic, and for
> building the automated publishing pipelines. Special thanks to Qing and
> Zach for sharing their expertise in Scala with Sheng and guiding and
> supporting him locally for this milestone.
>
>
>
> [1] https://github.com/apache/incubator-mxnet/issues/8671
>
> [2]
>
> https://github.com/apache/incubator-mxnet/blob/master/scala-package/dev/compile-mxnet-backend.sh#L59-L105
>
> [3]
>
> https://repository.apache.org/#nexus-search;gav~org.apache.mxnet~~1.3.1-SNAPSHOT~~
>
> [4] https://maven.apache.org/repository-management.html
>
> [5] https://github.com/apache/incubator-mxnet/projects/13
>

Re: [DISCUSS] - Revisions to Committer Criteria

[Tianqi Chen]

Thanks Carin

Tianqi

On Sun, Oct 28, 2018 at 8:04 AM Carin Meier  wrote:

> I plan to start a vote on the adopting
>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> to
> replace our current document
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> tomorrow
> (Monday).
>
> - Carin
>
> On Thu, Oct 25, 2018 at 8:32 AM Carin Meier  wrote:
>
> > Thanks for publishing the notes and also thanks everyone for providing
> > valuable feedback and discussion.
> >
> > I encourage everyone that has ideas for improvement to the document to
> > feel free to edit and revise. If you need a login to the wiki, please
> just
> > ask.
> >
> > Also, while editing, please keep in mind that the intent is to have a
> vote
> > on adopting the new
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > to replace our current document
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > before a vote on separating levels of committer and PPMC as a process.
> So,
> > if possible, adopting wording that would work in either outcome of that
> > vote.
> >
> > On the subject of voting, I was thinking of starting a vote on Friday,
> but
> > will delay that until the active discussions and revisions are complete.
> >
> > Best,
> > Carin
> >
> > On Thu, Oct 25, 2018 at 6:39 AM Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> > wrote:
> >
> >> This is the first hangout that I was able to attend, I liked the format
> >> and
> >> found them valuable. Thanks for organizing and publishing the notes.
> >> Looking forward to the next one.
> >>
> >> Pedro
> >>
> >> On Thu, Oct 25, 2018 at 6:44 AM Steffen Rochel  >
> >> wrote:
> >>
> >> > Carin - please see
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Hangout+October+24th+2018+8am+and+5pm+PDT
> >> > :
> >> > Discussion about committer proposal:
> >> >
> >> >- Proposal default should be to have separation between committer
> and
> >> >PPMC election
> >> >- Criteria are vague, should we add some example persona?
> >> >- Spell out privileges of committer and PPMC member
> >> >
> >> >
> >> > Note: I update the project proposal to address first bullet.
> >> >
> >> > Steffen
> >> >
> >> >
> >> > On Wed, Oct 24, 2018 at 11:29 AM Carin Meier 
> >> wrote:
> >> >
> >> > > A request to whoever is taking notes at the MXNet Hangouts that are
> >> > > occurring today. Could you please recap feedback from the meeting in
> >> > > regards to document revisions here for everyone? I would like to
> >> attend
> >> > the
> >> > > session later today, but may not due to family obligations.
> >> > >
> >> > > Thanks!
> >> > > Carin
> >> > >
> >> > > On Tue, Oct 23, 2018 at 2:24 PM Steffen Rochel <
> >> steffenroc...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Carin - I got feedback on my proposal and made changes. I
> >> incorporated
> >> > > > Tianqi's suggesiton that we should strive to nominate
> committer/PPMC
> >> > > > candidates from outside ones own organization. It should not be
> >> > > considered
> >> > > > as a hard rule, but recommendation.
> >> > > >
> >> > > > Steffen
> >> > > >
> >> > > > On Mon, Oct 22, 2018 at 2:18 PM Carin Meier  >
> >> > > wrote:
> >> > > >
> >> > > > > Thanks Steffen helping draft up the proposal for Committer and
> >> PPMC
> >> > > > > guidelines.
> >> > > > >
> >> > > > > Please everyone review and provide feedback
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+(incubating)+Committer+and+PPMC+Member+Proposal
> >> > > > > .
> >> > > > >
> >> > > > > I plan to start a vote on this Friday if the
> discussions/revisions
> >> > are
> >> > > > > complete.
> >> > > > >
> >> > > > > - Carin
> >> > > > >
> >> > > > > On Fri, Oct 19, 2018 at 12:03 PM Carin Meier <
> >> carinme...@gmail.com>
> >> > > > wrote:
> >> > > > >
> >> > > > > > Great!
> >> > > > > >
> >> > > > > > I started a rough draft for collaboration at
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/MXNET/Become+a+Committer+Proposal
> >> > > > > > .
> >> > > > > >
> >> > > > > > Everyone feel free to enhance and provide feedback.
> >> > > > > >
> >> > > > > > - Carin
> >> > > > > >
> >> > > > > > On Fri, Oct 19, 2018 at 10:55 AM Steffen Rochel <
> >> > > > steffenroc...@gmail.com
> >> > > > > >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > >> +1, great suggestion, thanks Carin!
> >> > > > > >> I'm willing to collaborate to create a draft proposal.
> >> > > > > >> Steffen
> >> > > > > >>
> >> > > > > >> On Fri, Oct 19, 2018 at 5:35 AM Carin Meier <
> >> carinme...@gmail.com
> >> > >
> >> > > > > wrote:
> >> > > > > >>
> >> > > > > >> > Background:
> >> > > > > >> >
> >> > > > > >> > There is a desire to increase the committer pool and 

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

>
>  To become a reviewer , he/she would have to have some
> history of code review in MXNet.


In contrary, we should to bring reviewers who have contributed to the repo,
but do not have code review history before, there is always a time gap
between someone who contributed something, to someone who would provide
active high-quality review feedbacks. The reviewer could be an useful
mechanism to encourage the contributors to do so

Tianqi


On Tue, Oct 23, 2018, 8:31 AM Tianqi Chen  wrote:
>
> > It is true that is a person is trusted to review code they should be
> > considered as a committer.
> >
> > On the other hand, it is also super valuable to solicit reviews from
> > contributors who have the potential to become committers. These code
> > reviews may not necessarily directly grant the merge of the code, they
> are
> > super helpful to the one who sends the patch, the committer who would
> merge
> > the code, and the reviewer(since they can learn from code review of
> > committers).
> >
> > There is always a process for a contributor to learn, and starting by
> > contributing code reviews is a good part. Potential committers don't
> simply
> > show up in the community. We need to find them, encourage them to
> > contribute and provide mentorship. I am proposing to recognize them and
> > list them as reviewers, so committers can solicit reviews and watch these
> > process. This would in general results in more reviews for each patch,
> and
> > more evidence to help us to find potential committers
> >
> > Tianqi
> >
> > On Tue, Oct 23, 2018 at 8:29 AM Tianqi Chen  wrote:
> >
> > > It is true that is a person is trusted to review code they should be
> > > considered as a reviewer.
> > >
> > > But what I am trying to say is that -- it is also super valuable to
> > > solicit reviews from contributors who have the potential to become
> > > committers. These code reviews may not necessarily directly grant the
> > merge
> > > of the code, they are super helpful to the one who sends the patch, the
> > > committer who would merge the code, and the reviewer(since they can
> learn
> > > from code review of committers).
> > >
> > > There is always a process for a contributor to learn, and starting by
> > > contributing code reviews is a good part. I am proposing to recognize
> > them
> > > and list them as reviewers, so committers can solicit reviews and watch
> > > these process. This would in general results in more reviews for each
> > > patch, and more evidence to help us to find potential committers
> > >
> > > Tianqi
> > >
> > > On Tue, Oct 23, 2018 at 7:08 AM Bob Paulin  wrote:
> > >
> > >> Generally if a person is trusted to review code they should be
> > >> considered as a committer.  Agree that having good reviewers are
> > >> important but the way most projects recognize those efforts is by
> making
> > >> them committers.
> > >>
> > >>
> > >> - Bob
> > >>
> > >>
> > >> On 10/22/2018 5:23 PM, Chris Olivier wrote:
> > >> > Are there any other major Apache projects which have this
> designation?
> > >> I
> > >> > am always continually suspicious of efforts to reinvent Apache rules
> > >> from
> > >> > other non-Apache projects, when Apache projects have historically
> been
> > >> > quite successful within the Apache platform.  In fact, operating
> > >> outside of
> > >> > Apache norms is already a major problem as everyone knows.  We are
> > only
> > >> > just now splitting Committer/PMC into two separate groups. Splitting
> > >> into
> > >> > three seems a bit much at this juncture unless there's some good
> > >> precedents.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Mon, Oct 22, 2018 at 2:17 PM Tianqi Chen 
> > wrote:
> > >> >
> > >> >> The situation most projects are facing(including us), is lack of
> code
> > >> >> reviews. Code reviews are the most important part of the project,
> and
> > >> >> high-quality reviews are extremely time-consuming, maybe as much as
> > so
> > >> >> as the code itself. Usually, it is only committers do the code
> > >> reviews, the
> > >> >> code reviews from committers are important, as they are the serve
> as

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

It is true that is a person is trusted to review code they should be
considered as a committer.

On the other hand, it is also super valuable to solicit reviews from
contributors who have the potential to become committers. These code
reviews may not necessarily directly grant the merge of the code, they are
super helpful to the one who sends the patch, the committer who would merge
the code, and the reviewer(since they can learn from code review of
committers).

There is always a process for a contributor to learn, and starting by
contributing code reviews is a good part. Potential committers don't simply
show up in the community. We need to find them, encourage them to
contribute and provide mentorship. I am proposing to recognize them and
list them as reviewers, so committers can solicit reviews and watch these
process. This would in general results in more reviews for each patch, and
more evidence to help us to find potential committers

Tianqi

On Tue, Oct 23, 2018 at 8:29 AM Tianqi Chen  wrote:

> It is true that is a person is trusted to review code they should be
> considered as a reviewer.
>
> But what I am trying to say is that -- it is also super valuable to
> solicit reviews from contributors who have the potential to become
> committers. These code reviews may not necessarily directly grant the merge
> of the code, they are super helpful to the one who sends the patch, the
> committer who would merge the code, and the reviewer(since they can learn
> from code review of committers).
>
> There is always a process for a contributor to learn, and starting by
> contributing code reviews is a good part. I am proposing to recognize them
> and list them as reviewers, so committers can solicit reviews and watch
> these process. This would in general results in more reviews for each
> patch, and more evidence to help us to find potential committers
>
> Tianqi
>
> On Tue, Oct 23, 2018 at 7:08 AM Bob Paulin  wrote:
>
>> Generally if a person is trusted to review code they should be
>> considered as a committer.  Agree that having good reviewers are
>> important but the way most projects recognize those efforts is by making
>> them committers.
>>
>>
>> - Bob
>>
>>
>> On 10/22/2018 5:23 PM, Chris Olivier wrote:
>> > Are there any other major Apache projects which have this designation?
>> I
>> > am always continually suspicious of efforts to reinvent Apache rules
>> from
>> > other non-Apache projects, when Apache projects have historically been
>> > quite successful within the Apache platform.  In fact, operating
>> outside of
>> > Apache norms is already a major problem as everyone knows.  We are only
>> > just now splitting Committer/PMC into two separate groups. Splitting
>> into
>> > three seems a bit much at this juncture unless there's some good
>> precedents.
>> >
>> >
>> >
>> >
>> > On Mon, Oct 22, 2018 at 2:17 PM Tianqi Chen  wrote:
>> >
>> >> The situation most projects are facing(including us), is lack of code
>> >> reviews. Code reviews are the most important part of the project, and
>> >> high-quality reviews are extremely time-consuming, maybe as much as so
>> >> as the code itself. Usually, it is only committers do the code
>> reviews, the
>> >> code reviews from committers are important, as they are the serve as
>> >> the gate-keeper of the quality of the code.  In my experience, I
>> >> usually find the reviews from non-committer super helpful, and they
>> >> help the committer to catch problems that are otherwise overlooked.
>> >>
>> >> However, it is very hard to get contributors to do code reviews unless
>> we
>> >> solicit them. It is definitely harder than getting code
>> contributions.  The
>> >> Reviewer mechanism could provide a way to do so. We can recognize
>> >> contributors, bring them as reviewers and encourage them to do the code
>> >> reviews by explicitly soliciting. The reviewers can learn from the
>> >> committer reviews,
>> >> which serves as a role model for what is being expected. Naturally,
>> this
>> >> likely helps us find more good reviewers and bought them committer.
>> >>
>> >> Cheers
>> >> Tianqi
>> >>
>> >> On Mon, Oct 22, 2018 at 1:09 PM Anirudh  wrote:
>> >>
>> >>> -1. I dont see the need for additional level of hierarchy. I totally
>> am
>> >> for
>> >>> recognizing good code reviewers. We can recognize this by making them
>> >>> committe

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

It is true that is a person is trusted to review code they should be
considered as a reviewer.

But what I am trying to say is that -- it is also super valuable to solicit
reviews from contributors who have the potential to become committers.
These code reviews may not necessarily directly grant the merge of the
code, they are super helpful to the one who sends the patch, the committer
who would merge the code, and the reviewer(since they can learn from code
review of committers).

There is always a process for a contributor to learn, and starting by
contributing code reviews is a good part. I am proposing to recognize them
and list them as reviewers, so committers can solicit reviews and watch
these process. This would in general results in more reviews for each
patch, and more evidence to help us to find potential committers

Tianqi

On Tue, Oct 23, 2018 at 7:08 AM Bob Paulin  wrote:

> Generally if a person is trusted to review code they should be
> considered as a committer.  Agree that having good reviewers are
> important but the way most projects recognize those efforts is by making
> them committers.
>
>
> - Bob
>
>
> On 10/22/2018 5:23 PM, Chris Olivier wrote:
> > Are there any other major Apache projects which have this designation?  I
> > am always continually suspicious of efforts to reinvent Apache rules from
> > other non-Apache projects, when Apache projects have historically been
> > quite successful within the Apache platform.  In fact, operating outside
> of
> > Apache norms is already a major problem as everyone knows.  We are only
> > just now splitting Committer/PMC into two separate groups. Splitting into
> > three seems a bit much at this juncture unless there's some good
> precedents.
> >
> >
> >
> >
> > On Mon, Oct 22, 2018 at 2:17 PM Tianqi Chen  wrote:
> >
> >> The situation most projects are facing(including us), is lack of code
> >> reviews. Code reviews are the most important part of the project, and
> >> high-quality reviews are extremely time-consuming, maybe as much as so
> >> as the code itself. Usually, it is only committers do the code reviews,
> the
> >> code reviews from committers are important, as they are the serve as
> >> the gate-keeper of the quality of the code.  In my experience, I
> >> usually find the reviews from non-committer super helpful, and they
> >> help the committer to catch problems that are otherwise overlooked.
> >>
> >> However, it is very hard to get contributors to do code reviews unless
> we
> >> solicit them. It is definitely harder than getting code contributions.
> The
> >> Reviewer mechanism could provide a way to do so. We can recognize
> >> contributors, bring them as reviewers and encourage them to do the code
> >> reviews by explicitly soliciting. The reviewers can learn from the
> >> committer reviews,
> >> which serves as a role model for what is being expected. Naturally, this
> >> likely helps us find more good reviewers and bought them committer.
> >>
> >> Cheers
> >> Tianqi
> >>
> >> On Mon, Oct 22, 2018 at 1:09 PM Anirudh  wrote:
> >>
> >>> -1. I dont see the need for additional level of hierarchy. I totally am
> >> for
> >>> recognizing good code reviewers. We can recognize this by making them
> >>> committers. Being a good reviewer should be sufficient to become a
> >>> committer in my opinion. (Assuming that there is a seperation between
> >> PPMC
> >>> and committers).
> >>>
> >>> Anirudh
> >>>
> >>> On Mon, Oct 22, 2018 at 8:28 AM Qing Lan  wrote:
> >>>
> >>>> +1
> >>>> Let's have a reviewer list somewhere with a certain format: such as
> >> C++,
> >>>> Gluon, Scala/Java based on language or some other category. etc. In
> the
> >>>> future, label bot would automatically assign reviewers based on this
> >> kind
> >>>> of documentation.
> >>>>
> >>>> Thanks,
> >>>> Qing
> >>>>
> >>>> On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:
> >>>>
> >>>> +1
> >>>> I also suggest add reviewer list link to the PR template, so that
> >>>> developers can easily request review from those reviewers.
> >>>> On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen 
> >>> wrote:
> >>>> >
> >>>> > I was suggesting something more concrete:
> >>>> >
> >

Re: [Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Tianqi Chen]

Hi Pedro:
If any of the Amazonians have enough merit to get the committership.
The PMCs outside Amazon should recognize and bring them to the
committership -- This proposal is not about discriminating against anyone.
Please do note that this community is bigger than Amazon itself -- there
are Intel engineers, Googlers, University students, startup companies
employees, Apache members, and independent contributors. Admittedly their
contributions need to get recognized, and they do not sit next door to
another PMC member.

   I do not understand why we should be afraid of this proposal. If the
merit of contributions is good enough, any PMC, including non-Amazonians
should recognize and propose them to the committership, why does it have to
be an Amazonian PMC? Why not try get someone outside Amazon to do so. Try
to have a goodwill and to give it a spin.

On Tue, Oct 23, 2018 at 7:09 AM Pedro Larroy 
wrote:

> Hi
>
> Tianqi, there's a saying that the road to hell is paved with good
> intentions. I think most of us here are enthusiastic about increasing
> diversity of contributions to this project and are working actively towards
> this. Having any kind of positive or negative discrimination seems to me
> like it goes against what's listed on the Apache website, under the section
> "Meritocracy". https://www.apache.org/foundation/how-it-works.html
> Several
> Amazonians have invested time, love and resources both inside and outside
> working hours to this project. I don't think it's fair to them that their
> contributions are not taken impartially irregardless of their current
> employer, neither would be against a member of any other organization, sex,
> condition etc.
>
> -1
>
> Pedro.
>
>
>
>
> On Mon, Oct 22, 2018 at 6:02 PM Tianqi Chen  wrote:
>
> > I want to clarify that this would not prevent Amazon contributors from
> > being nominated. Nor it would prevent collaboration between Amazon
> > employees. A good thing about Apache is that everything is recorded and
> > presented to the entire community, this includes the dev list,
> > github review/commit history, documentation, wiki.
> >
> > Specifically to Amazon contributors, there are non-Amazon PMCs can watch
> > these evidence and bring these contributors on board -- and I am very
> > certain this would be the case. If the problem that there are too few
> > non-Amazon PMCs, then it wouldn't hurt to try to get more on board, and
> > then get them in the term to nominate PMC contributors.
> >
> > One of the key criteria of graduation for an Apache Project is that it
> > should not be controlled by a single entity. I think that whether we can
> > execute this guideline is exactly a good test to check if we pass that
> bar.
> >
> > On Sun, Oct 21, 2018 at 9:19 PM Naveen Swamy  wrote:
> >
> > > this suggestion looks like it is putting the onus on contributors to
> > > collaborate with contributors outside their org to get nominated to be
> > > committer or a PMC of this project.
> > > Every organization has its own business goals, on the way to meet their
> > > objectives if their employees happen to be great contributors to this
> > > project, I would expect PMC members(wearing their Apache hat) to
> > recognize
> > > them and give them a greater role in the project.
> > > I would assume the responsibility of increasing the diversity is solely
> > > upon the PMC members, the PMC should look ways to evangelize the
> project,
> > > mentor new contributors, nominate and make them a part of the project's
> > > journey.
> > > I do agree that we have to increase the diversity and suggest to
> explore
> > > different ways( for example collaborate with other successful Open
> source
> > > projects to get their members excited about MXNet).
> > >
> > > Guideline or not, I cannot agree to this in principle.
> > > -1
> > >
> > >
> > > On Sun, Oct 21, 2018 at 8:22 PM Tianqi Chen 
> > > wrote:
> > >
> > > > >
> > > > >  Many potential committers and
> > > > > PMC won’t interact with the non-Amazonians at all (since there are
> so
> > > > few),
> > > > > so they’d be relegated to obscurity and hopelessness by default.
> > > > >
> > > >
> > > > If potential contributors do not comes from Amazon, then the
> Amazonian
> > > PMC
> > > > can nominate them :)  If the potential contributors does comes from
> > > Amazon,
> > > > then it is not a bad thing to interact with bigger part of the
> > > community.

Re: [Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Tianqi Chen]

Hi Pedro:
If any of the Amazonians have enough merit to get the committership.
The PMCs outside Amazon should recognize and bring them to the
committership -- This proposal is not about discriminating against anyone.
Please do note that this community is bigger than Amazon itself -- there
are Intel engineers, Googlers, University students, startup companies
employees, Apache members, and independent contributors. Admittedly their
contributions need to get recognized, and they do not sit next door to
another PMC member.

   I do not understand why we should be afraid of this proposal. If the
merit of contributions is good enough, any PMC, including non-Amazonians
should recognize and propose them to the committership, why does it have to
be an Amazonian PMC? Why not try get someone outside Amazon to do so. Try
to have a goodwill and to give it a spin.

Tianqi

On Tue, Oct 23, 2018 at 7:09 AM Pedro Larroy 
wrote:

> Hi
>
> Tianqi, there's a saying that the road to hell is paved with good
> intentions. I think most of us here are enthusiastic about increasing
> diversity of contributions to this project and are working actively towards
> this. Having any kind of positive or negative discrimination seems to me
> like it goes against what's listed on the Apache website, under the section
> "Meritocracy". https://www.apache.org/foundation/how-it-works.html
> Several
> Amazonians have invested time, love and resources both inside and outside
> working hours to this project. I don't think it's fair to them that their
> contributions are not taken impartially irregardless of their current
> employer, neither would be against a member of any other organization, sex,
> condition etc.
>
> -1
>
> Pedro.
>
>
>
>
> On Mon, Oct 22, 2018 at 6:02 PM Tianqi Chen  wrote:
>
> > I want to clarify that this would not prevent Amazon contributors from
> > being nominated. Nor it would prevent collaboration between Amazon
> > employees. A good thing about Apache is that everything is recorded and
> > presented to the entire community, this includes the dev list,
> > github review/commit history, documentation, wiki.
> >
> > Specifically to Amazon contributors, there are non-Amazon PMCs can watch
> > these evidence and bring these contributors on board -- and I am very
> > certain this would be the case. If the problem that there are too few
> > non-Amazon PMCs, then it wouldn't hurt to try to get more on board, and
> > then get them in the term to nominate PMC contributors.
> >
> > One of the key criteria of graduation for an Apache Project is that it
> > should not be controlled by a single entity. I think that whether we can
> > execute this guideline is exactly a good test to check if we pass that
> bar.
> >
> > On Sun, Oct 21, 2018 at 9:19 PM Naveen Swamy  wrote:
> >
> > > this suggestion looks like it is putting the onus on contributors to
> > > collaborate with contributors outside their org to get nominated to be
> > > committer or a PMC of this project.
> > > Every organization has its own business goals, on the way to meet their
> > > objectives if their employees happen to be great contributors to this
> > > project, I would expect PMC members(wearing their Apache hat) to
> > recognize
> > > them and give them a greater role in the project.
> > > I would assume the responsibility of increasing the diversity is solely
> > > upon the PMC members, the PMC should look ways to evangelize the
> project,
> > > mentor new contributors, nominate and make them a part of the project's
> > > journey.
> > > I do agree that we have to increase the diversity and suggest to
> explore
> > > different ways( for example collaborate with other successful Open
> source
> > > projects to get their members excited about MXNet).
> > >
> > > Guideline or not, I cannot agree to this in principle.
> > > -1
> > >
> > >
> > > On Sun, Oct 21, 2018 at 8:22 PM Tianqi Chen 
> > > wrote:
> > >
> > > > >
> > > > >  Many potential committers and
> > > > > PMC won’t interact with the non-Amazonians at all (since there are
> so
> > > > few),
> > > > > so they’d be relegated to obscurity and hopelessness by default.
> > > > >
> > > >
> > > > If potential contributors do not comes from Amazon, then the
> Amazonian
> > > PMC
> > > > can nominate them :)  If the potential contributors does comes from
> > > Amazon,
> > > > then it is not a bad thing to interact with bigger part of the
> > > comm

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

To be clear, we are not splitting the committers into reviewers, we are
recognizing an additional set of contributors who could become potential
committers and recognizing them as committers

Tianqi

On Mon, Oct 22, 2018 at 3:23 PM Chris Olivier  wrote:

> Are there any other major Apache projects which have this designation?  I
> am always continually suspicious of efforts to reinvent Apache rules from
> other non-Apache projects, when Apache projects have historically been
> quite successful within the Apache platform.  In fact, operating outside of
> Apache norms is already a major problem as everyone knows.  We are only
> just now splitting Committer/PMC into two separate groups. Splitting into
> three seems a bit much at this juncture unless there's some good
> precedents.
>
>
>
>
> On Mon, Oct 22, 2018 at 2:17 PM Tianqi Chen  wrote:
>
> > The situation most projects are facing(including us), is lack of code
> > reviews. Code reviews are the most important part of the project, and
> > high-quality reviews are extremely time-consuming, maybe as much as so
> > as the code itself. Usually, it is only committers do the code reviews,
> the
> > code reviews from committers are important, as they are the serve as
> > the gate-keeper of the quality of the code.  In my experience, I
> > usually find the reviews from non-committer super helpful, and they
> > help the committer to catch problems that are otherwise overlooked.
> >
> > However, it is very hard to get contributors to do code reviews unless we
> > solicit them. It is definitely harder than getting code contributions.
> The
> > Reviewer mechanism could provide a way to do so. We can recognize
> > contributors, bring them as reviewers and encourage them to do the code
> > reviews by explicitly soliciting. The reviewers can learn from the
> > committer reviews,
> > which serves as a role model for what is being expected. Naturally, this
> > likely helps us find more good reviewers and bought them committer.
> >
> > Cheers
> > Tianqi
> >
> > On Mon, Oct 22, 2018 at 1:09 PM Anirudh  wrote:
> >
> > > -1. I dont see the need for additional level of hierarchy. I totally am
> > for
> > > recognizing good code reviewers. We can recognize this by making them
> > > committers. Being a good reviewer should be sufficient to become a
> > > committer in my opinion. (Assuming that there is a seperation between
> > PPMC
> > > and committers).
> > >
> > > Anirudh
> > >
> > > On Mon, Oct 22, 2018 at 8:28 AM Qing Lan  wrote:
> > >
> > > > +1
> > > > Let's have a reviewer list somewhere with a certain format: such as
> > C++,
> > > > Gluon, Scala/Java based on language or some other category. etc. In
> the
> > > > future, label bot would automatically assign reviewers based on this
> > kind
> > > > of documentation.
> > > >
> > > > Thanks,
> > > > Qing
> > > >
> > > > On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:
> > > >
> > > > +1
> > > > I also suggest add reviewer list link to the PR template, so that
> > > > developers can easily request review from those reviewers.
> > > > On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen 
> > > wrote:
> > > > >
> > > > > I was suggesting something more concrete:
> > > > >
> > > > > - Add a Reviewers section to
> > > > >
> > > >
> https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md
> > to
> > > > > list a list of Reviewers.
> > > > > - This is a "pesudo role", but holds weight as committers
> > > should
> > > > highly
> > > > > value their reviews during the PR process.
> > > > > - The committers/PMC could actively look for good contributors
> > and
> > > > nominate
> > > > > them as Reviewer.
> > > > > - Contributors are encouraged to seek reviews from the list of
> > > > reviewers.
> > > > > - The committers should actively solicit code reviews from the
> > > > reviewers
> > > > > when reviewing PRs and take their reviews into serious
> > > consideration.
> > > > >
> > > > > - PMCs should actively look for new committers in the current
> > > > Reviewers
> > > > >- Notably, the history reviews

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

The situation most projects are facing(including us), is lack of code
reviews. Code reviews are the most important part of the project, and
high-quality reviews are extremely time-consuming, maybe as much as so
as the code itself. Usually, it is only committers do the code reviews, the
code reviews from committers are important, as they are the serve as
the gate-keeper of the quality of the code.  In my experience, I
usually find the reviews from non-committer super helpful, and they
help the committer to catch problems that are otherwise overlooked.

However, it is very hard to get contributors to do code reviews unless we
solicit them. It is definitely harder than getting code contributions.  The
Reviewer mechanism could provide a way to do so. We can recognize
contributors, bring them as reviewers and encourage them to do the code
reviews by explicitly soliciting. The reviewers can learn from the
committer reviews,
which serves as a role model for what is being expected. Naturally, this
likely helps us find more good reviewers and bought them committer.

Cheers
Tianqi

On Mon, Oct 22, 2018 at 1:09 PM Anirudh  wrote:

> -1. I dont see the need for additional level of hierarchy. I totally am for
> recognizing good code reviewers. We can recognize this by making them
> committers. Being a good reviewer should be sufficient to become a
> committer in my opinion. (Assuming that there is a seperation between PPMC
> and committers).
>
> Anirudh
>
> On Mon, Oct 22, 2018 at 8:28 AM Qing Lan  wrote:
>
> > +1
> > Let's have a reviewer list somewhere with a certain format: such as C++,
> > Gluon, Scala/Java based on language or some other category. etc. In the
> > future, label bot would automatically assign reviewers based on this kind
> > of documentation.
> >
> > Thanks,
> > Qing
> >
> > On 10/21/18, 11:44 PM, "YiZhi Liu"  wrote:
> >
> > +1
> > I also suggest add reviewer list link to the PR template, so that
> > developers can easily request review from those reviewers.
> > On Sun, Oct 21, 2018 at 8:30 PM Tianqi Chen 
> wrote:
> > >
> > > I was suggesting something more concrete:
> > >
> > > - Add a Reviewers section to
> > >
> > https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md to
> > > list a list of Reviewers.
> > > - This is a "pesudo role", but holds weight as committers
> should
> > highly
> > > value their reviews during the PR process.
> > > - The committers/PMC could actively look for good contributors and
> > nominate
> > > them as Reviewer.
> > > - Contributors are encouraged to seek reviews from the list of
> > reviewers.
> > > - The committers should actively solicit code reviews from the
> > reviewers
> > > when reviewing PRs and take their reviews into serious
> consideration.
> > >
> > > - PMCs should actively look for new committers in the current
> > Reviewers
> > >- Notably, the history reviews plus contribution likely will
> > provide a
> > > good indication on whether the person can uphold the quality
> > standard of
> > > the codebase, and provide helpful feedbacks(which is the trait that
> > needed
> > > from committer to merge code)
> > >
> > > Tianqi
> > >
> > >
> > > On Sun, Oct 21, 2018 at 5:13 PM Steffen Rochel <
> > steffenroc...@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > > With the release announcement for MXNet 1.3 all contributors
> incl.
> > code
> > > > reviewers have been recognized. I suggest all future release
> > announcements
> > > > should include such recognition. Are you suggesting to highlight
> > most
> > > > active reviewers in release announcement or regularly (e.g.
> > monthly),
> > > > specifically from non-committers?
> > > >
> > > > On Sun, Oct 21, 2018 at 10:11 AM Tianqi Chen 
> > wrote:
> > > >
> > > > > Also re another email-thread(I sent out one with my
> > institutional email
> > > > > which get blocked initially, so this one was a bit duplication
> > of that).
> > > > I
> > > > > think it should really be the job of committers to recognize
> > potential
> > > > > reviewers, github also makes it easier to do so, e.g.
> > > > >
> > > > >
>

Re: [Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Tianqi Chen]

I want to clarify that this would not prevent Amazon contributors from
being nominated. Nor it would prevent collaboration between Amazon
employees. A good thing about Apache is that everything is recorded and
presented to the entire community, this includes the dev list,
github review/commit history, documentation, wiki.

Specifically to Amazon contributors, there are non-Amazon PMCs can watch
these evidence and bring these contributors on board -- and I am very
certain this would be the case. If the problem that there are too few
non-Amazon PMCs, then it wouldn't hurt to try to get more on board, and
then get them in the term to nominate PMC contributors.

One of the key criteria of graduation for an Apache Project is that it
should not be controlled by a single entity. I think that whether we can
execute this guideline is exactly a good test to check if we pass that bar.

On Sun, Oct 21, 2018 at 9:19 PM Naveen Swamy  wrote:

> this suggestion looks like it is putting the onus on contributors to
> collaborate with contributors outside their org to get nominated to be
> committer or a PMC of this project.
> Every organization has its own business goals, on the way to meet their
> objectives if their employees happen to be great contributors to this
> project, I would expect PMC members(wearing their Apache hat) to recognize
> them and give them a greater role in the project.
> I would assume the responsibility of increasing the diversity is solely
> upon the PMC members, the PMC should look ways to evangelize the project,
> mentor new contributors, nominate and make them a part of the project's
> journey.
> I do agree that we have to increase the diversity and suggest to explore
> different ways( for example collaborate with other successful Open source
> projects to get their members excited about MXNet).
>
> Guideline or not, I cannot agree to this in principle.
> -1
>
>
> On Sun, Oct 21, 2018 at 8:22 PM Tianqi Chen 
> wrote:
>
> > >
> > >  Many potential committers and
> > > PMC won’t interact with the non-Amazonians at all (since there are so
> > few),
> > > so they’d be relegated to obscurity and hopelessness by default.
> > >
> >
> > If potential contributors do not comes from Amazon, then the Amazonian
> PMC
> > can nominate them :)  If the potential contributors does comes from
> Amazon,
> > then it is not a bad thing to interact with bigger part of the
> community. I
> > can expect that as more non-Amazonian contributors get nonimated, this
> > would make the process more healthy.
> >
> > Like neural networks, any guideline can be played in adverserial fashion
> > (e.g. in the case of the gray areas). I think having a goodwill to push
> the
> > guideline will understandably make people to work together.
> >
> > Afterall, this is an Apache project that should goes beyond a single
> > company
> >
> > Tianqi
> >
> > >
> > >
> > >
> > > On Sun, Oct 21, 2018 at 5:06 PM Steffen Rochel <
> steffenroc...@gmail.com>
> > > wrote:
> > >
> > > > Hi Tianqi -
> > > > +1 . I like the idea to grow diversity at the project and encourage
> > > > communication beyond people sitting next to each other. I also
> support
> > > the
> > > > way you described as guideline, not has a hard rule. I think it is
> > > > important we focus on merit and contributions when evaluating nominee
> > for
> > > > committer and PPMC.
> > > >
> > > > Carin started a draft document for revised criteria for committer and
> > > PPMC
> > > > membership
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > > >.
> > > > I suggest to contribute, provide feedback and suggestion including
> your
> > > > proposal.
> > > >
> > > > Steffen
> > > >
> > > > On Sun, Oct 21, 2018 at 10:22 AM Tianqi Chen 
> > wrote:
> > > >
> > > > > Dear MXNet Community:
> > > > >
> > > > > There has been a great discussion going on in terms of
> > > > > PMC/Committer Criteria.  As a community move forward, it is
> important
> > > to
> > > > > make the community inclusive to everyone and encourage folks to
> work
> > > > > together.
> > > > >
> > > > > I want to propose the following proposal courtesy: when a PMC
> > proposes
> > > a
> >

Re: [Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Tianqi Chen]

I want to clarify that this would not prevent Amazon contributors from
being nominated. Nor it would prevent collaboration between Amazon
employees. A good thing about Apache is that everything is recorded and
presented to the entire community, this includes the dev list,
github review/commit history, documentation, wiki.

Specifically to Amazon contributors, there are non-Amazon PMCs can watch
these evidence and bring these contributors on board -- and I am very
certain this would be the case. If the problem that there are too few
non-Amazon PMCs, then it wouldn't hurt to try to get more on board, and
then get them in the term to nominate PMC contributors.

One of the key criteria of graduation for an Apache Project is that it
should not be controlled by a single entity, I think to be able to execute
this guideline is exactly a good test to check if we pass that bar.

Tianqi

On Sun, Oct 21, 2018 at 9:19 PM Naveen Swamy  wrote:

> this suggestion looks like it is putting the onus on contributors to
> collaborate with contributors outside their org to get nominated to be
> committer or a PMC of this project.
> Every organization has its own business goals, on the way to meet their
> objectives if their employees happen to be great contributors to this
> project, I would expect PMC members(wearing their Apache hat) to recognize
> them and give them a greater role in the project.
> I would assume the responsibility of increasing the diversity is solely
> upon the PMC members, the PMC should look ways to evangelize the project,
> mentor new contributors, nominate and make them a part of the project's
> journey.
> I do agree that we have to increase the diversity and suggest to explore
> different ways( for example collaborate with other successful Open source
> projects to get their members excited about MXNet).
>
> Guideline or not, I cannot agree to this in principle.
> -1
>
>
> On Sun, Oct 21, 2018 at 8:22 PM Tianqi Chen 
> wrote:
>
> > >
> > >  Many potential committers and
> > > PMC won’t interact with the non-Amazonians at all (since there are so
> > few),
> > > so they’d be relegated to obscurity and hopelessness by default.
> > >
> >
> > If potential contributors do not comes from Amazon, then the Amazonian
> PMC
> > can nominate them :)  If the potential contributors does comes from
> Amazon,
> > then it is not a bad thing to interact with bigger part of the
> community. I
> > can expect that as more non-Amazonian contributors get nonimated, this
> > would make the process more healthy.
> >
> > Like neural networks, any guideline can be played in adverserial fashion
> > (e.g. in the case of the gray areas). I think having a goodwill to push
> the
> > guideline will understandably make people to work together.
> >
> > Afterall, this is an Apache project that should goes beyond a single
> > company
> >
> > Tianqi
> >
> > >
> > >
> > >
> > > On Sun, Oct 21, 2018 at 5:06 PM Steffen Rochel <
> steffenroc...@gmail.com>
> > > wrote:
> > >
> > > > Hi Tianqi -
> > > > +1 . I like the idea to grow diversity at the project and encourage
> > > > communication beyond people sitting next to each other. I also
> support
> > > the
> > > > way you described as guideline, not has a hard rule. I think it is
> > > > important we focus on merit and contributions when evaluating nominee
> > for
> > > > committer and PPMC.
> > > >
> > > > Carin started a draft document for revised criteria for committer and
> > > PPMC
> > > > membership
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > > > >.
> > > > I suggest to contribute, provide feedback and suggestion including
> your
> > > > proposal.
> > > >
> > > > Steffen
> > > >
> > > > On Sun, Oct 21, 2018 at 10:22 AM Tianqi Chen 
> > wrote:
> > > >
> > > > > Dear MXNet Community:
> > > > >
> > > > > There has been a great discussion going on in terms of
> > > > > PMC/Committer Criteria.  As a community move forward, it is
> important
> > > to
> > > > > make the community inclusive to everyone and encourage folks to
> work
> > > > > together.
> > > > >
> > > > > I want to propose the following proposal courtesy: when a PMC
> > proposes
> > > a
> >

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

I was suggesting something more concrete:

- Add a Reviewers section to
https://github.com/apache/incubator-mxnet/blob/master/CONTRIBUTORS.md to
list a list of Reviewers.
- This is a "pesudo role", but holds weight as committers should highly
value their reviews during the PR process.
- The committers/PMC could actively look for good contributors and nominate
them as Reviewer.
- Contributors are encouraged to seek reviews from the list of reviewers.
- The committers should actively solicit code reviews from the reviewers
when reviewing PRs and take their reviews into serious consideration.

- PMCs should actively look for new committers in the current Reviewers
   - Notably, the history reviews plus contribution likely will provide a
good indication on whether the person can uphold the quality standard of
the codebase, and provide helpful feedbacks(which is the trait that needed
from committer to merge code)

Tianqi


On Sun, Oct 21, 2018 at 5:13 PM Steffen Rochel 
wrote:

> +1
> With the release announcement for MXNet 1.3 all contributors incl. code
> reviewers have been recognized. I suggest all future release announcements
> should include such recognition. Are you suggesting to highlight most
> active reviewers in release announcement or regularly (e.g. monthly),
> specifically from non-committers?
>
> On Sun, Oct 21, 2018 at 10:11 AM Tianqi Chen  wrote:
>
> > Also re another email-thread(I sent out one with my institutional email
> > which get blocked initially, so this one was a bit duplication of that).
> I
> > think it should really be the job of committers to recognize potential
> > reviewers, github also makes it easier to do so, e.g.
> >
> >
> https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=reviewed-by%3Apiiswrong
> >
> > Tianqi
> >
> > On Fri, Oct 19, 2018 at 12:05 PM Carin Meier 
> wrote:
> >
> > > +1 Great idea. Adding a name to the contributor list is a good idea.
> > Also,
> > > I've found that thanking the person for the review on the PR is another
> > way
> > > to express gratitude for their time and effort.
> > >
> > > On Fri, Oct 19, 2018 at 2:51 PM Tianqi Chen  wrote:
> > >
> > > > Dear MXNet Community:
> > > >
> > > > There is a great discussion going on in terms of lowering the barrier
> > of
> > > > entries and encourage more contribution to the project.  One of the
> > > general
> > > > goals is to encourage a broader pool of contributions. I want to make
> > the
> > > > following proposal:
> > > >
> > > > Besides Committers and PMC, let us also recognize Reviewers in the
> > > > community.  This is a "pseudo role" as there is no such official role
> > in
> > > > Apache. But I want to explore the possibility of recognizing active
> > > > reviewers for example, by adding a list of names in the contributor
> > list.
> > > > In general, I find it is really helpful to have more code reviews.
> > > > Recognizing good reviewers early enables us to find committer
> > candidates,
> > > > and encourage them to contribute and understand what is the bar of
> code
> > > > quality that is required to merge the code.
> > > >
> > > > This can provide the community with more evidence when recruiting new
> > > > committers. After all the write access of committership is about to
> the
> > > > code and understand the consequence of the responsibility -- which is
> > > > usually can be found in high-quality review history.
> > > >
> > > > Please let me know what you think.
> > > >
> > > > Tianqi
> > > >
> > >
> >
>

Re: [Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Tianqi Chen]

>
>  Many potential committers and
> PMC won’t interact with the non-Amazonians at all (since there are so few),
> so they’d be relegated to obscurity and hopelessness by default.
>

If potential contributors do not comes from Amazon, then the Amazonian PMC
can nominate them :)  If the potential contributors does comes from Amazon,
then it is not a bad thing to interact with bigger part of the community. I
can expect that as more non-Amazonian contributors get nonimated, this
would make the process more healthy.

Like neural networks, any guideline can be played in adverserial fashion
(e.g. in the case of the gray areas). I think having a goodwill to push the
guideline will understandably make people to work together.

Afterall, this is an Apache project that should goes beyond a single company

Tianqi

>
>
>
> On Sun, Oct 21, 2018 at 5:06 PM Steffen Rochel 
> wrote:
>
> > Hi Tianqi -
> > +1 . I like the idea to grow diversity at the project and encourage
> > communication beyond people sitting next to each other. I also support
> the
> > way you described as guideline, not has a hard rule. I think it is
> > important we focus on merit and contributions when evaluating nominee for
> > committer and PPMC.
> >
> > Carin started a draft document for revised criteria for committer and
> PPMC
> > membership
> > <
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member+Proposal
> > >.
> > I suggest to contribute, provide feedback and suggestion including your
> > proposal.
> >
> > Steffen
> >
> > On Sun, Oct 21, 2018 at 10:22 AM Tianqi Chen  wrote:
> >
> > > Dear MXNet Community:
> > >
> > > There has been a great discussion going on in terms of
> > > PMC/Committer Criteria.  As a community move forward, it is important
> to
> > > make the community inclusive to everyone and encourage folks to work
> > > together.
> > >
> > > I want to propose the following proposal courtesy: when a PMC proposes
> a
> > > committer/PMC member, for courtesy of the community, she/he should only
> > > propose a person from a different organization(company).
> > >
> > > The idea behind that is that the Apache project goes beyond a single
> > > organization, it is important to recognize others, including those
> from a
> > > different organization in the community, and get your merit being
> > > recognized by others.
> > >
> > > Admittedly, this would also give more "power" to the PMC members from
> > > minority organizations -- which I think is a good thing. This might
> also
> > > encourage everyone to work together and talk to folks who are beyond
> your
> > > next door
> > >
> > > Tianqi
> > >
> >
>

[Discussion] PMC and Committer Courtesy: Only Propose Candidate in a Different Organization

[Tianqi Chen]

Dear MXNet Community:

There has been a great discussion going on in terms of
PMC/Committer Criteria.  As a community move forward, it is important to
make the community inclusive to everyone and encourage folks to work
together.

I want to propose the following proposal courtesy: when a PMC proposes a
committer/PMC member, for courtesy of the community, she/he should only
propose a person from a different organization(company).

The idea behind that is that the Apache project goes beyond a single
organization, it is important to recognize others, including those from a
different organization in the community, and get your merit being
recognized by others.

Admittedly, this would also give more "power" to the PMC members from
minority organizations -- which I think is a good thing. This might also
encourage everyone to work together and talk to folks who are beyond your
next door

Tianqi

Re: [Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

Also re another email-thread(I sent out one with my institutional email
which get blocked initially, so this one was a bit duplication of that). I
think it should really be the job of committers to recognize potential
reviewers, github also makes it easier to do so, e.g.
https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=reviewed-by%3Apiiswrong

Tianqi

On Fri, Oct 19, 2018 at 12:05 PM Carin Meier  wrote:

> +1 Great idea. Adding a name to the contributor list is a good idea. Also,
> I've found that thanking the person for the review on the PR is another way
> to express gratitude for their time and effort.
>
> On Fri, Oct 19, 2018 at 2:51 PM Tianqi Chen  wrote:
>
> > Dear MXNet Community:
> >
> > There is a great discussion going on in terms of lowering the barrier of
> > entries and encourage more contribution to the project.  One of the
> general
> > goals is to encourage a broader pool of contributions. I want to make the
> > following proposal:
> >
> > Besides Committers and PMC, let us also recognize Reviewers in the
> > community.  This is a "pseudo role" as there is no such official role in
> > Apache. But I want to explore the possibility of recognizing active
> > reviewers for example, by adding a list of names in the contributor list.
> > In general, I find it is really helpful to have more code reviews.
> > Recognizing good reviewers early enables us to find committer candidates,
> > and encourage them to contribute and understand what is the bar of code
> > quality that is required to merge the code.
> >
> > This can provide the community with more evidence when recruiting new
> > committers. After all the write access of committership is about to the
> > code and understand the consequence of the responsibility -- which is
> > usually can be found in high-quality review history.
> >
> > Please let me know what you think.
> >
> > Tianqi
> >
>

[Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

Dear MXNet Community:

There is a great discussion going on in terms of lowering the barrier of
entries and encourage more contribution to the project.  One of the general
goals is to encourage a broader pool of contributions. I want to make the
following proposal:

Besides Committers and PMC, let us also recognize Reviewers in the
community.  This is a "pseudo role" as there is no such official role in
Apache. But I want to explore the possibility of recognising active
reviewers for example, by adding a list of names in the contributor list.
In general, I find it is really helpful to have more code reviews.
Recognising good reviewers early enables us to find candidate for
committers, and encourage them to contribute and understand what is the bar
of code quality that is required to merge the code.

This can provide the community more evidence when recruiting new
committers. After all committers is about write access to the code and
understand the consequence of the responsibility -- which is usually can be
found in high quality reviews.

Please let me know what you think.
Tianqi

[Discussion] Recognise Reviewers, Besides Committers and PMC

[Tianqi Chen]

Dear MXNet Community:

There is a great discussion going on in terms of lowering the barrier of
entries and encourage more contribution to the project.  One of the general
goals is to encourage a broader pool of contributions. I want to make the
following proposal:

Besides Committers and PMC, let us also recognize Reviewers in the
community.  This is a "pseudo role" as there is no such official role in
Apache. But I want to explore the possibility of recognizing active
reviewers for example, by adding a list of names in the contributor list.
In general, I find it is really helpful to have more code reviews.
Recognizing good reviewers early enables us to find committer candidates,
and encourage them to contribute and understand what is the bar of code
quality that is required to merge the code.

This can provide the community with more evidence when recruiting new
committers. After all the write access of committership is about to the
code and understand the consequence of the responsibility -- which is
usually can be found in high-quality review history.

Please let me know what you think.

Tianqi

Re: Which merge option to use on the Import Julia binding PR?

[Tianqi Chen]

One of the main reason for a rebase merge is that it preserves the commit
history of the MXNet.jl package contributors, and given that the project
has been evolved since 2015 and has always been a high-quality language
module for MXNet.

I think we should take an exception here to preserve the commit history of
each individual contributors to the Julia binding and welcome them to the
community.

Tianqi

On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
wrote:

> In this particular case, I would suggest rebase and merge.
>
> The main reasoning is that the commit log of the Julia binding is not
> simple WIP commits, every commit there has been done through testcases and
> it is important for us to respect the developer of the effort. It is also
> good to trace back the history of the commits more easily.
>
> Tianqi
>
>
> Tianqi
>
> On Wed, Sep 26, 2018 at 5:34 PM Carin Meier  wrote:
>
>> Chiyuan,
>>
>> Thanks for the prompt to find some clarity of the pros and cons of each. I
>> think that will help drive us to the right decision. I think some of those
>> reasons are the ones you listed. I will take a stab below at outlining
>> what
>> I see. Feel free to chime in if I missed any.
>>
>> *Squash and Merge*
>>   *Pros* - It is the project standard
>>   - It will provide one commit for the feature and lessen the need
>> for 700+ commits rebased on top of master.
>>  - It is easier for a user to do git log to browse commits and see
>> what was features were added.
>>   *Cons* - I don't know how github would handle squashing all those commit
>> messages into one. Will it be too much?
>> - You lose the granularity of the features individual commits
>>
>> *Rebase and Merge*
>>  * Pros *- You don't have a huge commit message with one commit
>>   -  You do have the granularity of the individual features of the
>> commit
>>  * Cons *- It is not the project standard
>>- You have 700+ commits on top of master that might be harder
>> to
>> see the ones that went in right before. (like someone browsing commits)
>>
>> On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang  wrote:
>>
>> > Hi Carin,
>> >
>> > Can you clarify the pros and cons of the two approaches? Is the main
>> > concern here about logistics (e.g. preserving the history of the
>> original
>> > repo and developments) or technical issue (e.g. using squash might end
>> up
>> > with a hge commit message that might be difficult or hard to
>> handle)?
>> >
>> > I think it might not be very likely that someone is going to cherry pick
>> > revert some of the commits. But preserving the commit history is still
>> > useful in case one need to trace the change or bisect for some
>> regression
>> > bugs, etc.
>> >
>> > Just to provide some context: the PR actually contains 700+ commits,
>> and it
>> > dates back to 2015. The development of the Julia binding started in the
>> > early stage of MXNet. We started with a separate repo due to the
>> > requirement of the package system of julia.
>> >
>> > Best,
>> > Chiyuan
>> >
>> > On Wed, Sep 26, 2018 at 3:41 PM Carin Meier 
>> wrote:
>> >
>> > > The Import Julia binding PR ,(
>> > > https://github.com/apache/incubator-mxnet/pull/10149), is getting
>> very
>> > > close to being merged. Because of the large number of commits there
>> was a
>> > > suggestion not to use the usual "Squash and Merge".  The only option
>> > would
>> > > be "Rebase and Merge" since merging with a merge commit is not enabled
>> > for
>> > > the project.
>> > >
>> > > *Squash and Merge* - The commits from this branch will be combined
>> into
>> > one
>> > > commit in the base branch (With all the commit messages combined)
>> > >
>> > > *Rebase and Merge* - The commits from this branch will be rebased and
>> > added
>> > > to the base branch
>> > >
>> > > The PR is over 250+ commits (Github won't show all of them)
>> > >
>> > > Thoughts about how we should handle the merge?
>> > >
>> > > Thanks,
>> > > Carin
>> > >
>> >
>>
>

Re: Which merge option to use on the Import Julia binding PR?

[Tianqi Chen]

In this particular case, I would suggest rebase and merge.

The main reasoning is that the commit log of the Julia binding is not
simple WIP commits, every commit there has been done through testcases and
it is important for us to respect the developer of the effort. It is also
good to trace back the history of the commits more easily.

Tianqi


Tianqi

On Wed, Sep 26, 2018 at 5:34 PM Carin Meier  wrote:

> Chiyuan,
>
> Thanks for the prompt to find some clarity of the pros and cons of each. I
> think that will help drive us to the right decision. I think some of those
> reasons are the ones you listed. I will take a stab below at outlining what
> I see. Feel free to chime in if I missed any.
>
> *Squash and Merge*
>   *Pros* - It is the project standard
>   - It will provide one commit for the feature and lessen the need
> for 700+ commits rebased on top of master.
>  - It is easier for a user to do git log to browse commits and see
> what was features were added.
>   *Cons* - I don't know how github would handle squashing all those commit
> messages into one. Will it be too much?
> - You lose the granularity of the features individual commits
>
> *Rebase and Merge*
>  * Pros *- You don't have a huge commit message with one commit
>   -  You do have the granularity of the individual features of the
> commit
>  * Cons *- It is not the project standard
>- You have 700+ commits on top of master that might be harder to
> see the ones that went in right before. (like someone browsing commits)
>
> On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang  wrote:
>
> > Hi Carin,
> >
> > Can you clarify the pros and cons of the two approaches? Is the main
> > concern here about logistics (e.g. preserving the history of the original
> > repo and developments) or technical issue (e.g. using squash might end up
> > with a hge commit message that might be difficult or hard to handle)?
> >
> > I think it might not be very likely that someone is going to cherry pick
> > revert some of the commits. But preserving the commit history is still
> > useful in case one need to trace the change or bisect for some regression
> > bugs, etc.
> >
> > Just to provide some context: the PR actually contains 700+ commits, and
> it
> > dates back to 2015. The development of the Julia binding started in the
> > early stage of MXNet. We started with a separate repo due to the
> > requirement of the package system of julia.
> >
> > Best,
> > Chiyuan
> >
> > On Wed, Sep 26, 2018 at 3:41 PM Carin Meier 
> wrote:
> >
> > > The Import Julia binding PR ,(
> > > https://github.com/apache/incubator-mxnet/pull/10149), is getting very
> > > close to being merged. Because of the large number of commits there
> was a
> > > suggestion not to use the usual "Squash and Merge".  The only option
> > would
> > > be "Rebase and Merge" since merging with a merge commit is not enabled
> > for
> > > the project.
> > >
> > > *Squash and Merge* - The commits from this branch will be combined into
> > one
> > > commit in the base branch (With all the commit messages combined)
> > >
> > > *Rebase and Merge* - The commits from this branch will be rebased and
> > added
> > > to the base branch
> > >
> > > The PR is over 250+ commits (Github won't show all of them)
> > >
> > > Thoughts about how we should handle the merge?
> > >
> > > Thanks,
> > > Carin
> > >
> >
>

Re: Some feedback from MXNet Zhihu topic

[Tianqi Chen]

The key complain here is mainly about the clarity of the documents
themselves. Maybe it is time to focus on a single flavor of API that is
useful(Gluon) and highlight all the docs around that

Tianqi


On Wed, Sep 19, 2018 at 11:04 AM Qing Lan  wrote:

> Hi all,
>
> There was a trend topic in
> Zhihu (a famous Chinese Stackoverflow+Quora) asking about the status of
> MXNet in 2018 recently. Mu replied the thread and obtained more than 300+
> `like`.
> However there are a few concerns addressed in the comments of this thread,
> I have done some simple translation from Chinese to English:
>
> 1. Documentations! Until now, the online doc still contains:
> 1. Depreciated but not updated doc
> 2. Wrong documentation with poor description
> 3. Document in Alpha stage such as you must install `pip
> –pre` in order to run.
>
> 2. Examples! For Gluon specifically, many examples are still mixing
> Gluon/MXNet apis. The mixure of mx.sym, mx.nd mx.gluon confused the users
> of what is the right one to choose in order to get their model to work. As
> an example, Although Gluon made data encapsulation possible, still there
> are examples using mxn.io.ImageRecordIter with tens of params (feels like
> gluon examples are simply the copy from old Python examples).
>
> 3. Examples again! Comparing to PyTorch, there are a few examples I don't
> like in Gluon:
> 1. Available to run however the code structure is still
> very complicated. Such as example/image-classification/cifar10.py. It
> seemed like a consecutive code concatenation. In fact, these are just a
> series of layers mixed with model.fit. It makes user very hard to
> modify/extend the model.
> 2. Only available to run with certain settings. If users
> try to change a little bit in the model, crashes will happen. For example,
> the multi-gpu example in Gluon website, MXNet hide the logic that using
> batch size to change learning rate in a optimizer. A lot of newbies didn't
> know this fact and they would only find that the model stopped converging
> when batch size changed.
> 3. The worst scenario is the model itself just simply
> didn't work. Maintainers in the MXNet community didn't run the model (even
> no integration test) and merge the code directly. It makes the script not
> able run till somebody raise the issues and fix it.
>
> 4. The Community problem. The core advantage for MXNet is it's scalability
> and efficiency. However, the documentation of some tools are confusing.
> Here are two examples:
>
> 1. im2rec contains 2 versions, C++ (binary) and python.
> But nobody would thought that the argparse in these tools are different (in
> the meantime, there is no appropriate examples to compare with, users could
> only use them by guessing the usage).
>
> 2. How to combine MXNet distributed platform with
> supercomputing tool such as Slurm? How do we do profiling and how to debug.
> A couples of companies I knew thought of using MXNet for distributed
> training. Due to lack of examples and poor support from the community, they
> have to change their models into TensorFlow and Horovod.
>
> 5. The heavy code base. Most of the MXNet examples/source
> code/documentation/language binding are in a single repo. A git clone
> operation will cost tens of Mb. The New feature PR would takes longer time
> than expected. The poor reviewing response / rules keeps new contributors
> away from the community. I remember there was a call for
> document-improvement last year. The total timeline cost a user 3 months of
> time to merge into master. It almost equals to a release interval of
> Pytorch.
>
> 6. To Developers. There are very few people in the community discussed the
> improvement we can take to make MXNet more user-friendly. It's been so easy
> to trigger tens of stack issues during coding. Again, is that a requirement
> for MXNet users to be familiar with C++? The connection between Python and
> C lacks a IDE lint (maybe MXNet assume every developers as a VIM master).
> API/underlying implementation chaged frequently. People have to release
> their code with an achieved version of MXNet (such as TuSimple and MSRA).
> Let's take a look at PyTorch, an API used move tensor to device would raise
> a thorough discussion.
>
> There will be more comments translated to English and I will keep this
> thread updated…
> Thanks,
> Qing
>

Re: Some feedback from MXNet Zhihu topic

[Tianqi Chen]

Thanks for the great feedbacks. I want to point out though that the cost of
building Mxnet is mainly on the operators that sit on Mxnet repo, rather
than its submodules

Tianqi


On Thu, Sep 20, 2018 at 1:10 AM Naveen Swamy  wrote:

> Qing,
>
> this is so loaded and very specific suggestions. Thank you for bringing up
> here, since Apache MXNet is popular in China, It would be great if Mandrin
> speaking developers here could bring such feedback and user pain to the
> community's attention.
>
> 1. To capture specific API/Example/Tutorial that users have an issue on, Mu
> suggested in the past to add thumbs up/down on the website:
> https://issues.apache.org/jira/browse/MXNET-972
>
> 6. The heavy code base is not because of the code in the MXNet repo, its
> all the sub-modules that are added to the repo - I have had this problem
> too, to build MXNet i have to fetch and build the whole world that MXNet
> depends on and its dependency(sub within sub) - I think its time to revisit
> and refactor.
>
> For others I suggest you work with someone to create actionable JIRAs(may
> be Denis - because he knowledgable JIRA and creates nice actionable
> stories), it would be nice if these stories can contain many
> first-good-issue tasks for new contributors to pick up - creating
> standalone examples(from existing) is a great one for newbies to learn
> MXNet and contribute back.
>
> Examples are very important for someone to not only quickly learn but also
> extend/adopt to their own application, In Scala we(you) have added tests
> around Examples and actually use them as integration tests - we should do
> insist the same for new examples written or old examples that we touch .
>
> In Deep Learning what is more critical and could increase rapid adoption is
> to have the latest and greatest papers implemented as examples - this is a
> call for suggestions and Action to the community.
>
> Thanks, Naveen
>
>
> On Wed, Sep 19, 2018 at 10:39 PM, Aaron Markham  >
> wrote:
>
> > Thanks for this translation and feedback Qing!
> > I've addressed point 3 of the documentation feedback with this PR:
> > https://github.com/apache/incubator-mxnet/pull/12604
> > I'm not sure how to take the first two points without some explicit URLs
> > and examples, so if anyone has those I'd be happy to take a look if
> there's
> > some glitch vs missing or wrong docs.
> >
> > Also, I would agree that there should be some more simple examples. Often
> > times the examples are too complicated and unclear about what is
> important
> > or not. The audience targeting is for deep learning practitioners, not
> > "newbies".
> >
> > And on a related note, I'd really like to pull the Gluon stuff into the
> API
> > section. It's confusing as its own navigation item and orphaned
> > information. It could have a navigation entry at the top of the API list
> > like "Python: Gluon" or just "Gluon" then list "Python: Module" or just
> > "Python". Or running this the other way, the Gluon menu could have API
> and
> > Tutorials and be more fleshed out, though this is not my preference.
> Either
> > way, it needs some attention.
> >
> > Cheers,
> > Aaron
> >
> > On Wed, Sep 19, 2018 at 11:04 AM Qing Lan  wrote:
> >
> > > Hi all,
> > >
> > > There was a trend topic in
> > > Zhihu (a famous Chinese Stackoverflow+Quora) asking about the status of
> > > MXNet in 2018 recently. Mu replied the thread and obtained more than
> 300+
> > > `like`.
> > > However there are a few concerns addressed in the comments of this
> > thread,
> > > I have done some simple translation from Chinese to English:
> > >
> > > 1. Documentations! Until now, the online doc still contains:
> > > 1. Depreciated but not updated doc
> > > 2. Wrong documentation with poor description
> > > 3. Document in Alpha stage such as you must install
> `pip
> > > –pre` in order to run.
> > >
> > > 2. Examples! For Gluon specifically, many examples are still mixing
> > > Gluon/MXNet apis. The mixure of mx.sym, mx.nd mx.gluon confused the
> users
> > > of what is the right one to choose in order to get their model to work.
> > As
> > > an example, Although Gluon made data encapsulation possible, still
> there
> > > are examples using mxn.io.ImageRecordIter with tens of params (feels
> like
> > > gluon examples are simply the copy from old Python examples).
> > >
> > > 3. Examples again! Comparing to PyTorch, there are a few examples I
> don't
> > > like in Gluon:
> > > 1. Available to run however the code structure is still
> > > very complicated. Such as example/image-classification/cifar10.py. It
> > > seemed like a consecutive code concatenation. In fact, these are just a
> > > series of layers mixed with model.fit. It makes user very hard to
> > > modify/extend the model.
> > > 2. Only available to run with certain settings. If
> users
> > > try to change a little bit in the model, 

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

[Tianqi Chen]

Alrite, then I think it is fine as long as we can kept up with build speed
without timeout.


Tianqi

On Wed, Sep 5, 2018 at 9:14 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Travis actually has explicit support for ccache, it's a platform feature.
> I've run it and it seems to work quite well.  See for example this build:
> https://travis-ci.org/KellenSunderland/incubator-mxnet/builds/424768656
>
> On Wed, Sep 5, 2018 at 7:10 PM Tianqi Chen 
> wrote:
>
> > Travis it self is stateless, which means ccache is not likely going to
> > work. As far as I understand, if jenkins master is in the public domain,
> > you do not need to setup a vpn to the subset of the master.
> >
> > As for versions of MacOS, we are likely going to be fine with one
> version,
> > as usually the 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 ccache that it won't
> timeout
> > > when running tests, but even that is questionable.  In my private
> testing
> > > it was running in about 35 minutes and the global timeout for Travis
> jobs
> > > is 45 minutes.  I'd say let's run it for a few builds and see how it
> > goes.
> > > It won't be enabled in a mode that blocks PRs any time soon.
> > >
> > > I don't think physical hardware is a great solution.  We would have to
> > > purchase the hardware, then maintain security updates, install
> different
> > > versions of XCode / MacOS, setup a vpn to our jenkins master, etc.  I
> > would
> > > also worry that if the machine goes down for whatever reason it would
> > block
> > > PRs, and someone would have to be physically present to turn it back
> on.
> > > Even assuming we set all the hardware up it's still not scalable so
> we'd
> > > have to over-provision.
> > >
> > > I'm hoping the Travis solution works for the time being. If it doesn't
> > > we'll have to take a look at a few other options, but I've spent a fair
> > > amount of time thinking about this and I don't think there are any good
> > > options that don't have trade-offs.
> > >
> > > @Lin: Great!  Thanks for the offer.  There'll be a few features we want
> > to
> > > re-enable once the Job gets hooked up again.  I'll ping you when it's
> > ready
> > > and see if there's anything you think would be interesting to help
> with.
> > >
> > > -Kellen
> > >
> > > On Wed, Sep 5, 2018 at 6:58 PM Lin Yuan  wrote:
> > >
> > > > Hi Kellen,
> > > >
> > > > I would love to contribute. Please let me know if you have any
> > particular
> > > > work item that I can help.
> > > >
> > > > Best,
> > > >
> > > > Lin
> > > >
> > > > On Wed, Sep 5, 2018 at 9:51 AM Tianqi Chen  >
> > > > wrote:
> > > >
> > > > > is it possible for us to get a MacBook and hook it to the current
> > > Jenkins
> > > > > CI? Travis OSX usually build from 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
> > > > > any
> > > > > > features you'd like tested.  We are using the travis image
> xcode9.4
> > > > which
> > > > > > is based on MacOS 10.13.
> > > > > >
> > > > > > On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan 
> > wrote:
> > > > > >
> > > > > > > Hi Kellen,
> > > > > > >
> > > > > > > Many thanks for your and Marco's effort! I think this is a very
> > > > crucial
> > > > > > > piece to improve MXNet stability.
> > > > > > >
> > > > > > > To add some data points:
> > > > > > > 1) Customers using CoreML to MXNet converter were blocked for a
> > > while
> > > > > > > because the converter was broken and no unit test was in place
> to
> > > &

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

[Tianqi Chen]

Travis it self is stateless, which means ccache is not likely going to
work. As far as I understand, if jenkins master is in the public domain,
you do not need to setup a vpn to the subset of the master.

As for versions of MacOS, we are likely going to be fine with one version,
as usually the 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 ccache that it won't timeout
> when running tests, but even that is questionable.  In my private testing
> it was running in about 35 minutes and the global timeout for Travis jobs
> is 45 minutes.  I'd say let's run it for a few builds and see how it goes.
> It won't be enabled in a mode that blocks PRs any time soon.
>
> I don't think physical hardware is a great solution.  We would have to
> purchase the hardware, then maintain security updates, install different
> versions of XCode / MacOS, setup a vpn to our jenkins master, etc.  I would
> also worry that if the machine goes down for whatever reason it would block
> PRs, and someone would have to be physically present to turn it back on.
> Even assuming we set all the hardware up it's still not scalable so we'd
> have to over-provision.
>
> I'm hoping the Travis solution works for the time being. If it doesn't
> we'll have to take a look at a few other options, but I've spent a fair
> amount of time thinking about this and I don't think there are any good
> options that don't have trade-offs.
>
> @Lin: Great!  Thanks for the offer.  There'll be a few features we want to
> re-enable once the Job gets hooked up again.  I'll ping you when it's ready
> and see if there's anything you think would be interesting to help with.
>
> -Kellen
>
> On Wed, Sep 5, 2018 at 6:58 PM Lin Yuan  wrote:
>
> > Hi Kellen,
> >
> > I would love to contribute. Please let me know if you have any particular
> > work item that I can help.
> >
> > Best,
> >
> > Lin
> >
> > On Wed, Sep 5, 2018 at 9:51 AM Tianqi Chen 
> > wrote:
> >
> > > is it possible for us to get a MacBook and hook it to the current
> Jenkins
> > > CI? Travis OSX usually build from 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
> > > any
> > > > features you'd like tested.  We are using the travis image xcode9.4
> > which
> > > > is based on MacOS 10.13.
> > > >
> > > > On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan  wrote:
> > > >
> > > > > Hi Kellen,
> > > > >
> > > > > Many thanks for your and Marco's effort! I think this is a very
> > crucial
> > > > > piece to improve MXNet stability.
> > > > >
> > > > > To add some data points:
> > > > > 1) Customers using CoreML to MXNet converter were blocked for a
> while
> > > > > because the converter was broken and no unit test was in place to
> > > detect
> > > > > that.
> > > > > 2) Developers on Mac cannot verify their local commits because some
> > > unit
> > > > > tests on master were broken. This wasted much time and resource on
> > > > jenkins
> > > > > server to detect the failure.
> > > > > 3) Please consider running the CI on Mac OS 10.13 since this is the
> > > > minimum
> > > > > Mac OS version that supports CoreML (to support CoreML to 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 enabling Travis.
> > > > > >
> > > > > > I'm going to do a little experimental work together with Marco
> with
> > > the
> > > > > > goal of enabling a minimal Travis build that will run python
> tests.
> > > So
> > > > > far
> > > > > > I'v

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

[Tianqi Chen]

is it possible for us to get a MacBook and hook it to the current Jenkins
CI? Travis OSX usually build from 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 any
> features you'd like tested.  We are using the travis image xcode9.4 which
> is based on MacOS 10.13.
>
> On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan  wrote:
>
> > Hi Kellen,
> >
> > Many thanks for your and Marco's effort! I think this is a very crucial
> > piece to improve MXNet stability.
> >
> > To add some data points:
> > 1) Customers using CoreML to MXNet converter were blocked for a while
> > because the converter was broken and no unit test was in place to detect
> > that.
> > 2) Developers on Mac cannot verify their local commits because some unit
> > tests on master were broken. This wasted much time and resource on
> jenkins
> > server to detect the failure.
> > 3) Please consider running the CI on Mac OS 10.13 since this is the
> minimum
> > Mac OS version that supports CoreML (to support CoreML to 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 enabling Travis.
> > >
> > > I'm going to do a little experimental work together with Marco with the
> > > goal of enabling a minimal Travis build that will run python tests.  So
> > far
> > > I've verified that Travis will in fact find a bug that currently exists
> > in
> > > master and has been reproduced by MacOS clients.  This indicates to me
> > that
> > > adding Travis will add value to our CI.
> > >
> > > My best guess is that it might take us some iteration before we find a
> > > scalable way to integrate Travis.  Given this we're going to enable
> > Travis
> > > in non-blocking mode (i.e. failures are safe to ignore for the time
> > being).
> > >
> > > To help mitigate the risk of timeouts, and to remove legacy code I'm
> > going
> > > to re-create the travis.yml file from scratch.  I think it'll be much
> > less
> > > confusing if we only have working code related to Travis in our
> codebase,
> > > so that contributors won't have to experiment to see what is or isn't
> > > working.  We've got some great, but slightly out-of-date functionality
> in
> > > the legacy .travis.yml file.  I hope we can work together to update the
> > > legacy features, ensure they work with the current folder structure and
> > > also make sure the features run within Travis's 45 minute global time
> > > window.
> > >
> > > I'd also like to set expectations that this is strictly a volunteer
> > > effort.  I'd welcome help from the community for support and
> maintenance.
> > > The model downloading caching work particularly stands out to me 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 <
> > > marco.g.ab...@googlemail.com>
> > > 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 a minimum creating a clang build
> so
> > > > I've
> > > > > created a PR
> > > > > https://github.com/apache/incubator-mxnet/pull/9330/commits/
> > > > > 84089ea14123ebe4d66cc92e82a2d529cfbd8b19.
> > > > > My hope is this will catch many of the issues blocking OSX builds.
> > In
> > > > fact
> > > > > it already caught one issue.  If you guys are in favour I can
> remove
> > > the
> > > > > WIP and ask that it be merged.
> > > > >
> > > > > On Thu, Jan 4, 2018 at 6:29 PM, Chris Olivier <
> cjolivie...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Nope, I have been on vacation.
> > > > > >
> > > > > > On Thu, Jan 4, 2018 at 9:10 AM, kellen sunderland <
> > > > > > kellen.sunderl...@gmail.com> wrote:
> > > > > >
> > > > > > > Hope everyone had a good break.  Just wanted to check if there
> > were
> > > > > > further
> > > > > > > thoughts on OSX builds.  Chris, did you have time to look into
> > > > > > virtualizing
> > > > > > > Mac OS?  Would it make sense for us to put something in place
> in
> > > the
> > > > > > > interim e.g. the clang solution?
> > > > > > >
> > > > > > > On Tue, Dec 12, 2017 at 7:59 PM, de Abreu, Marco <
> > > mab...@amazon.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Thanks for looking into this, Chris! No hurries on that one,
> > > we’ll
> > > > > look
> > > > > > > > into it next stage when we add new system- and
> > > build-configurations
> > > > > to
> > > > > > > the
> > > > > > > > CI.
> > > > > > > >
> > > > > > > > On 12.12.17, 19:12, "Chris Olivier" 
> > > wrote:
> > > > > > > >
> > > > > > > > I am on vacation starting Thursday.
> > > > > > > >
> > > > 

Re: A question about fusion of TVM and MXNet/mshadow

[Tianqi Chen]

It is true that most of the current GPU code depends on mshadow. Porting
the operator code entirely over to TVM will take quite a huge effort. So a
more gradual path forward is to could be drop-in TVM to support cases that
it optimizes well(ARM, AMDGPU, accelerators) while keeping the old
infrastructure around for a while.

This is my part of the technical assessment. There is not yet a proposal
for a complete migration over TVM in the community.

Tianqi

On Wed, Aug 8, 2018 at 12:52 PM, Tao Sun  wrote:

> After some reading and learning of MXNet, I tentatively made the conclusion
> that the migration of MXNet to TVM, if it exists, has yet finished.
> Currently, mshadow, on which most of current operator code is still based,
> seems to carry out the most functionality that TVM can carry ultimately.
> Will anyone correct/confirm this conclusion? Will the community have a
> plan/calendar to migrate to TVM? Thanks.
>
>
> Tao Sun
>

Re: Help with understanding docs

[Tianqi Chen]

As far as I understand, these are packages that are build on top of gluon
and runs on MXNet, it is up to the maintainers of these packages as well
the the comitters to decide whether they want to put it into MXNet master.

I personally feel it is great to see ecosystem build and content on top of
what we are building

Tianqi
On Wed, Aug 8, 2018 at 12:26 PM Isabel Drost-Fromm 
wrote:

>
>
> Am 8. August 2018 21:17:44 MESZ schrieb Mu Li :
> >MXNet's website is http://mxnet.incubator.apache.org/. I own mxnet.io,
> >which was mxnet's main site before, but now we are using its subdomains
> >to
> >host various packages in the mxnet ecosystem.
>
> I'm still confused: There's what looks like content vital to the project
> owned and controlled privately by one project member? Is the intention to
> move that stuff over to mxnet.incubator or to keep it where it is?
>
> Isabel
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>

Re: [VOTE] Subscribe dev@ to Github Activities

[Tianqi Chen]

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 going on. The filtering mechanism means that it is
possible to alleviate this problem for those who don't want to see
"noise"(although most of them are not noises, but bugfixes, discussions
etc.).

Tianqi

On Wed, Jul 18, 2018 at 10:41 AM, Rahul Huilgol 
wrote:

> 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 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 all contributors feel inclusive under the frameworks of Apache
> > (including those who contribute and discuss through github, which is
> > currently the majority).
> >
> > On the other hand, the filtering mechanism would work for those who do
> not
> > want to receive the content.
> >
> > Tianqi
> >
> > On Wed, Jul 18, 2018 at 10:21 AM, Chris Olivier 
> > wrote:
> >
> > > 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.  seems this is a constant push from
> > day
> > > one.
> > >
> > >
> > > On Wed, Jul 18, 2018 at 9:39 AM Sheng Zha  wrote:
> > >
> > > > 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 contributors' life easier by decoupling the recognized forum
> > from
> > > > the technology they use, and that github contributors can easily
> > > > communicate with the community on the list.
> > > >
> > > > -sz
> > > >
> > > > On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> > > > christopher.bar...@analog.com> wrote:
> > > >
> > > > > 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 to avoid spamming dev with all GitHub
> > > > notifications?
> > > > > I think that if dev gets too much traffic, then people with casual
> > > > interest
> > > > > may find it easier to unsubscribe than to set up filters. Once
> > someone
> > > > > unsubscribes, they probably won't be coming back soon, so you
> should
> > be
> > > > > very careful with this.
> > > > >
> > > > > I don't see why artificially increasing the traffic on dev will do
> > > > > anything to grow the community in any case.
> > > > >
> > > > > - C
> > > > >
> > > > > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> > > > >
> > > > > 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 policy says "if it didn't happen in dev, it didn't
&g

Re: [VOTE] Subscribe dev@ to Github Activities

[Tianqi Chen]

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 all contributors feel inclusive under the frameworks of Apache
(including those who contribute and discuss through github, which is
currently the majority).

On the other hand, the filtering mechanism would work for those who do not
want to receive the content.

Tianqi

On Wed, Jul 18, 2018 at 10:21 AM, Chris Olivier 
wrote:

> 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.  seems this is a constant push from day
> one.
>
>
> On Wed, Jul 18, 2018 at 9:39 AM Sheng Zha  wrote:
>
> > 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 contributors' life easier by decoupling the recognized forum from
> > the technology they use, and that github contributors can easily
> > communicate with the community on the list.
> >
> > -sz
> >
> > On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > 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 to avoid spamming dev with all GitHub
> > notifications?
> > > I think that if dev gets too much traffic, then people with casual
> > interest
> > > may find it easier to unsubscribe than to set up filters. Once someone
> > > unsubscribes, they probably won't be coming back soon, so you should be
> > > very careful with this.
> > >
> > > I don't see why artificially increasing the traffic on dev will do
> > > anything to grow the community in any case.
> > >
> > > - C
> > >
> > > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> > >
> > > 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 policy says "if it didn't happen in dev, it didn't happen",
> > > let's
> > > forward all GitHub discussions to dev so those discussions would
> > count.
> > > That's the motivation for this vote.
> > >
> > > I think when people say there needs to be more discussions in the
> dev
> > > list,
> > > I assume they mean the kind of discussions that happen *before* a
> PR
> > is
> > > created or even before someone starts working on anything. I don't
> > > think
> > > people are asking an email for every activity on GitHub. The
> correct
> > > way to
> > > address the problem would be for committees/contributors to stop
> > > communicating in private channels (like Amazon or DMLC
> communication
> > > channels) and do those discussions in the dev list instead.
> > >
> > > Indu
> > >
> > >
> > > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> > > christopher.bar...@analog.com> wrote:
> > >
> > > > 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)
> > > >
> > > > 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 12:42 AM Rahul Huilgol <
> > > rahulhuil...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > 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

Re: [VOTE] Subscribe dev@ to Github Activities

[Tianqi Chen]

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 be good enough for people who do not want
to receive these messages, so I see there is no down side from doing this

Tianqi


On Wed, Jul 18, 2018 at 9:39 AM, Sheng Zha  wrote:

> 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 contributors' life easier by decoupling the recognized forum from
> the technology they use, and that github contributors can easily
> communicate with the community on the list.
>
> -sz
>
> On Wed, Jul 18, 2018 at 9:05 AM, Barber, Christopher <
> christopher.bar...@analog.com> wrote:
>
> > 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 to avoid spamming dev with all GitHub
> notifications?
> > I think that if dev gets too much traffic, then people with casual
> interest
> > may find it easier to unsubscribe than to set up filters. Once someone
> > unsubscribes, they probably won't be coming back soon, so you should be
> > very careful with this.
> >
> > I don't see why artificially increasing the traffic on dev will do
> > anything to grow the community in any case.
> >
> > - C
> >
> > On 7/18/18, 11:17 AM, "Indhu"  wrote:
> >
> > 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 policy says "if it didn't happen in dev, it didn't happen",
> > let's
> > forward all GitHub discussions to dev so those discussions would
> count.
> > That's the motivation for this vote.
> >
> > I think when people say there needs to be more discussions in the dev
> > list,
> > I assume they mean the kind of discussions that happen *before* a PR
> is
> > created or even before someone starts working on anything. I don't
> > think
> > people are asking an email for every activity on GitHub. The correct
> > way to
> > address the problem would be for committees/contributors to stop
> > communicating in private channels (like Amazon or DMLC communication
> > channels) and do those discussions in the dev list instead.
> >
> > Indu
> >
> >
> > On Wed, Jul 18, 2018, 5:51 AM Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > 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)
> > >
> > > 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 12:42 AM Rahul Huilgol <
> > rahulhuil...@gmail.com
> > > >
> > > wrote:
> > >
> > > > 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 mails
> > > > Current commits list for MXNet: 5329 mails
> > > > Making the proposed dev list for MXNet to be ~5677 mails.
> > > >
> > > > Sheng, even going by your comments that 1 of of those 4 mails
> > are
> > > relevant
> > > > for dev@, that's still a really high number of emails. (130
> > email
> > > lists
> > > > doesn't say anything if we ignore the actual number of emails
> > in
> > > those
> > > > lists, especially 

Re: [VOTE] Subscribe dev@ to Github Activities

[Tianqi Chen]

+1, most of issue and PR activities are about development, and they belong
to dev. It also helps us to recognizes contributors who are actively
contributing but less vocal via emails -- there are many of them.

Tianqi

On Tue, Jul 17, 2018 at 8:47 AM, Anirudh  wrote:

> -1
>
> The low signal to noise ratio would mean that we may miss important emails.
> Even with the different filters that we may setup for dev@, the emails
> would be too many to not miss the important ones. We would see more and
> more people starting a design discussion on an issue or PR. Because of the
> low signal to noise ratio on the dev@ list, many may miss these
> discussions.
>
> Slowly, this would erode the purpose of the dev@ list as this means that
> you don't really have to do anything explicitly on the dev@ list.
> You can start a design discussion on a github issue. You can start a
> vote/discussion on a github 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 vote on subscribing dev@ to Github activities. See
> > previous
> > > discussion thread here
> > >  > > bfd01f0b78d3cb44034f566442@%3Cdev.mxnet.apache.org%3E>
> > > .
> > >
> > > The vote lasts for three days and ends on 7/18/2018 at 9pm pst.
> > >
> > > -sz
> > >
> >
>

Re: Deprecate python 2

[Tianqi Chen]

FYI https://python3statement.org/

On Thu, Jul 12, 2018 at 3:00 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> CentOS 7, for example, does not offer stable Python 3 support. We're using
> an unstable version in our CI to verify it none the less. I think that's a
> hard stop for quite a few users.
>
> -Marco
>
> Pedro Larroy  schrieb am Do., 12. Juli 2018,
> 23:51:
>
> > Hi
> >
> > I would like to know your opinion in regards to deprecating and removing
> > Python 2. Maybe for MXNet 2.0 ?
> >
> > What's the reason to have support for Python2?
> >
> > Pedro.
> >
>

Re: Deprecate python 2

[Tianqi Chen]

I think we just need to be on side with the community. Most community plans
to deprecate python2 at beginning of 2019 and drop support at 2020

Tianqi

On Thu, Jul 12, 2018 at 2:51 PM, Pedro Larroy 
wrote:

> Hi
>
> I would like to know your opinion in regards to deprecating and removing
> Python 2. Maybe for MXNet 2.0 ?
>
> What's the reason to have support for Python2?
>
> Pedro.
>

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

[Tianqi Chen]

+1

On Thu, Jul 12, 2018 at 11:10 AM, Sheng Zha  wrote:

> 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 cons:
>
> Pros:
> - There have been many high quality discussions that happen on github to
> which the dev list can benefit.
> - Replies on update emails are reflected on the specific issue/PR.
> - Users can also choose to click on the link and go to github to
> participate in discussion.
> - We still have the ability to carry out dev@ only conversation.
>
> Cons:
> - Higher volume on dev list.
> - Some discussions might not be suitable for dev@. (though I can't think
> of
> why such conversation should happen on github either)
>
> -sz
>

Re: [LAZY VOTE] Test coverage of PRs

[Tianqi Chen]

While I think test coverage is a nice information to have. I would object
to using this as a metric to decide whether a PR should be merged.
Code-cov act as a mere coverage of APIs, which is a useful aspect, it can
be misleading in many cases, especially when such change involves
cross-language APIs and automatically generated wrapper.
Sometimes the code-cov shows a negative impact on coverage while CI passes,
and the giving information was quite misleading if you just look at the PR
tabs

I would still trust the reviewer's decision on the pull request merging.

Tianqi

On Wed, Jun 20, 2018 at 7:14 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> Hello,
>
> I'd like to introduce test coverage metrics of PRs using
> https://codecov.io/.
> This tool will aggregate coverage reports across multiple runs, platforms
> and technologies and gives contributors as well as reviewers a new tool
> that allows to improve the quality of a pull request.
>
> Since we need to gather some data first, I'd like to request merging
> https://github.com/apache/incubator-mxnet/pull/11344. This will enable
> publishing the coverage data to the service and have no impact on your PRs
> - it will just allow me to assess the quality of the service in the
> background while I come up with a full integration design. My initial plan
> is to start with coverage across Python and C++ and then, with the help of
> our community, extend the report across all our supported languages.
>
> Does anybody object to having us gather this data in the background?
>
> Best regards,
> Marco
>

Re: users@mxnet

[Tianqi Chen]

IMHO, the approach(mail list or discuss) have nothing to do with the
popularity of the project.  If you look at TF or pytorch you mentioned.
Pytorch uses discuss forum and slack, tf uses stackoverflow for support.
Both are popular but not adopting maillist. Note that I know both are both
not apache projects, but just to show that the popularity of the project do
not necessarily have to go with the setup of maillist


Tianqi


On Mon, Jun 18, 2018 at 11:42 AM Sebastian  wrote:

> I am puzzled by the reluctance of this project to setup a user
> mailinglist to be honest.
>
> MXNet has major issues with attracting a community outside of Amazon
> (whenever I hear folks talking about deep learning, they usually mention
> tensorflow, pytorch and keras, but I rarely hear someone talk about
> MXNet). At the same time, there is so much resistance to adopt practices
> that are successfully used by many high-profile toplevel projects...
>
> -s
>
> On 18.06.2018 20:37, Timur Shenkao wrote:
> > Facebook is definitely a bad idea: we will be dependent on third party
> > provider + unclear who & how manages such group etc.
> > Forum + Confluence + Slack is  much better then.
> >
> > On Mon, Jun 18, 2018 at 7:17 PM, Ivan Serdyuk <
> local.tourist.k...@gmail.com>
> > wrote:
> >
> >> Greetings Barber, Christopher. I had an idea to move out some
> discussions,
> >> covering Java and Scala API, to Facebook. So if somewhere exists a local
> >> JUG or Scala user group - they could reflect the topic of discussion.
> But
> >> background stuff could take place on mailing lists, Slack, forum,
> whatever.
> >> The reverse mechanism could be used to involve new committers, as well
> (so
> >> they would appear as presented newcomers, as for contributions).
> >>
> >> Regards
> >> Ivan
> >>
> >> On Mon, Jun 18, 2018 at 8:40 PM, Barber, Christopher <
> >> christopher.bar...@analog.com> wrote:
> >>
> >>> I don't understand why you would want a users mailing list when you
> >>> already have discussion forums. Users that want to be notified of new
> >> posts
> >>> on the forum can configure their notification preferences
> appropriately.
> >>> The traffic on the forums is already pretty low. I would think you
> would
> >>> not want to dilute that further.
> >>>
> >>> Christopher
> >>>
> >>> On 6/18/18, 1:27 PM, "Jim Jagielski"  wrote:
> >>>
> >>>  users@ mailing lists have great societal advantages that one
> >>> shouldn't ignore...
> >>>
> >>>  And it's not like this is the only project with "multiple"
> >>> communication choices for users. Most, if not all, projects have
> users@in
> >>> addition to such supplemental methods as IRC channels, a forum, etc...
> >> It's
> >>> about making it easy to have as many users as possible and as many
> >>> potential ways for users to communicate. It's not confusing; it's
> >>> empowering :)
> >>>
> >>>  > On Jun 18, 2018, at 1:19 PM, Tianqi Chen <
> tqc...@cs.washington.edu
> >>>
> >>> wrote:
> >>>  >
> >>>  > The problem of having multiple separate channels of
> communication
> >> is
> >>> that
> >>>  > users get confused, and the cost of maintenance goes up(people
> have
> >>> to
> >>>  > watch both). As the current community was at discuss forum and
> many
> >>> users
> >>>  > prefer it, having a mail-list is only a burden we will bring
> >>>  >
> >>>  > Tianqi
> >>>  >
> >>>  > On Mon, Jun 18, 2018 at 9:48 AM, Jim Jagielski  >
> >>> wrote:
> >>>  >
> >>>  >> IMO, that is the wrong way to look at it.
> >>>  >>
> >>>  >> A users@ mailing list is a great, easy, low-cost and
> low-overhead
> >>> way of
> >>>  >> *increasing* the user community and providing an extra level of
> >>> support.
> >>>  >> Unless there is "strong evidence" that this is NOT the case, I
> >> would
> >>>  >> recommend we create the list.
> >>>  >>
> >>>  >>> On Jun 16, 2018, at 12:28 AM, Tianqi Chen <
> >>> tqc...@cs.washington.edu>
> >&

Re: users@mxnet

[Tianqi Chen]

I don't want to argue here, as "Apache way" also says VOTE should not be a
way to enforce our opinion, and consensus need to be reached through
discussion

Thanks!

Tianqi

On Fri, Jun 15, 2018 at 9:41 PM, Tianqi Chen 
wrote:

> Then who should represent the users who are using the forums but not the
> mail-list? I personally think it is a bit abuse use of the term "Apache
> way" to force our mind into the entire community... Maybe I am wrong..
>
> Tianqi
>
> On Fri, Jun 15, 2018 at 9:39 PM, Sergio Fernández 
> wrote:
>
>> Well, I do respect what you discussed in that meetup, if course. But for
>> those who weren't there, maybe the decision taken what a bit bias.
>>
>> In Apache we like to say that "if it didn't happen on the mailing list s,
>> it didn't happen" ;-)
>>
>> Look like there are different feelings about this. Should I cast a VOTE?
>>
>>
>> On Fri, Jun 15, 2018, 21:27 Tianqi Chen  wrote:
>>
>> > I do think we are targeting all the community, but we must also agree
>> that
>> > the voice of users from the meetup is a representative sample of users'
>> > demand, and it is important that we respect that.
>> >
>> > Tianqi
>> >
>> > On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández 
>> > wrote:
>> >
>> > > Are we targeting just Seattle as our community? I really hope we are
>> > > thinking a bit beyond that...
>> > >
>> > > On Fri, Jun 15, 2018, 21:22 Tianqi Chen 
>> > wrote:
>> > >
>> > > > I remember last time during the mxnet meetup in Seattle, we did a
>> > survey,
>> > > > and most users preferred the current discuss forum. So I would say
>> we
>> > > stick
>> > > > with that given the user community prefers that
>> > > >
>> > > > Tianqi
>> > > >
>> > > > On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández <
>> wik...@apache.org>
>> > > > wrote:
>> > > >
>> > > > > Then, if everybody agree, let's request the mailing list creation
>> to
>> > > > INFRA
>> > > > > ;-)
>> > > > >
>> > > > > Marco, I wouldn't do that. Typically developers are also
>> subscribed
>> > > > there,
>> > > > > since they may be the most informed people for answering users'
>> > > > questions.
>> > > > > But the topics discussed there may not be of the interest for pure
>> > > > > development purposes. Some discussions will jump from users@ to
>> dev@
>> > ,
>> > > > but
>> > > > > at a different level. So I wouldn't forward one mailing list to
>> the
>> > > > other.
>> > > > >
>> > > > > On Fri, Jun 15, 2018, 21:01 Marco de Abreu
>> > > > >  wrote:
>> > > > >
>> > > > > > I think nobody was opposed to it in the past, right?
>> > > > > >
>> > > > > > I'd propose that all emails automatically get copied to dev@ to
>> > > ensure
>> > > > > > high
>> > > > > > visibility initially. What do you think?
>> > > > > >
>> > > > > > Sebastian  schrieb am Fr., 15. Juni 2018,
>> 20:51:
>> > > > > >
>> > > > > > > I have already proposed this many times in the past and would
>> > > > strongly
>> > > > > > > encourage it.
>> > > > > > >
>> > > > > > > -s
>> > > > > > >
>> > > > > > > On 15.06.2018 21:56, Sergio Fernández wrote:
>> > > > > > > > Hi,
>> > > > > > > >
>> > > > > > > > is there any good reason why the podling doesn't have a
>> users@
>> > > > > mailing
>> > > > > > > list
>> > > > > > > > yet?
>> > > > > > > >
>> > > > > > > > Honestly speaking, I'm not a big fan of the other tools the
>> > > podling
>> > > > > is
>> > > > > > > > using. Slack and Web forums a cool tools, and I used them a
>> lot
>> > > in
>> > > > > > other
>> > > > > > > > contexts. But when it comes to transparency and community,
>> > > mailing
>> > > > > > lists
>> > > > > > > > play a crucial role in the Apache Way.
>> > > > > > > >
>> > > > > > > > Users are the most important asset a project can have. Even
>> > more
>> > > > than
>> > > > > > > > developers, believe me. So I think it's time to create a
>> users@
>> > > > > > mailing
>> > > > > > > > list for to helping MXNet grow its community beyong the core
>> > > team.
>> > > > > > > >
>> > > > > > > > Cheers,
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>