Re: Cambricon MLU support for MXNet.

[Steffen Rochel]

Hi Haochong -
welcome to MXNet. I invited you to the Slack channel, which you can use as
another communication path.

Regards,
Steffen

On Tue, Dec 18, 2018 at 5:45 AM Haochong Zhang 
wrote:

> Thank you very much for your valuable feedback!
>
> We will submit the design proposal ASAP. At the same time, we will be
> ready for the appropriate server or cloud.
>
> The cambricon libraries related to MXNet are Cambricon Neuware Machine
> Learning Library (CNML) and Cambricon Neuware Runtime Library (CNRT). The
> libraries' documentation will be available soon.
>
> Look forward to continued participation and contribution in the future.
>
>
> --
> 发件人：Skalicky, Sam 
> 发送时间：2018年12月18日(星期二) 06:03
> 收件人：dev@mxnet.incubator.apache.org 
> 抄 送：张昊翀 
> 主 题：Re: Cambricon MLU support for MXNet.
>
> Hi Haochong,
>
> I am in the process of putting together a design proposal for an
> accelerator interface for MXNet that would allow hardware vendors to
> integrate their runtime with MXNet. I would like to suggest setting up a
> time to get together so that we can hear more about your needs to
> interface/control your accelerator, and I can share some thought on a
> generic accelerator API that I will be proposing. Id be happy to help you
> prepare a design proposal as well.
>
> I’ll connect with you separately to setup a time to chat.
>
> Sam
>
>
> > On Dec 17, 2018, at 5:49 AM, Pedro Larroy 
> wrote:
> >
> > Hi Haochong
> >
> > Welcome to MXNet, It's exciting to have additional hardware platforms
> > added and supported in the project.
> >
> > The CI system for MXNet is donated by AWS to the project. We have a
> > small hardware lab with embedded physical hardware like ARM boards
> > including NVidia Jetson which we are connecting to the CI system.
> > (It's a WIP).
> >
> > However, the bulk of the CI system runs in the AWS Cloud using Jenkins
> > and EC2 GPU and CPU instances. So even though any of the options you
> > mention are possible and could work, I think in the order you
> > mentioned them would be the most preferable. Connecting a remote
> > server or cloud instance to the MXNet Jenkins would be the easiest
> > which wouldn't involve hardware shipping and maintenance.
> >
> > I think once you have the contribution merged and the changes ready to
> > be tested we can make a plan on how to best integrate with CI. For
> > that, the recommendation that Hagay gave (Design proposal in the Wiki)
> > is a good path forward, so other members of the community and the
> > engineers contributing to the CI system can contribute.
> >
> > Pedro.
> >
> > On Mon, Dec 17, 2018 at 3:33 AM 张昊翀  wrote:
> >>
> >> Dear MXNet community,
> >>
> >> We are from Cambricon, a leading supplier of artificial intelligence
> chips. We have two product lines, including IP products (e.g., Cambricon
> 1A/1H) and chip products (e.g., MLU100 released in May 2018)
> >>
> >> We are now adapting MXNet on Cambricon products. During the follow-up
> session, we plan to open source, and hope to merge these new features into
> the master branch of MXNet and to be a part of MXNet's long-term support.
> We firmly believe that these MLU features will promote the MXNet community
> development.
> >> To this end, we are ready to accept the rigorous inspection of MXNet
> community. In addition, we need advice from the community to achieve high
> quality implementation. On this basis, we very much hope to reach a
> full-scale long-term cooperation with the community.
> >>
> >> In order to achieve the above goals, we hope to keep in touch with the
> community on some issues. Looking forward to your valuable feedback.
> >>
> >> 1. MLU100 mainly focuses on inference, and we plan to first support the
> inference part of MXNet. The training part of MXNet on MLU will be released
> in the future. Is that acceptable for MXNet community?
> >>
> >> 2. Though MLU can support various operators/networks, to guarantee high
> quality, all supported operators submitted to the community should undergo
> rigorous stress test. Thus, at the beginning, we plan to release a small
> number of supported operators and networks, and more of them will be
> continuously added. Is that acceptable or do we have to support all
> networks in the ModelZoo in the first release?
> >>
> >> 3. Currently we plan to support both Python and C++ APIs. More details
> on supported APIs will be provided in a follow-up proposal.
> >>
> >> 4. We need to modify the mShadow in order to support tensor memory
> operations.
> >>
> >> 5. In order to enable the community to run and fully test our code, we
> want to provide the community with a complete test environment. At present,
> we are considering the following three ways.
> >> A) Provides several remote servers for community and integrates with
> the community's Jenkins.
> >> B) Provide a cloud platform to the community.
> >> C) Donate MLU100 to the community's testing platform. However, we don’t
> 

Malformed package uploaded to Maven central

[Qing Lan]

Dear Community,

Recently I tried to improve the Maven automated publish procedure and tested 
publish the package. However, I accidently used maven to upload a package to a 
close release branch: 
https://repository.apache.org/#nexus-search;gav~org.apache.mxnet~~1.5.0~~/.
 However, it seemed that I didn’t have the access to remove this package since 
it is controlled by Maven central. In this case, I regretfully request a 
PMC/PPMC member to file an Apache Infra ticket to remove this package from 
there so it won’t influence the current maven users to download them. The 
influence is limited to OSX users who are using official releases of MXNet 
Scala/Java packages.

I apologize for this act and won’t do any more risky experiment until I am 
fully aware of the consequence of it.
Qing

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0

[Aston Zhang]

+ 1
tested with code at zh.diveintodeeplearning.org on both Windows and Linux.

Thank @yajiedesign and @szha for the pip wheels.

Cheers,
Aston

On Thu, Dec 20, 2018 at 9:25 AM Steffen Rochel 
wrote:

> Dear MXNet community,
>
> This is the vote to release Apache MXNet (incubating) version v1.4.0.
> Voting will start December 20 noon PST  and close on December 27 noon PST.
>
> Link to release notes:
>
>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Notes
>
> Link to release candidate:
> https://github.com/apache/incubator-mxnet/releases/tag/
> 
> 1.4.0.rc0
> 
>
> Link to source and signatures on apache dist server:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc0
> 
>
>
> Please remember to TEST first before voting accordingly:
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
>
> Best regards,
> Steffen
>

Re: [Question] UI change policy in MXNet

[Anirudh Subramanian]

On Thu, Dec 20, 2018, 1:56 PM Lin Yuan  Hi Anirudh,
>
> Thanks a lot for your clarifications! I have some followup
> questions/comments:
>
> 1) Which guideline should we follow when updating the UI in MXNet
> operators?
> A) MXNet follows semantic versioning, so breaking changes to operator
> interfaces can be introduced only in major versions.
>
> (Lin:) My question is what style of UI guide we should follow. e.g. naming
> convension, usage mode, etc. Something like numpy's style or tensorflow?
>
I don't think there is such an UI guide. If the operator already existed in
numpy/scipy or other frameworks we generally tend to use similar
interfaces.

>
> 2) Who should approve the UI change?
> A) Contributors who may have worked on the operator and/or other
> contributors/committers.
>
> (Lin:) Is it too local to reply on contributors to one/a few operators to
> decide the UI. How can we make sure the consistency of UI across all
> operators in MXNet?
>
agreed. Feel free to propose a better way.

>
> 3) In case of backward compatibility, should we favor breaking the backward
> compatibility and update the release notes or adding a newer version of the
> operator like ***_v2?
> A) If the operator interfaces are not compatible, its fine to create
> operator with the name "_v2" . In the next major version release, you can
> add an alias for newer implementation and deprecate the older one.
>
> (Lin) What if there is already "_v2", do we add "_v3", "_v4" as the project
> evolves?
>
This needs to be dealt on case by case basis. I haven't seen many ops which
would require three backward incompatible revisions between two major
releases.

>
> 4) Which operator should go to contrib and which be implemented as regular?
> A) I think this discussion may help:
> https://github.com/apache/incubator-mxnet/pull/5499 . To summarize:
> contrib
> was created for ops for which we provide limited guarantees with respect to
> backward compatibility, interface changes, testing etc.
>
> (Lin) This is definitely an informative discussion. It would be better if
> we can put this in a more noticeable place for developers.
>
>
> On Thu, Dec 20, 2018 at 1:39 PM Anirudh Subramanian  >
> wrote:
>
> > 1) Which guideline should we follow when updating the UI in MXNet
> > operators?
> > A) MXNet follows semantic versioning, so breaking changes to operator
> > interfaces can be introduced only in major versions.
> >
> > 2) Who should approve the UI change?
> > A) Contributors who may have worked on the operator and/or other
> > contributors/committers.
> >
> > 3) In case of backward compatibility, should we favor breaking the
> backward
> > compatibility and update the release notes or adding a newer version of
> the
> > operator like ***_v2?
> > A) If the operator interfaces are not compatible, its fine to create
> > operator with the name "_v2" . In the next major version release, you can
> > add an alias for newer implementation and deprecate the older one.
> >
> > 4) Which operator should go to contrib and which be implemented as
> regular?
> > A) I think this discussion may help:
> > https://github.com/apache/incubator-mxnet/pull/5499 . To summarize:
> > contrib
> > was created for ops for which we provide limited guarantees with respect
> to
> > backward compatibility, interface changes, testing etc.
> >
> > Anirudh
> >
> > On Thu, Dec 20, 2018 at 1:00 PM Lin Yuan  wrote:
> >
> > > Dear Community,
> > >
> > > As a contributor, I would like to know the current policy for updating
> UI
> > > of an operator. I understand UI change should be introduced in major
> > > release not minor release. However, it is still not quite clear to me
> > > regarding the UI change process:
> > >
> > > 1) Which guideline should we follow when updating the UI in MXNet
> > > operators?
> > > 2) Who should approve the UI change?
> > > 3) In case of backward compatibility, should we favor breaking the
> > backward
> > > compatibility and update the release notes or adding a newer version of
> > the
> > > operator like ***_v2?
> > > 4) Which operator should go to contrib and which be implemented as
> > regular?
> > >
> > > Any clarification is appreciated and it is helpful to guide PR
> reviewers
> > as
> > > well.
> > >
> > > Merry Christmas to ya'all!
> > >
> > > Lin
> > >
> >
>

Re: [Question] UI change policy in MXNet

[Lin Yuan]

Hi Anirudh,

Thanks a lot for your clarifications! I have some followup
questions/comments:

1) Which guideline should we follow when updating the UI in MXNet operators?
A) MXNet follows semantic versioning, so breaking changes to operator
interfaces can be introduced only in major versions.

(Lin:) My question is what style of UI guide we should follow. e.g. naming
convension, usage mode, etc. Something like numpy's style or tensorflow?

2) Who should approve the UI change?
A) Contributors who may have worked on the operator and/or other
contributors/committers.

(Lin:) Is it too local to reply on contributors to one/a few operators to
decide the UI. How can we make sure the consistency of UI across all
operators in MXNet?

3) In case of backward compatibility, should we favor breaking the backward
compatibility and update the release notes or adding a newer version of the
operator like ***_v2?
A) If the operator interfaces are not compatible, its fine to create
operator with the name "_v2" . In the next major version release, you can
add an alias for newer implementation and deprecate the older one.

(Lin) What if there is already "_v2", do we add "_v3", "_v4" as the project
evolves?

4) Which operator should go to contrib and which be implemented as regular?
A) I think this discussion may help:
https://github.com/apache/incubator-mxnet/pull/5499 . To summarize: contrib
was created for ops for which we provide limited guarantees with respect to
backward compatibility, interface changes, testing etc.

(Lin) This is definitely an informative discussion. It would be better if
we can put this in a more noticeable place for developers.


On Thu, Dec 20, 2018 at 1:39 PM Anirudh Subramanian 
wrote:

> 1) Which guideline should we follow when updating the UI in MXNet
> operators?
> A) MXNet follows semantic versioning, so breaking changes to operator
> interfaces can be introduced only in major versions.
>
> 2) Who should approve the UI change?
> A) Contributors who may have worked on the operator and/or other
> contributors/committers.
>
> 3) In case of backward compatibility, should we favor breaking the backward
> compatibility and update the release notes or adding a newer version of the
> operator like ***_v2?
> A) If the operator interfaces are not compatible, its fine to create
> operator with the name "_v2" . In the next major version release, you can
> add an alias for newer implementation and deprecate the older one.
>
> 4) Which operator should go to contrib and which be implemented as regular?
> A) I think this discussion may help:
> https://github.com/apache/incubator-mxnet/pull/5499 . To summarize:
> contrib
> was created for ops for which we provide limited guarantees with respect to
> backward compatibility, interface changes, testing etc.
>
> Anirudh
>
> On Thu, Dec 20, 2018 at 1:00 PM Lin Yuan  wrote:
>
> > Dear Community,
> >
> > As a contributor, I would like to know the current policy for updating UI
> > of an operator. I understand UI change should be introduced in major
> > release not minor release. However, it is still not quite clear to me
> > regarding the UI change process:
> >
> > 1) Which guideline should we follow when updating the UI in MXNet
> > operators?
> > 2) Who should approve the UI change?
> > 3) In case of backward compatibility, should we favor breaking the
> backward
> > compatibility and update the release notes or adding a newer version of
> the
> > operator like ***_v2?
> > 4) Which operator should go to contrib and which be implemented as
> regular?
> >
> > Any clarification is appreciated and it is helpful to guide PR reviewers
> as
> > well.
> >
> > Merry Christmas to ya'all!
> >
> > Lin
> >
>

Re: [Question] UI change policy in MXNet

[Anirudh Subramanian]

1) Which guideline should we follow when updating the UI in MXNet operators?
A) MXNet follows semantic versioning, so breaking changes to operator
interfaces can be introduced only in major versions.

2) Who should approve the UI change?
A) Contributors who may have worked on the operator and/or other
contributors/committers.

3) In case of backward compatibility, should we favor breaking the backward
compatibility and update the release notes or adding a newer version of the
operator like ***_v2?
A) If the operator interfaces are not compatible, its fine to create
operator with the name "_v2" . In the next major version release, you can
add an alias for newer implementation and deprecate the older one.

4) Which operator should go to contrib and which be implemented as regular?
A) I think this discussion may help:
https://github.com/apache/incubator-mxnet/pull/5499 . To summarize: contrib
was created for ops for which we provide limited guarantees with respect to
backward compatibility, interface changes, testing etc.

Anirudh

On Thu, Dec 20, 2018 at 1:00 PM Lin Yuan  wrote:

> Dear Community,
>
> As a contributor, I would like to know the current policy for updating UI
> of an operator. I understand UI change should be introduced in major
> release not minor release. However, it is still not quite clear to me
> regarding the UI change process:
>
> 1) Which guideline should we follow when updating the UI in MXNet
> operators?
> 2) Who should approve the UI change?
> 3) In case of backward compatibility, should we favor breaking the backward
> compatibility and update the release notes or adding a newer version of the
> operator like ***_v2?
> 4) Which operator should go to contrib and which be implemented as regular?
>
> Any clarification is appreciated and it is helpful to guide PR reviewers as
> well.
>
> Merry Christmas to ya'all!
>
> Lin
>

[Question] UI change policy in MXNet

[Lin Yuan]

Dear Community,

As a contributor, I would like to know the current policy for updating UI
of an operator. I understand UI change should be introduced in major
release not minor release. However, it is still not quite clear to me
regarding the UI change process:

1) Which guideline should we follow when updating the UI in MXNet operators?
2) Who should approve the UI change?
3) In case of backward compatibility, should we favor breaking the backward
compatibility and update the release notes or adding a newer version of the
operator like ***_v2?
4) Which operator should go to contrib and which be implemented as regular?

Any clarification is appreciated and it is helpful to guide PR reviewers as
well.

Merry Christmas to ya'all!

Lin

[VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0

[Steffen Rochel]

Dear MXNet community,

This is the vote to release Apache MXNet (incubating) version v1.4.0.
Voting will start December 20 noon PST  and close on December 27 noon PST.

Link to release notes:

https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.0+Release+Notes

Link to release candidate:
https://github.com/apache/incubator-mxnet/releases/tag/

1.4.0.rc0


Link to source and signatures on apache dist server:
https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.0.rc0



Please remember to TEST first before voting accordingly:
+1 = approve
+0 = no opinion
-1 = disapprove (provide reason)


Best regards,
Steffen