RE: Updates for 1.7.0 minor release

[Chen, Ciyong]

Hi Chai,

Thanks a lot for your kindly help to fix this 
I will continue the rest steps of release process.

Thanks,
-Ciyong

-Original Message-
From: Chaitanya Bapat  
Sent: Tuesday, May 12, 2020 8:14 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: Updates for 1.7.0 minor release

Hello Ciyong,

With the https://github.com/apache/incubator-mxnet/pull/18261 merged, nightly 
pipeline passes for 1.7.x So as far as the 2 nightly test pipelines are 
concerned [NightlyTests and NightlyTestsForBinaries] 1.7.x is good to go!

Thanks,
Chai

On Sun, 10 May 2020 at 04:53, Chen, Ciyong  wrote:

> Hi MXNet Community,
>
> Here's some updates after the code freeze.
> 1. Nightly tests[1] and nightly binaries tests[2] were enabled, many 
> thanks to Chaitanya who helped to create and activate these jobs for 
> v1.7.x branch.
> 2. A nightly test failure (incorrect with_seed path) was fixed by 
> Chaitanya [3] 3. A bug fix for external graph pass by Sam [4] 4. 
> Recently, there's another failed cased (test_large_vector.test_nn) in 
> nightly test[5], and Chaitanya is helping to address this issue[6]
>
> I'll keep monitoring the nightly test before making a rc0 tag.
> Please let me know if you have any other issues that should be 
> included/fixed in this release.
>
> Thanks,
> -Ciyong
>
> ---
> [1]
> http://jenkins.mxnet-ci.amazon-ml.com/view/Nightly%20Tests/job/Nightly
> Tests/job/v1.7.x/
> [2]
> http://jenkins.mxnet-ci.amazon-ml.com/view/Nightly%20Tests/job/Nightly
> TestsForBinaries/job/v1.7.x/ [3] 
> https://github.com/apache/incubator-mxnet/pull/18220
> [4] https://github.com/apache/incubator-mxnet/pull/18237
> [5]
> http://jenkins.mxnet-ci.amazon-ml.com/job/NightlyTestsForBinaries/job/
> v1.7.x/2/execution/node/232/log/ [6] 
> https://github.com/apache/incubator-mxnet/pull/18261
>
>
> -Original Message-
> From: Chen, Ciyong 
> Sent: Sunday, April 26, 2020 3:29 PM
> To: dev@mxnet.incubator.apache.org
> Cc: Marco de Abreu 
> Subject: Code freeze for 1.7.0 minor release
>
> Hi MXNet Community,
>
> Code freeze for 1.7.0 minor release is in effect (last commit: 38e6634)!
> Which means there're no more NEW features going to be accepted for 
> this release.
>
> Many thanks to everyone who helped submitting/back porting/reviewing 
> the PRs targeting this release.
> I've created a draft Release Notes for 1.7.0 release[1], please take a 
> review, any comments/suggestions are highly appreciated.
>
> Currently, the nightly test pipeline [2][3] for v1.7.x is not 
> triggered, cc @Marco de Abreu  marco.g.ab...@gmail.com> to help take a look.
> I will keep monitoring the nightly test result for the current code 
> base, and continue to go through the rest of releasing process.
>
> [1] 
> https://cwiki.apache.org/confluence/display/MXNET/1.7.0+Release+Notes
> [2]
> http://jenkins.mxnet-ci.amazon-ml.com/view/Nightly%20Tests/job/Nightly
> Tests/job/v1.7.x/
> [3]
> http://jenkins.mxnet-ci.amazon-ml.com/view/Nightly%20Tests/job/Nightly
> TestsForBinaries/job/v1.7.x/
>
>
> Thanks,
> -Ciyong
>
>

--
*Chaitanya Prakash Bapat*
*+1 (973) 953-6299*

[image: https://www.linkedin.com//in/chaibapat25]
[image: https://www.facebook.com/chaibapat]
[image:
https://twitter.com/ChaiBapchya] [image:
https://www.linkedin.com//in/chaibapat25]

Re: Updates for 1.7.0 minor release

[Chaitanya Bapat]

Hello Ciyong,

With the https://github.com/apache/incubator-mxnet/pull/18261 merged,
nightly pipeline passes for 1.7.x
So as far as the 2 nightly test pipelines are concerned [NightlyTests and
NightlyTestsForBinaries] 1.7.x is good to go!

Thanks,
Chai

On Sun, 10 May 2020 at 04:53, Chen, Ciyong  wrote:

> Hi MXNet Community,
>
> Here's some updates after the code freeze.
> 1. Nightly tests[1] and nightly binaries tests[2] were enabled, many
> thanks to Chaitanya who helped to create and activate these jobs for v1.7.x
> branch.
> 2. A nightly test failure (incorrect with_seed path) was fixed by
> Chaitanya [3]
> 3. A bug fix for external graph pass by Sam [4]
> 4. Recently, there's another failed cased (test_large_vector.test_nn) in
> nightly test[5], and Chaitanya is helping to address this issue[6]
>
> I'll keep monitoring the nightly test before making a rc0 tag.
> Please let me know if you have any other issues that should be
> included/fixed in this release.
>
> Thanks,
> -Ciyong
>
> ---
> [1]
> http://jenkins.mxnet-ci.amazon-ml.com/view/Nightly%20Tests/job/NightlyTests/job/v1.7.x/
> [2]
> http://jenkins.mxnet-ci.amazon-ml.com/view/Nightly%20Tests/job/NightlyTestsForBinaries/job/v1.7.x/
> [3] https://github.com/apache/incubator-mxnet/pull/18220
> [4] https://github.com/apache/incubator-mxnet/pull/18237
> [5]
> http://jenkins.mxnet-ci.amazon-ml.com/job/NightlyTestsForBinaries/job/v1.7.x/2/execution/node/232/log/
> [6] https://github.com/apache/incubator-mxnet/pull/18261
>
>
> -Original Message-
> From: Chen, Ciyong 
> Sent: Sunday, April 26, 2020 3:29 PM
> To: dev@mxnet.incubator.apache.org
> Cc: Marco de Abreu 
> Subject: Code freeze for 1.7.0 minor release
>
> Hi MXNet Community,
>
> Code freeze for 1.7.0 minor release is in effect (last commit: 38e6634)!
> Which means there're no more NEW features going to be accepted for this
> release.
>
> Many thanks to everyone who helped submitting/back porting/reviewing the
> PRs targeting this release.
> I've created a draft Release Notes for 1.7.0 release[1], please take a
> review, any comments/suggestions are highly appreciated.
>
> Currently, the nightly test pipeline [2][3] for v1.7.x is not triggered,
> cc @Marco de Abreu  marco.g.ab...@gmail.com> to help take a look.
> I will keep monitoring the nightly test result for the current code base,
> and continue to go through the rest of releasing process.
>
> [1] https://cwiki.apache.org/confluence/display/MXNET/1.7.0+Release+Notes
> [2]
> http://jenkins.mxnet-ci.amazon-ml.com/view/Nightly%20Tests/job/NightlyTests/job/v1.7.x/
> [3]
> http://jenkins.mxnet-ci.amazon-ml.com/view/Nightly%20Tests/job/NightlyTestsForBinaries/job/v1.7.x/
>
>
> Thanks,
> -Ciyong
>
>

-- 
*Chaitanya Prakash Bapat*
*+1 (973) 953-6299*

[image: https://www.linkedin.com//in/chaibapat25]
[image: https://www.facebook.com/chaibapat]
[image:
https://twitter.com/ChaiBapchya] [image:
https://www.linkedin.com//in/chaibapat25]

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

[Triston Cao]

Leonard,

We are seeking help from NVIDIA product and legal team. I will keep you guys 
update once there is any progress. 
Thanks,

-Triston

-Original Message-
From: Lausen, Leonard  
Sent: Monday, May 11, 2020 10:44 AM
To: dev@mxnet.incubator.apache.org
Cc: ptre...@apache.org; Triston Cao 
Subject: Re: Severe legal issues with releases on repository.apache.org

External email: Use caution opening links or attachments


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?

Triston helped to establish contact with the Nvidia Legal team and we're 
currently waiting for a response on their interpretation of the EULA as well as 
the possibility of an exception. It would be great to have an "internal lobby"
for granting an GCC Runtime Library Exception style exception for nvcc in 
general, or at least ASF in particular.

On Sun, 2020-05-10 at 08:52 -0700, Tianqi Chen wrote:
> 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

Currently https://issues.apache.org/jira/browse/LEGAL-515 asks similar 
questions to the Legal Team, but there is no conclusion yet. One open question 
in LEGAL-
515 is if the CD system managed in the project's source code at 
https://github.com/apache/incubator-mxnet/tree/master/cd can be seen as 
releasing third-party binaries given that it doesn't run on Apache 
infrastructure. In the "worst case" the CD in the ASF repo must be restricted 
to build ASF-compliant binaries and third-parties need to manage their own CD 
outside the Apache repo.

Once we have clarity on that, let's continue clarifying with the trademarks@ 
team.

Best regards
Leonard

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---

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

[Triston Cao]

Thank you, Leonard. 

Hi, Markus & Tianqi, 

It will be very helpful that you can summarize the issues.  I would be happy to 
coordinate from NVIDIA teams to see if we can address them appropriately. 

Thanks, 

-Triston 

-Original Message-
From: Lausen, Leonard  
Sent: Monday, May 11, 2020 10:44 AM
To: dev@mxnet.incubator.apache.org
Cc: ptre...@apache.org; Triston Cao 
Subject: Re: Severe legal issues with releases on repository.apache.org

External email: Use caution opening links or attachments


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?

Triston helped to establish contact with the Nvidia Legal team and we're 
currently waiting for a response on their interpretation of the EULA as well as 
the possibility of an exception. It would be great to have an "internal lobby"
for granting an GCC Runtime Library Exception style exception for nvcc in 
general, or at least ASF in particular.

On Sun, 2020-05-10 at 08:52 -0700, Tianqi Chen wrote:
> 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

Currently https://issues.apache.org/jira/browse/LEGAL-515 asks similar 
questions to the Legal Team, but there is no conclusion yet. One open question 
in LEGAL-
515 is if the CD system managed in the project's source code at 
https://github.com/apache/incubator-mxnet/tree/master/cd can be seen as 
releasing third-party binaries given that it doesn't run on Apache 
infrastructure. In the "worst case" the CD in the ASF repo must be restricted 
to build ASF-compliant binaries and third-parties need to manage their own CD 
outside the Apache repo.

Once we have clarity on that, let's continue clarifying with the trademarks@ 
team.

Best regards
Leonard

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---

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

[Carin Meier]

Does removing the jars from both of these solutions also remove them from
maven central?
>
>
> 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 so, either of these options has potential to cause major disruption for
users that depend on using them in production. If either of these actions
are deemed necessary, we should strive to provide communication to end
users and a solution for a process of how to replace them.


- Carin

On Mon, May 11, 2020 at 1:44 PM Lausen, Leonard 
wrote:

> 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?
>
> Triston helped to establish contact with the Nvidia Legal team and we're
> currently waiting for a response on their interpretation of the EULA as
> well as
> the possibility of an exception. It would be great to have an "internal
> lobby"
> for granting an GCC Runtime Library Exception style exception for nvcc in
> general, or at least ASF in particular.
>
> On Sun, 2020-05-10 at 08:52 -0700, Tianqi Chen wrote:
> > 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
>
> Currently https://issues.apache.org/jira/browse/LEGAL-515 asks similar
> questions
> to the Legal Team, but there is no conclusion yet. One open question in
> LEGAL-
> 515 is if the CD system managed in the project's source code at
> https://github.com/apache/incubator-mxnet/tree/master/cd can be seen as
> releasing third-party binaries given that it doesn't run on Apache
> infrastructure. In the "worst case" the CD in the ASF repo must be
> restricted to
> build ASF-compliant binaries and third-parties need to manage their own CD
> outside the Apache repo.
>
> Once we have clarity on that, let's continue clarifying with the
> trademarks@
> team.
>
> Best regards
> Leonard
>

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

[Lausen, Leonard]

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?

Triston helped to establish contact with the Nvidia Legal team and we're
currently waiting for a response on their interpretation of the EULA as well as
the possibility of an exception. It would be great to have an "internal lobby"
for granting an GCC Runtime Library Exception style exception for nvcc in
general, or at least ASF in particular.

On Sun, 2020-05-10 at 08:52 -0700, Tianqi Chen wrote:
> 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

Currently https://issues.apache.org/jira/browse/LEGAL-515 asks similar questions
to the Legal Team, but there is no conclusion yet. One open question in LEGAL-
515 is if the CD system managed in the project's source code at 
https://github.com/apache/incubator-mxnet/tree/master/cd can be seen as
releasing third-party binaries given that it doesn't run on Apache
infrastructure. In the "worst case" the CD in the ASF repo must be restricted to
build ASF-compliant binaries and third-parties need to manage their own CD
outside the Apache repo.

Once we have clarity on that, let's continue clarifying with the trademarks@
team.

Best regards
Leonard