[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

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

[Carin Meier]

+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] Recognise Reviewers, Besides Committers and PMC

[Naveen Swamy]

+1
reviews are great contributions given that it takes good understanding and
investment of time to provide insightful feedback.

On Fri, Oct 19, 2018 at 11:51 AM 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 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

Python API docs issues

[Aaron Markham]

Hello everyone!

I'm writing this note to raise awareness about some issues I'm seeing with
the Python API docs. While some of the issues can be traced back prior to
v1.3.0, the biggest issue of docs not rendering is fairly recent.
At a high level, Sphinx (our Python API docs generator) is getting confused
with a couple of things:
1. Folder changes (moving optimizer.py to /optimizer/, and io.py to /io/,
etc.)
2. Ambiguous references (where ndarray, type, shape, name, etc are declared
in different modules)

This is leading the Python docs to link up to the wrong place, or not link
up at all, or not generate at all.
If you didn't know, most of the API reference is auto-generated with about
two lines of rst that invokes Sphinx to do its thing. Except now Sphinx is
not doing what it's supposed do.

I've done a couple of workaround to fix the docs in areas that were
reported broken - by manually specifying the members of the API that should
be generated and manually linking up parameters, but I get this nagging
feeling that this could be fixed upstream. The init functions, the
importing, or ...? I don't really know, but Sphinx is unhappy and the docs
are suffering. Or maybe since the project is growing, we have give Sphinx a
little more TLC and be very good at being specific in the documentation.

I've documented what I've been seeing in some recent PRs and issues.

* Start here with the Python IO API since I've provided several links to
tour the two "Sphinx confusion" issues I previously mentioned.
https://github.com/apache/incubator-mxnet/pull/12871

* I also reported Sphinx not being able to access shorthand methods in
other PR where I fixed the test_utils and visualization docs. Looks at the
comments.
https://github.com/apache/incubator-mxnet/pull/12455
Note that mxnet.viz doesn't work but mxnet.visualization does... for
Sphinx. But everyone else can use mxnet.viz. What's up with that? I found
this pretty strange.

* This happened again with the ONNX import_model function. I deployed a
workaround so the ONNX docs were at least functional. It is reported here:
https://github.com/apache/incubator-mxnet/issues/12318

* Ndarray docs are messed up right now. Reported here:
https://github.com/apache/incubator-mxnet/issues/12829

I can probably fix the Ndarray API docs using the same pattern I used for
the IO API, but I don't want to go down this path too far when there might
be a simple solution. Otherwise, it seems pretty clear that every .py file
and every .md file for the Python API will need some updating.

Thoughts? Any Sphinx whisperers out there?

Thanks!
Aaron

Re: Include MKLDNN into default mxnet pip package

[Pedro Larroy]

I did  pip install mxnet-mkl==1.3.1b20181018 on an AMD Ryzen 1950X and unit
tests are passing.

Is this build using AVX512?  in /proc/cpuinfo I see only "avx" flag.
There's no "avx2" like on recent intel cpus.

Pedro.

On Fri, Oct 19, 2018 at 5:12 PM Hagay Lupesko  wrote:

> Awesome collaborative effort across many contributors and companies!
>
> The boost is impressive and for MXNet users to get this boost "out of the
> box" is a great benefit and makes MXNet an even better choice.
>
> Alex - can you clarify whether there are any down sides with regards to
> noon AVX-512 architectures, AMD CPUs, etc? Will it gracefully fallback?
>
> Hagay
>
>
> On Fri, Oct 19, 2018, 15:46 Sergio Fernández  wrote:
>
> > If there is no downside on platforms not supporting AVX512 instructions,
> > then +1
> >
> >
> > On Wed, Oct 17, 2018, 14:10 Alex Zai  wrote:
> >
> > > Hey all,
> > > We have been working hard these past few months to integrate and
> > stabilize
> > > Intel’s MKLDNN deep learning CPU accelerator into Mxnet and have made
> > > incredible progress. On CPUs with AVX512 instructions (such as c5.18x)
> we
> > > have seen performance increase up to 12x and on other platforms (Macs,
> > > AVX2) we seen a speedup of 1.5+. Full list of benchmarks can be found
> > here
> > > (
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95650764
> > >  and https://github.com/apache/incubator-mxnet/pull/12591).
> > >
> > > Currently, using this accelerator requires the developer to either pip
> > > install the mxnet-mkl version of mxnet or to build it themselves from
> > > source. Given that we should try to provide the best performance "out
> of
> > > the box” with mxnet we should include this in the default build. The
> > mkldnn
> > > library is included with in the pip package build so it does not
> require
> > an
> > > external dependency.
> > >
> > > There were concerns that MKLDNN could cause regressions on certain
> > > platforms (as it did with the tensorflow version a while back); but we
> > > added a env flag (MXNET_MKLDNN_ENABLED) that allows users to turn of
> this
> > > feature during runtime. Please bring up any other concerns you may have
> > and
> > > your thoughts on including this accelerator in the default build.
> > >
> > > Best,
> > > Alex
> > >
> >
>

Re: [DISCUSS] - Revisions to Committer Criteria

[Carin Meier]

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 
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  wrote:
>
> > Background:
> >
> > There is a desire to increase the committer pool and grow the community.
> > This thread is to discuss the possibility of revision the current
> committer
> > criteria in light of the following goals:
> >
> > - Make it easier to newcomers to be committers
> > - Recognize non-code contributions as paths to committership
> > - Open the door to separating levels of committer and PMC (discussed in
> > another thread)
> >
> > Current State:
> >
> > The current committer criteria is here
> > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> as
> > is modeled after the Hadoop committer criteria
> > https://hadoop.apache.org/committer_criteria.html
> >
> > Proposal:
> >
> > Model the MXNet path to committership and PMC after the Apache Beam
> project
> > https://beam.apache.org/contribute/become-a-committer/
> >
> > Short quote from page:
> >   =
> > An Apache Beam committer…
> > <
> >
> https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer
> > >
> >
> >- Takes many forms
> ><
> > https://beam.apache.org/contribute/become-a-committer/#takes-many-forms>
> >- Knows, upholds, and reinforces the Apache Software Foundation code
> of
> >conduct
> ><
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-apache-software-foundation-code-of-conduct
> > >
> >- Knows, upholds, and reinforces the responsibilities of an Apache
> >Software Foundation committer
> ><
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-responsibilities-of-an-apache-software-foundation-committer
> > >
> >- Knows, upholds, and reinforces the Beam community’s practices
> ><
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
> > >
> >- =
> ><
> >
> https://beam.apache.org/contribute/become-a-committer/#knows-upholds-and-reinforces-the-beam-communitys-practices
> > >
> >
> >
> > I believe if we merge our current committer criteria with this model it
> > will open  the path to committership to a wider pool, acknowledge that
> > there are multiple paths, and reinforce the ASF values and
> > responsibilities.
> >
> > The Beam model does not explicitly address a PMC level but we could add
> it
> > in in the same spirit of reinforcing the ASF responsibilities and values
> of
> > this level.
> >
> > Looking forward to feedback about this possible direction. If the
> community
> > is interested looking more into this direction I would be happy to create
> > of first draft of something more concrete to look at - (or if someone
> else
> > wants to take a crack at it too that would be great)
> >
> > - Carin
> >
>

Re: [LAZY VOTE]: rename dockerfiles s/.build.//

[Pedro Larroy]

Allright then, I closed that PR. Thanks for your feedback.

On Wed, Oct 17, 2018 at 9:06 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> May be of interest to people that we're trying get a good set of
> production-ready Dockerfiles (which I'm referring to as runtime Dockerfiles
> in this thread) with a PR open here:
> https://github.com/apache/incubator-mxnet/pull/12791 (thanks for updating
> these Meghna).
>
> On Wed, Oct 17, 2018 at 12:00 PM Naveen Swamy  wrote:
>
> > I agree with Kellen on not renaming the CI docker files (by renaming - i
> > think its implicit you can use these for production) i don't think we
> > should telling our users go use these bloated docker files, you could
> > create lean separate docker files for production use-case with only
> > necessary runtime packages.
> >
> > -1
> >
> > On Wed, Oct 17, 2018 at 11:48 AM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > Hey Pedro, sorry I still don't see a good reason to justify changing
> the
> > > filenames.  Renaming them to be less specific isn't going to explain to
> > > users what the purpose of the files is, and it could cause breakages
> with
> > > any system that refer to these files including external company's CI
> > > systems.  If I think of the benefits versus potential errors introduced
> > by
> > > making the change I see more potential risk than obvious benefits.  I
> > also
> > > feel that this change will make the difference between the runtime
> docker
> > > files and the CI docker files less clear to users, not more clear.  In
> > > general I think adding a descriptive README.md would server our
> purposed
> > > better here.  Happy to hear what others think.
> > >
> > > On Wed, Oct 17, 2018 at 6:45 AM Pedro Larroy <
> > pedro.larroy.li...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi Kellen, thank you for your response.
> > > >
> > > > Maybe I didn't explain myself correctly. The purpose of this
> > > infrastructure
> > > > is not changed.
> > > >
> > > > I'm not planning to use these Dockerfiles as MXNet docker containers
> > for
> > > > users to run MXNet, that is a separate concern.
> > > >
> > > > It is just that some of this Dockerfiles we use in CI to build, test
> > and
> > > > generate documentation, so are used as a runtime container as well.
> > Thus
> > > > i'm just changing the pathing for semantic reasons and remove the
> > .build.
> > > > which is just noise.
> > > >
> > > > As an example I would like to explain that we are about to merge the
> PR
> > > > which uses QEMU to run the unit tests, so there's an associated
> > > Dockerfile
> > > > which hosts the QEMU runtime environment used to execute the unit
> tests
> > > in
> > > > an ARM emulated machine. Thus makes little sense that these
> Dockerfiles
> > > are
> > > > called "build".  I don't know if my explanation changes your vote.
> > Either
> > > > way please let me know. Separating this change in a different PR was
> > > > suggested by several MXNet contributors during review.
> > > >
> > > > Pedro.
> > > >
> > > > On Wed, Oct 17, 2018 at 11:21 AM kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > > > -1. (non-binding)
> > > > >
> > > > > These Dockerfiles are very bloated and imo only useful for
> creating a
> > > > build
> > > > > environment or running tests.  Just as you wouldn't setup a server
> > for
> > > a
> > > > > service and then install 200 packages that may or may not be used
> for
> > > the
> > > > > service I wouldn't recommend using these Dockerfiles at runtime.
> > > Runtime
> > > > > Dockerfiles should in my opinion be as lightweight and suited to
> > their
> > > > task
> > > > > as possible.
> > > > >
> > > > > On Wed, Oct 17, 2018, 1:58 AM Hagay Lupesko 
> > wrote:
> > > > >
> > > > > > The PR provides a good explanation of this change and all code
> > > updates.
> > > > > > LGTM.
> > > > > >
> > > > > > On Tue, Oct 16, 2018 at 8:41 AM Pedro Larroy <
> > > > > pedro.larroy.li...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > I would like to rename the dockerfiles since they are used as a
> > > > runtime
> > > > > > > environment and not only as build as they were initially
> > intended.
> > > > > > >
> > > > > > > More info about the change in this PR:
> > > > > > > https://github.com/apache/incubator-mxnet/pull/12423/files
> > > > > > >
> > > > > > >
> > > > > > > Pedro.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Include MKLDNN into default mxnet pip package

[Hagay Lupesko]

Awesome collaborative effort across many contributors and companies!

The boost is impressive and for MXNet users to get this boost "out of the
box" is a great benefit and makes MXNet an even better choice.

Alex - can you clarify whether there are any down sides with regards to
noon AVX-512 architectures, AMD CPUs, etc? Will it gracefully fallback?

Hagay


On Fri, Oct 19, 2018, 15:46 Sergio Fernández  wrote:

> If there is no downside on platforms not supporting AVX512 instructions,
> then +1
>
>
> On Wed, Oct 17, 2018, 14:10 Alex Zai  wrote:
>
> > Hey all,
> > We have been working hard these past few months to integrate and
> stabilize
> > Intel’s MKLDNN deep learning CPU accelerator into Mxnet and have made
> > incredible progress. On CPUs with AVX512 instructions (such as c5.18x) we
> > have seen performance increase up to 12x and on other platforms (Macs,
> > AVX2) we seen a speedup of 1.5+. Full list of benchmarks can be found
> here
> > (
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95650764
> >  and https://github.com/apache/incubator-mxnet/pull/12591).
> >
> > Currently, using this accelerator requires the developer to either pip
> > install the mxnet-mkl version of mxnet or to build it themselves from
> > source. Given that we should try to provide the best performance "out of
> > the box” with mxnet we should include this in the default build. The
> mkldnn
> > library is included with in the pip package build so it does not require
> an
> > external dependency.
> >
> > There were concerns that MKLDNN could cause regressions on certain
> > platforms (as it did with the tensorflow version a while back); but we
> > added a env flag (MXNET_MKLDNN_ENABLED) that allows users to turn of this
> > feature during runtime. Please bring up any other concerns you may have
> and
> > your thoughts on including this accelerator in the default build.
> >
> > Best,
> > Alex
> >
>

Re: Apache MXNet Slack

[Steffen Rochel]

Dave - invited you to MXNet slack channel. Thanks for contributing to MXNet
& Clojure project.
Steffen

On Fri, Oct 19, 2018 at 5:53 AM Dave Liepmann 
wrote:

> Hi, could I get an invitation to the MXNet slack? I'm working with the
> Clojure contrib project and
> https://mxnet.incubator.apache.org/community/mxnet_channels.html said this
> is the place to ask.
>
> Thanks in advance,
> Dave
>

Re: [Discussion] Separating PMC and Committership

[Jason Dai]

I think in general it's always a good idea to reduce barriers to entry into
the project. Therefore I think separating committer and PMC roles is a good
idea, as it helps encourage and recognize contributors by giving them
commit early; and then it allows the new committers to spend some more time
to understand the projects governance (esp. how the the Apache Way is
applied by the PMC), so as to get ready for the PMC role.

Thanks,
-Jason

On Fri, Oct 19, 2018 at 1:16 AM Naveen Swamy  wrote:

> I suggest we discuss on what the revised criteria for committers will be
> and how do committers move up to become a PMC member before voting on the
> separation ? I would like to see if that helps grow the community before
> Voting on this.
>
> @Chris Olivier  Can you clarify what you mean by
> bonafide intentions and other intangeables ?,
> I would assume one can still consider them while you vote if you can
> justify or support it and not be just based on how someone feels.
>
> On Thu, Oct 18, 2018 at 8:29 AM Chris Olivier 
> wrote:
>
> > IMHO it’s not a great idea to develop a hard criteria for committer and
> PMC
> > as if it were some sort of checklist. If that were the case, then people
> > would tend to be just laser-focused on checking items off the list rather
> > than a bonafied drive to improve the product and the community.  It would
> > also make it difficult to consider other intangeables in the decision.
> >
> >
> > On Thu, Oct 18, 2018 at 5:43 AM Carin Meier 
> wrote:
> >
> > > Thanks Micheal for making the process clearer to me. It helps quite a
> > bit.
> > >
> > > Also thanks to Chris and Steffen for your clarification and input.
> > >
> > > I think there are two issues that are intermingled in considering this.
> > One
> > > relates to separating levels of committer and PMC member. The other, as
> > > Steffen pointed out, relates to the criteria which we use to consider
> > > people for these levels of membership. I would propose that to make it
> > > easier to achieve consensus, we consider them each as their own
> proposal.
> > >
> > > The proposal of separating levels of committer and PMC member can be
> > > considered on the Apache definitions of rights and responsibilities
> here
> > > https://www.apache.org/foundation/how-it-works.html#roles: Since the
> PMC
> > > member has more rights and responsibilities than a committer, I think
> it
> > > implies a stricter criteria, (although it would be unspecified in the
> > > proposal).
> > >
> > > The proposal of redefining our project's criteria in respect to how we
> > > consider nomination to those roles could be a separate discussion and
> > vote
> > > since there are other issues that we might want to tackle such as
> > inclusion
> > > of non-code contributions and general alignment to the Apache
> > definitions.
> > >
> > > We can of course choose to tackle the proposal of redefining the
> criteria
> > > first or do the separation of levels first since the discussion is
> > already
> > > in progress.
> > >
> > > Thoughts?
> > >
> > > - Carin
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Oct 18, 2018 at 2:04 AM Steffen Rochel <
> steffenroc...@gmail.com>
> > > wrote:
> > >
> > > > Haibin's proposed "For active contributors we first invite them to
> > become
> > > > our committers. Later on as they make significant contribution, we
> can
> > > > invite them to PMC."
> > > > Several people raised the question what defines "active contributors"
> > and
> > > > "make significant contribution". In my view the discussion has not
> > > answered
> > > > the questions and it is not clear to me what changes are proposed to
> > > >
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> > .
> > > > I'm making the assumption that the proposal is to simplify the path
> for
> > > > becoming a committer to grow the committer community. So far I have
> not
> > > > heard what changes or simplifications are proposed. Without a change
> I
> > > fail
> > > > to see the benefit of this proposal to increase the number of
> > committers.
> > > > I agree that the path from committer to PMC member should be
> clarified
> > as
> > > > well and suggest to align with expectations and responsibilities of
> PMC
> > > > members.
> > > > I'm also under the assumption that the proposal only applies for
> future
> > > > committers and PMC members, not for existing PMC members and this
> > > > assumption should be clarified.
> > > >
> > > > Steffen
> > > >
> > > > On Wed, Oct 17, 2018 at 4:29 PM Chris Olivier  >
> > > > wrote:
> > > >
> > > > > I believe the assumption has always been that current PMC members
> > will
> > > > > remain PMC members.
> > > > >
> > > > > On Wed, Oct 17, 2018 at 3:51 PM Michael Wall 
> > wrote:
> > > > >
> > > > > > I too think separating committers from PMC is a good idea for
> your
> > > > > project
> > > > > > given the desire to grow committers and the concerns I have seen
> > > trying
> > > > > to
> > > > > > add new 

Re: Include MKLDNN into default mxnet pip package

[Sergio Fernández]

If there is no downside on platforms not supporting AVX512 instructions,
then +1


On Wed, Oct 17, 2018, 14:10 Alex Zai  wrote:

> Hey all,
> We have been working hard these past few months to integrate and stabilize
> Intel’s MKLDNN deep learning CPU accelerator into Mxnet and have made
> incredible progress. On CPUs with AVX512 instructions (such as c5.18x) we
> have seen performance increase up to 12x and on other platforms (Macs,
> AVX2) we seen a speedup of 1.5+. Full list of benchmarks can be found here
> (
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95650764
>  and https://github.com/apache/incubator-mxnet/pull/12591).
>
> Currently, using this accelerator requires the developer to either pip
> install the mxnet-mkl version of mxnet or to build it themselves from
> source. Given that we should try to provide the best performance "out of
> the box” with mxnet we should include this in the default build. The mkldnn
> library is included with in the pip package build so it does not require an
> external dependency.
>
> There were concerns that MKLDNN could cause regressions on certain
> platforms (as it did with the tensorflow version a while back); but we
> added a env flag (MXNET_MKLDNN_ENABLED) that allows users to turn of this
> feature during runtime. Please bring up any other concerns you may have and
> your thoughts on including this accelerator in the default build.
>
> Best,
> Alex
>

Re: Apache MXNet (incubating) Python Docker Images

[Sergio Fernández]

Python 2.7 reaches End of Life by the end on 2019.Take that into account.

About Python 3.x, why not having 3.6 docker images? I know 3.7 is not yet
supposed by MXNet. But starting with 3 5 doesn't make much sense for me

On Wed, Oct 17, 2018, 11:52 Meghna Baijal 
wrote:

> Hi All,
>
> I am currently in the process of updating the python docker images for
> Apache MXNet such that they are built on top of the pip binaries.
> Until now these were built to use python 2.7 but with an upcoming PR I am
> also adding python 3.5 docker images. I would like to know the community’s
> preference on whether I should keep the *Python 2.7 Docker image as the
> default or should I move to Python 3.5 as the default version*?
>
> [1] The new python2 dockerfiles and build script can be found here.
> <
> https://github.com/apache/incubator-mxnet/tree/master/docker/docker-python
> >
> [2] The PR for python3 images is in progress and is here.
> 
>
> Thanks,
> Meghna Baijal
>

Apache MXNet Slack

[Dave Liepmann]

Hi, could I get an invitation to the MXNet slack? I'm working with the
Clojure contrib project and
https://mxnet.incubator.apache.org/community/mxnet_channels.html said this
is the place to ask.

Thanks in advance,
Dave

[DISCUSS] - Revisions to Committer Criteria

[Carin Meier]

Background:

There is a desire to increase the committer pool and grow the community.
This thread is to discuss the possibility of revision the current committer
criteria in light of the following goals:

- Make it easier to newcomers to be committers
- Recognize non-code contributions as paths to committership
- Open the door to separating levels of committer and PMC (discussed in
another thread)

Current State:

The current committer criteria is here
https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer as
is modeled after the Hadoop committer criteria
https://hadoop.apache.org/committer_criteria.html

Proposal:

Model the MXNet path to committership and PMC after the Apache Beam project
https://beam.apache.org/contribute/become-a-committer/

Short quote from page:
  =
An Apache Beam committer…


   - Takes many forms
   
   - Knows, upholds, and reinforces the Apache Software Foundation code of
   conduct
   

   - Knows, upholds, and reinforces the responsibilities of an Apache
   Software Foundation committer
   

   - Knows, upholds, and reinforces the Beam community’s practices
   

   - =
   



I believe if we merge our current committer criteria with this model it
will open  the path to committership to a wider pool, acknowledge that
there are multiple paths, and reinforce the ASF values and responsibilities.

The Beam model does not explicitly address a PMC level but we could add it
in in the same spirit of reinforcing the ASF responsibilities and values of
this level.

Looking forward to feedback about this possible direction. If the community
is interested looking more into this direction I would be happy to create
of first draft of something more concrete to look at - (or if someone else
wants to take a crack at it too that would be great)

- Carin