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
+1 on Kellen’s comments and suggestion.
On Wed, Oct 17, 2018 at 12:39 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:
> This feels like something we should get a little data on before making a
> decision, but I also don't have a strong opinion. I would bias towards
> pushing something
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
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 committers. I saw at least one other mentor, Jim on this thread
too.
Is the plan to leave all current PMC members in the PMC? If that is n
If my understanding is correct about the context, it should be acknowledged
that the significant performance improvement comes from the Intel MKLDNN
team's contribution in this PR:
https://github.com/apache/incubator-mxnet/pull/12530.
On Wed, Oct 17, 2018 at 3:12 PM kellen sunderland <
kellen.sund
Do nightly artifacts need to be signed? For releases what you wrote and what
Apache recommends makes total sense. Thus artifacts from cd can’t be signed
manually.
Pedro
> On 17. Oct 2018, at 22:29, Naveen Swamy wrote:
>
> I am collaborating with Zach Kimberg and Qing to work on automatic (
>
First of all thanks to Intel for these improvements, really a great effort.
What would the compatibility story look like for users that don't have
these AVX instructions? Would there be any negative affect for AMD users?
Regarding TensorRT: It's a possibility but not planned in the short term. A
Let me rephrase the question.
Since I'm new to the committer/PMC process, I wondering what the next step
is in a proposed change of process like this.
If we gauge that there is a significant enough interest do we propose a
vote? Is there enough interest and information to have a vote in this case
This is huge. Thanks for working on this. Is there a similar plan with eg;
tensor-rt support being ported into the main cuda-9.x packages?
On October 17, 2018 at 2:10:20 PM, Alex Zai (aza...@gmail.com) wrote:
Hey all,
We have been working hard these past few months to integrate and stabilize
Inte
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,
I am collaborating with Zach Kimberg and Qing to work on automatic (
currently its very tedious and time consuming) publishing the MXNet-Scala
maven package to Apache Snapshot repo(either as nightly or weekly), for
publishing the package the artifacts need to be signed with a committer's
key, howev
This feels like something we should get a little data on before making a
decision, but I also don't have a strong opinion. I would bias towards
pushing something that might be imperfect and moving on to develop other
improvements for users rather than determining a 'perfect' solution.
The questio
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 P
Hi!
I'd like to join the MXNet Slack channel. My GH handle is @kohr-h.
Cheers,
Holger
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
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
pref
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. I
Yes, definitely! I have added it to the list of examples. Thanks :)
-Marco
Aaron Markham schrieb am Mi., 17. Okt. 2018,
16:15:
> Thanks Marco, this is a great feature. I didn't see git listed under "when
> to use this guide". Can we use this to access git credentials like for when
> we publish
Thanks Marco, this is a great feature. I didn't see git listed under "when
to use this guide". Can we use this to access git credentials like for when
we publish the website?
Cheers,
Aaron
On Wed, Oct 17, 2018, 06:19 Marco de Abreu
wrote:
> Hello,
>
> I have just published a new guide how to man
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
Hello,
I have just published a new guide how to manage and access credentials in
MXNet CI. It's available at
https://cwiki.apache.org/confluence/display/MXNET/Managing+and+accessing+credentials
.
This is was part of the preparation for the Scala Maven Publish job that
will run as Continuous Deplo
-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 r
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
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 ab
23 matches
Mail list logo
