Re: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc1

[Markus Weimer]

> Shall we provide pip wheels for later release votes?

Apache projects generally do not provide binaries as "signed off"
release artifacts. That being said, binaries are commonly provided and
marked as "convenience binaries". Hence, no vote is necessary on them,
nor are they "official" releases.

Markus

Re: [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc1

[Markus Weimer]

> Shall we provide pip wheels for later release votes?

Apache projects generally do not provide binaries as "signed off"
release artifacts. That being said, binaries are commonly provided and
marked as "convenience binaries". Hence, no vote is necessary on them,
nor are they "official" releases.

Markus

On Sat, Jan 11, 2020 at 4:17 PM Hao Jin  wrote:
>
> +1 (binding)
> Built from source and ran all the latest d2l notebooks without problems.
> Hao
>
> On Fri, Jan 10, 2020 at 10:03 PM Jun Wu  wrote:
>
> > +1 (binding)
> >
> > Built from source. Ran all the GPU tests and test_numpy*.py cpu tests
> > without problems.
> >
> > On Fri, Jan 10, 2020 at 9:43 PM Skalicky, Sam 
> > wrote:
> >
> > > We can enable building nightlys for feature branches too.
> > >
> > > Sam
> > >
> > > > On Jan 10, 2020, at 7:48 PM, Lin Yuan  wrote:
> > > >
> > > > We can release one cpu-mkl and one CUDA wheel  for testing various
> > > > applications. Other people can build from source if they want other
> > > flavors
> > > >
> > > > Lin
> > > >
> > > >> On Fri, Jan 10, 2020 at 4:00 PM Karan Jariwala <
> > > karankjariw...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> Yes, agree with your point. But we will be requiring  many flavors of
> > > pip
> > > >> wheel.
> > > >>
> > > >> MKL/ without MKL
> > > >> CUDA/ no CUDA
> > > >> Linux/windows/Mac
> > > >>
> > > >> Thanks,
> > > >> Karan
> > > >>
> > > >> On Fri, Jan 10, 2020 at 3:54 PM Haibin Lin 
> > > >> wrote:
> > > >>
> > > >>> Shall we provide pip wheels for later release votes?
> > > >>>
> > > >>> Not everyone knows how to build MXNet from source (and building from
> > > >> source
> > > >>> also takes very long). Providing a pip wheel would lower the bar for
> > > >> users
> > > >>> who wants to test MXNet and participate in voting.
> > > >>>
> > > >>> Best,
> > > >>> Haibin
> > > >>>
> > > >>> On Fri, Jan 10, 2020 at 3:50 PM Haibin Lin  > >
> > > >>> wrote:
> > > >>>
> > >  +1
> > > 
> > >  Built from source with USE_CUDA=1 on Ubuntu. Run gluon-nlp unit
> > tests
> > > >> and
> > >  they passed.
> > > 
> > >  On Fri, Jan 10, 2020 at 3:18 PM Karan Jariwala <
> > > >> karankjariw...@gmail.com
> > > 
> > >  wrote:
> > > 
> > > > +1
> > > >
> > > > Tested MXNet with and without MKL-DNN on Ubuntu 16.04 with Horovod
> > > >>> 0.18.2.
> > > > No regression seen between 1.5.1 and 1.6.0.rc1 when running
> > > >>> horovod_MXNet
> > > > integration test.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Karan
> > > >
> > > > On Fri, Jan 10, 2020 at 2:47 PM Markus Weimer 
> > > >>> wrote:
> > > >
> > > >> +1 (binding)
> > > >>
> > > >> I tested on Ubuntu 18.04 on the Windows Subsystem for Linux.
> > > >>
> > > >> Tested:
> > > >>  * Built from source using the instructions here [0]
> > > >>  * Ran the tests in `./build/tests/mxnet_unit_tests`
> > > >>  * SHA512 of the archive
> > > >>
> > > >> Not tested:
> > > >>  * Language bindings
> > > >>  * CUDA or other GPU acceleration
> > > >>  * LICENSE and compliance status
> > > >>  * Signature of the archive
> > > >>
> > > >
> > > 
> > > >>>
> > > >>
> > >
> >

Re: Stopping nightly releases to Pypi

[Skalicky, Sam]

Hi All,

The html page source is available at the link (view source, its all in a single 
html file), if someone wants to make modifications I’ll be happy to help 
integrate those changes and get the latest version published in the S3 bucket. 
Whenever the final location of the nightly builds is identified we can 
move/modify the script appropriately. 

Sam

> On Jan 12, 2020, at 5:41 PM, Tao Lv  wrote:
> 
> Thank you for the effort, Sam. One minor suggestion: can we sort and put
> the latest build at the top of the table?
> 
> -tao
> 
> On Mon, Jan 13, 2020 at 7:03 AM Marco de Abreu 
> wrote:
> 
>> Hi Sam,
>> 
>> that's a great idea, thanks! Can you please adjust the script so it uses
>> the artifacts that will be published once Shengs PR gets merged?
>> 
>> Best regards,
>> Marco
>> 
>> Skalicky, Sam  schrieb am So., 12. Jan. 2020,
>> 23:23:
>> 
>>> Hi dev,
>>> 
>>> I made an html page that generates the links to the nightly builds
>>> available in the public S3 bucket so you don’t have to log into AWS to
>> see
>>> them.
>>> 
>>> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/index.html
>>> 
>>> Keep in mind we only have builds from January 2020 and December 2019 so
>>> far.
>>> 
>>> Sam
>>> 
>>> On Jan 10, 2020, at 3:05 AM, Sheng Zha >> zhash...@apache.org>> wrote:
>>> 
>>> Size of a change doesn't necessarily reflect the time one spends on the
>>> navigating the code base and finding the solution. Also, I tend to
>> believe
>>> that everyone genuinely wants what's best for the project, just from
>>> different perspectives.
>>> 
>>> Let's focus on improving the CD solution so that security concerns can be
>>> addressed too.
>>> 
>>> -sz
>>> 
>>> On 2020/01/09 21:57:30, Chris Olivier >> cjolivie...@apache.org>> wrote:
>>> If this tiny fix is representative of the bulk of the reasoning behind
>> all
>>> the the CD churn recently, then this seems to be of some concern.
>>> 
>>> -Chris
>>> 
>>> On Thu, Jan 9, 2020 at 6:32 AM Marco de Abreu >> >
>>> wrote:
>>> 
>>> Great, thanks a lot sheng!
>>> 
>>> -Marco
>>> 
>>> Sheng Zha mailto:zhash...@apache.org>> schrieb am
>>> Do., 9. Jan. 2020, 14:28:
>>> 
>>> I'm fixing the CD pipeline in
>>> https://github.com/apache/incubator-mxnet/pull/17259/files and will
>>> update the s3 publish path so that it's friendly for automatically
>>> generating such page.
>>> 
>>> -sz
>>> 
>>> On 2020/01/06 18:19:52, "Lausen, Leonard" >> >
>>> wrote:
>>> Consider a user finds a bug in a nightly version but we can't narrow
>>> down the
>>> version of mxnet used as the name is constant over time. Or users wan't
>>> to
>>> revert back to the previous nightly version installed but don't know
>>> which date
>>> it was from due to constant name.
>>> 
>>> Instead I suggest we introduce an autogenerated page like
>>> https://download.pytorch.org/whl/nightly/cu101/torch_nightly.html
>>> 
>>> Then "pip install -f URLTOPAGE mxnet" will install the latest available
>>> version.
>>> Maybe the team maintaining the S3 bucket can reconsider creating such
>>> page for
>>> the intermediate time until the CD based nighlty build is operating.
>>> 
>>> On Mon, 2020-01-06 at 10:01 -0800, Lin Yuan wrote:
>>> +1 for a nightly pip with fixed name.
>>> 
>>> We need this to track mxnet integration with other packages such as
>>> Horovod.
>>> 
>>> Sam, when do you think we can have this nightly build with a fixed
>>> name?
>>> 
>>> Thanks,
>>> 
>>> Lin
>>> 
>>> On Sun, Jan 5, 2020 at 7:48 PM Skalicky, Sam
>>> mailto:sska...@amazon.com.invalid>>
>>> wrote:
>>> 
>>> Hi Tao,
>>> 
>>> We dont have this yet, but we did think about putting the latest
>>> wheels in
>>> a specific place in the s3 bucket so they are always updated.
>>> Initially we
>>> decided not to do this since the main MXNet CD should have been
>>> fixed. But
>>> since its still not fixed yet, we might try and go ahead and do
>>> this.
>>> 
>>> Sam
>>> 
>>> On Jan 5, 2020, at 6:02 PM, Lv, Tao A >> tao.a...@intel.com>>> tao.a...@intel.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> How to install the latest available build of a flavor without
>>> specifying
>>> the build date? Something like `pip install mxnet --pre`.
>>> 
>>> Thanks,
>>> -tao
>>> 
>>> -Original Message-
>>> From: Skalicky, Sam >> sska...@amazon.com.INVALID>>> sska...@amazon.com.INVALID>>
>>> Sent: Monday, January 6, 2020 2:09 AM
>>> To: dev@mxnet.incubator.apache.org> dev@mxnet.incubator.apache.org>
>>> Subject: Re: Stopping nightly releases to Pypi
>>> 
>>> Hi Haibin,
>>> 
>>> You typed the correct URLs, the cu100 build has been failing since
>>> December 30th but other builds have succeeded. The wheels are being
>>> delivered into a public bucket that anyone with an AWS account can
>>> access
>>> and go poke around, here’s the URL for web access:
>>> 
>>> 
>>> 
>>> 

Re: CCLA for MXNET

[Gil Yehuda]

Thanks,
I believe that we have a CCLA between *Verizon Media* (was Yahoo) and
Apache. This however is a contribution from *Verizon* (the parent company)
and I don't think they've had a relationship with Apache. So they are
asking my assistance to get everything in place.

I believe they will have contributions, yet I don't know if any will want
to seek committer status. All in time, as they get more involved in the
project, I guess. But I wanted to prepare what they might need. Should I
sign a CCLA on the part of Verizon? (I am authorized by Verizon Legal to do
so.)

Gil Yehuda: I help with external technology engagement

>From the Open Source Program Office
 at Yahoo --> Oath - ->
Verizon Media



On Sun, Jan 12, 2020 at 10:33 AM Michael Wall  wrote:

> Hi Gil,
>
> Do you have code already that you are looking to contribute?  Or are you
> looking to assign people to issues?
>
> Take a look at https://www.apache.org/licenses/contributor-agreements.html.
> Typically a CLA is not needed for someone to start making contributions.
> An ICLA is required for someone to join Apache and become committer.  For
> your situation, it sounds like it you may want to get the Corporate CLA in
> place.  Also take a look at https://www.apache.org/licenses/cla-faq.html
>
> Mike
>
>
>
> On Fri, Jan 10, 2020 at 12:15 AM Gil Yehuda
>  wrote:
>
>> Dear MXNet Dev team
>> I have a team at Verizon who would like to start contributing code to
>> MXNet. In preparation, would you need a CCLA in place between Verizon and
>> Apache listing their names? and ICLAs from them? if so I'll be glad to
>> make
>> this happen. I didn't see the CLA indicated on the contributing
>> documentation in the repo, so I'm asking just in case. Thanks
>>
>> Gil Yehuda: I help with external technology engagement
>>
>> From the Open Source Program Office
>>  at Yahoo --> Oath - ->
>> Verizon Media
>>
>

Re: Stopping nightly releases to Pypi

[Lin Yuan]

Awesome work! It's really convenient to have this page.

Two cents:
(1) create a link on mxnet page to this one
(2) reorder the nightly as Tao suggested. Newest first.

On Mon, Jan 13, 2020 at 10:25 AM Skalicky, Sam 
wrote:

> Hi All,
>
> The html page source is available at the link (view source, its all in a
> single html file), if someone wants to make modifications I’ll be happy to
> help integrate those changes and get the latest version published in the S3
> bucket. Whenever the final location of the nightly builds is identified we
> can move/modify the script appropriately.
>
> Sam
>
> > On Jan 12, 2020, at 5:41 PM, Tao Lv  wrote:
> >
> > Thank you for the effort, Sam. One minor suggestion: can we sort and put
> > the latest build at the top of the table?
> >
> > -tao
> >
> > On Mon, Jan 13, 2020 at 7:03 AM Marco de Abreu 
> > wrote:
> >
> >> Hi Sam,
> >>
> >> that's a great idea, thanks! Can you please adjust the script so it uses
> >> the artifacts that will be published once Shengs PR gets merged?
> >>
> >> Best regards,
> >> Marco
> >>
> >> Skalicky, Sam  schrieb am So., 12. Jan.
> 2020,
> >> 23:23:
> >>
> >>> Hi dev,
> >>>
> >>> I made an html page that generates the links to the nightly builds
> >>> available in the public S3 bucket so you don’t have to log into AWS to
> >> see
> >>> them.
> >>>
> >>> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/index.html
> >>>
> >>> Keep in mind we only have builds from January 2020 and December 2019 so
> >>> far.
> >>>
> >>> Sam
> >>>
> >>> On Jan 10, 2020, at 3:05 AM, Sheng Zha  >>> zhash...@apache.org>> wrote:
> >>>
> >>> Size of a change doesn't necessarily reflect the time one spends on the
> >>> navigating the code base and finding the solution. Also, I tend to
> >> believe
> >>> that everyone genuinely wants what's best for the project, just from
> >>> different perspectives.
> >>>
> >>> Let's focus on improving the CD solution so that security concerns can
> be
> >>> addressed too.
> >>>
> >>> -sz
> >>>
> >>> On 2020/01/09 21:57:30, Chris Olivier  >>> cjolivie...@apache.org>> wrote:
> >>> If this tiny fix is representative of the bulk of the reasoning behind
> >> all
> >>> the the CD churn recently, then this seems to be of some concern.
> >>>
> >>> -Chris
> >>>
> >>> On Thu, Jan 9, 2020 at 6:32 AM Marco de Abreu  >>> >
> >>> wrote:
> >>>
> >>> Great, thanks a lot sheng!
> >>>
> >>> -Marco
> >>>
> >>> Sheng Zha mailto:zhash...@apache.org>> schrieb am
> >>> Do., 9. Jan. 2020, 14:28:
> >>>
> >>> I'm fixing the CD pipeline in
> >>> https://github.com/apache/incubator-mxnet/pull/17259/files and will
> >>> update the s3 publish path so that it's friendly for automatically
> >>> generating such page.
> >>>
> >>> -sz
> >>>
> >>> On 2020/01/06 18:19:52, "Lausen, Leonard"  >>> >
> >>> wrote:
> >>> Consider a user finds a bug in a nightly version but we can't narrow
> >>> down the
> >>> version of mxnet used as the name is constant over time. Or users wan't
> >>> to
> >>> revert back to the previous nightly version installed but don't know
> >>> which date
> >>> it was from due to constant name.
> >>>
> >>> Instead I suggest we introduce an autogenerated page like
> >>> https://download.pytorch.org/whl/nightly/cu101/torch_nightly.html
> >>>
> >>> Then "pip install -f URLTOPAGE mxnet" will install the latest available
> >>> version.
> >>> Maybe the team maintaining the S3 bucket can reconsider creating such
> >>> page for
> >>> the intermediate time until the CD based nighlty build is operating.
> >>>
> >>> On Mon, 2020-01-06 at 10:01 -0800, Lin Yuan wrote:
> >>> +1 for a nightly pip with fixed name.
> >>>
> >>> We need this to track mxnet integration with other packages such as
> >>> Horovod.
> >>>
> >>> Sam, when do you think we can have this nightly build with a fixed
> >>> name?
> >>>
> >>> Thanks,
> >>>
> >>> Lin
> >>>
> >>> On Sun, Jan 5, 2020 at 7:48 PM Skalicky, Sam
> >>> mailto:sska...@amazon.com.invalid>>
> >>> wrote:
> >>>
> >>> Hi Tao,
> >>>
> >>> We dont have this yet, but we did think about putting the latest
> >>> wheels in
> >>> a specific place in the s3 bucket so they are always updated.
> >>> Initially we
> >>> decided not to do this since the main MXNet CD should have been
> >>> fixed. But
> >>> since its still not fixed yet, we might try and go ahead and do
> >>> this.
> >>>
> >>> Sam
> >>>
> >>> On Jan 5, 2020, at 6:02 PM, Lv, Tao A  >>> tao.a...@intel.com> >>> tao.a...@intel.com>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> How to install the latest available build of a flavor without
> >>> specifying
> >>> the build date? Something like `pip install mxnet --pre`.
> >>>
> >>> Thanks,
> >>> -tao
> >>>
> >>> -Original Message-
> >>> From: Skalicky, Sam  >>> sska...@amazon.com.INVALID> >>> sska...@amazon.com.INVALID>>
> >>> Sent: Monday, January 6, 2020 2:09 AM
> >>> To: dev@mxnet.incubator.apache.org 

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
>

[DISCUSS] Enforce tighter control on API related changes

[Lin Yuan]

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: CD with windows need a special jenkins slave machine like restricted-utility

[Pedro Larroy]

Isn't this something that gets selected through vcvars?

On Fri, Jan 10, 2020 at 6:46 PM shiwen hu  wrote:

> use x64 host msvc. cmake -T host=x64
>
> Pedro Larroy  于2020年1月10日周五 上午7:28写道：
>
> > Is there a solution for this error in VS2017?
> >
> > c:\users\administrator\mxnet\src\operator\mxnet_op.h(943) : fatal error
> > C1002: compiler is out of heap space in pass 2
> >
> >
> >
> > On Tue, Jan 7, 2020 at 5:11 PM shiwen hu  wrote:
> >
> > > >
> > > > I personally encountered the problem that 2015 can't compile in high
> > > > version cuda. But I can't remember the details. We can continue to
> use
> > > 2015
> > > > until we encounter problems.
> > > >
> > >
> >
>

Re: CCLA for MXNET

[Michael Wall]

I am going to include Justin to get his take on this.  Justin, does this
need to go to legal?

Thanks

Mike

On Mon, Jan 13, 2020 at 10:13 AM Gil Yehuda 
wrote:

> Thanks,
> I believe that we have a CCLA between *Verizon Media* (was Yahoo) and
> Apache. This however is a contribution from *Verizon* (the parent
> company) and I don't think they've had a relationship with Apache. So they
> are asking my assistance to get everything in place.
>
> I believe they will have contributions, yet I don't know if any will want
> to seek committer status. All in time, as they get more involved in the
> project, I guess. But I wanted to prepare what they might need. Should I
> sign a CCLA on the part of Verizon? (I am authorized by Verizon Legal to do
> so.)
>
> Gil Yehuda: I help with external technology engagement
>
> From the Open Source Program Office
>  at Yahoo --> Oath - ->
> Verizon Media
>
>
>
> On Sun, Jan 12, 2020 at 10:33 AM Michael Wall  wrote:
>
>> Hi Gil,
>>
>> Do you have code already that you are looking to contribute?  Or are you
>> looking to assign people to issues?
>>
>> Take a look at
>> https://www.apache.org/licenses/contributor-agreements.html.  Typically
>> a CLA is not needed for someone to start making contributions.  An ICLA is
>> required for someone to join Apache and become committer.  For your
>> situation, it sounds like it you may want to get the Corporate CLA in
>> place.  Also take a look at https://www.apache.org/licenses/cla-faq.html
>>
>> Mike
>>
>>
>>
>> On Fri, Jan 10, 2020 at 12:15 AM Gil Yehuda
>>  wrote:
>>
>>> Dear MXNet Dev team
>>> I have a team at Verizon who would like to start contributing code to
>>> MXNet. In preparation, would you need a CCLA in place between Verizon and
>>> Apache listing their names? and ICLAs from them? if so I'll be glad to
>>> make
>>> this happen. I didn't see the CLA indicated on the contributing
>>> documentation in the repo, so I'm asking just in case. Thanks
>>>
>>> Gil Yehuda: I help with external technology engagement
>>>
>>> From the Open Source Program Office
>>>  at Yahoo --> Oath - ->
>>> Verizon Media
>>>
>>

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

[Sheng Zha]

Hi Lin,

Thanks for the suggestions.

With respect to your proposal:

> (2) Any PR that contains API change should clearly state this in PR title.
> Otherwise, committer can reject the PR

I agree that PRs with API changes should be made more prominent. Another 
mechanism that has already been used is to tag the PRs with the "API change" 
label [1].

On the other hand, relying on the community to call out the PRs with API 
changes may not be reliable. Oftentimes, people didn't realize that a change 
constitutes an API change. If a committer identifies such a change, a more 
friendly response would be to just label the PR and call out where the API 
change happens in a comment.

> (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

I'm not convinced that more hierarchy should be created among committers. All 
committers are entrusted by the PPMC to use their judgement to the best 
interest of this project, and additional qualification seems counter-productive.

With respect to your linked issue #17292, as @stephenrawls pointed out, it 
comes from 4ed14e2 where the inline definition of MXAPIHandleException is moved 
to a .cc file, and I'm the one that actually made this change to unblock the 
PR. I want to call out that:
- This is not an API change in that there's no change in the function signature 
or visibility in the symbol table of libmxnet.so.
- It should not be the responsibility of MXNet to maintain the assumption that 
downstream projects like horovod make in their building logic.

A more pressing issue should have been the way that a third-party communication 
library like horovod integrates with MXNet. So far the horovod integration 
seemed brittle and there have been many issues [2]. For this specific issue, to 
me, it doesn't seem like a good decision on the horovod side to assume any 
function would be defined inline on the MXNet side.

With the development of MXNet 2.0, it's a good time to rethink how horovod 
integration should work with MXNet. I'm hoping that MXNet 2.0 item 4.11 
AbstractKVStore interface (See #17115) could help simplify and alleviate the 
coupling in the current way of integration.

-sz

[1] 
https://github.com/apache/incubator-mxnet/pulls?utf8=%E2%9C%93=is%3Apr+label%3A%22API+change%22+
[2] 
https://github.com/apache/incubator-mxnet/issues?utf8=%E2%9C%93=is%3Aissue+horovod

On 2020/01/14 00:37:55, 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: CD with windows need a special jenkins slave machine like restricted-utility

[Pedro Larroy]

Thanks, it's working after updating to a 64 bit compiler.
https://github.com/apache/incubator-mxnet/pull/17206

On Mon, Jan 13, 2020 at 4:55 PM Pedro Larroy 
wrote:

> Isn't this something that gets selected through vcvars?
>
> On Fri, Jan 10, 2020 at 6:46 PM shiwen hu  wrote:
>
>> use x64 host msvc. cmake -T host=x64
>>
>> Pedro Larroy  于2020年1月10日周五 上午7:28写道：
>>
>> > Is there a solution for this error in VS2017?
>> >
>> > c:\users\administrator\mxnet\src\operator\mxnet_op.h(943) : fatal error
>> > C1002: compiler is out of heap space in pass 2
>> >
>> >
>> >
>> > On Tue, Jan 7, 2020 at 5:11 PM shiwen hu  wrote:
>> >
>> > > >
>> > > > I personally encountered the problem that 2015 can't compile in high
>> > > > version cuda. But I can't remember the details. We can continue to
>> use
>> > > 2015
>> > > > until we encounter problems.
>> > > >
>> > >
>> >
>>
>

[RESULTS] [VOTE] Release Apache MXNet (incubating) version 1.6.0.rc1

[Przemysław Trędak]

Dear MXNet community,

I'm happy to announce the results of the vote.

This vote passes with 13 +1 votes (5 binding) and no 0 or -1 votes.

+1 votes
* Zhi Zhang / binding
* Qing Lan / binding
* Markus Weimer / binding
* Haibin Lin / binding
* Jun Wu / binding
* Lin Yuan
* Lai Wei
* Xinyu Chen
* Guanxin Qiao
* Ciyong Chen
* Chaitanya Bapat
* Karan Jariwala
* Hao Jin

0 votes
* No votes

-1 votes
* No votes

Vote thread can be found here [1]. The list of members can be found here [2].

I'll continue with the release process and the release announcement will follow 
soon.


Best regards,
Przemyslaw Tredak

[1] 
https://lists.apache.org/thread.html/87ae98b5449459f40b536af12bfe4b701305a28071fe7bd2173465d8%40%3Cdev.mxnet.apache.org%3E
[2] http://incubator.apache.org/projects/mxnet.html