Re: Release plan - MXNET 1.0.1

[Nan Zhu]

+1 and suggest consolidating all maintenance releases under the same
major.minor version into a single branch

On Wed, Jan 24, 2018 at 9:06 PM, Meghna Baijal 
wrote:

> I agree. If the release candidate is being cut from the master branch, it
> should be considered a minor release.
>
> Anyway the effort involved in the release process is exactly the same in
> either case.
>
> Thanks,
> Meghna
>
> On Jan 24, 2018 8:56 PM, "Marco de Abreu" 
> wrote:
>
> > Are there any particular reasons why we are classifying this release as
> > patch instead of minor release? As far as I know, we don't have any tests
> > in place to determine API changes and thus can't guarantee that this is
> an
> > actual patch release. Considering the fact that PRs have been merged
> > without having semantic versioning in place, this could be quite risky.
> >
> > Instead, I'd rather propose to make a minor release 1.1 instead of patch
> > release 1.0.1.
> >
> > -Marco
> >
> > Am 24.01.2018 7:20 nachm. schrieb "Zha, Sheng" :
> >
> > > There’s an experimental API for text data indexing and embedding in
> > > mx.contrib.text.
> > >
> > > - Sent by my thumb
> > >
> > > > On Jan 24, 2018, at 7:08 PM, Chris Olivier 
> > > wrote:
> > > >
> > > > the profiling PR contains a small breaking change, but i don’t think
> > it’s
> > > > going into 1.0.1
> > > >
> > > >> On Wed, Jan 24, 2018 at 6:48 PM Haibin Lin <
> haibin.lin@gmail.com>
> > > wrote:
> > > >>
> > > >> Hi everyone,
> > > >>
> > > >> Since the plan was to cut a branch from the master branch, the code
> > will
> > > >> include changes other than the bug fix PRs noted in the release
> note.
> > Is
> > > >> anyone aware of any API changes in the current MXNet master branch?
> In
> > > >> particular, are there backward incompatible ones?
> > > >>
> > > >> Best,
> > > >> Haibin
> > > >>
> > > >> On Tue, Jan 23, 2018 at 11:25 AM, Haibin Lin <
> > haibin.lin@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Hi Sheng,
> > > >>>
> > > >>> 1. I've been following the discussion on the branching & versioning
> > > >>> thread. Features like MKLDNN integration should not go to patch
> > release
> > > >>> 1.0.1, and it's risky to merge large PRs right before the release.
> > I've
> > > >>> removed the MKLDNN section from the release note.
> > https://cwiki.apache
> > > .
> > > >>> org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+
> > > >>> 1.0.1+Release+Notes
> > > >>>
> > > >>> 2. I agree that we should aim for better test coverage & stable CI,
> > and
> > > >>> get those disabled/flaky tests fixed eventually. Fixing these
> > requires
> > > >>> efforts from the community and I strongly encourage contributors to
> > > help.
> > > >>> Removing the corresponding feature from the release doesn't sound
> > > >> practical
> > > >>> since users might be already using some of those. I suggest that we
> > > keep
> > > >>> track of these tests on Apache Wiki and make sure they are
> addressed
> > > for
> > > >>> the release after 1.0.1.
> > > >>>
> > > >>> Hi everyone,
> > > >>>
> > > >>> In terms of the current status for this release, all critical bug
> > fixes
> > > >>> are merged (to the best of my knowledge) and we have made good
> > progress
> > > >>> fixing license issues. As Meghna mentioned, a list of open
> questions
> > > >>> regarding license is at
> > > >> https://cwiki.apache.org/confluence/display/MXNET/
> > > >>> MXNet+Source+Licenses section D - it would be great if we can get
> > more
> > > >>> clarification/help/feedback from Apache mentors.
> > > >>>
> > > >>> I suggest that we shoot for code freeze for 1.0.1 rc0 this
> Wednesday.
> > > >> Does
> > > >>> anyone have concern or objection on this?
> > > >>>
> > > >>> Best,
> > > >>> Haibin
> > > >>>
> > > >>> On Tue, Jan 23, 2018 at 7:51 AM, Steffen Rochel <
> > > steffenroc...@gmail.com
> > > >>>
> > > >>> wrote:
> > > >>>
> > >  Hi Sheng -
> > >  1. branch usage and versioning - lets converge our discussion and
> > > >> document
> > >  the agreement on wiki. I started a draft summarizing my
> > understanding
> > > of
> > >  the proposal at
> > >  https://cwiki.apache.org/confluence/display/MXNET/Release+
> > >  Versioning+and+Branching.
> > >  Lets work together to refine and clarify the draft, so we have
> > clarity
> > >  going forward. I'm inviting everyone to contribute to this
> > discussion.
> > >  As MKLDNN integration is not ready yet and we want to release all
> > the
> > > >> good
> > >  improvements including updates in tutorials and documentation I
> > > suggest
> > > >> we
> > >  move forward with the release asap. As we don't have major
> features
> > or
> > >  non-compatible API changes (to best of my knowledge) I think it is
> > >  appropriate to label the release as 1.0.1.
> > >  Note: This label indicates a patch release. Patch releases should
> be
> 

Re: Release plan - MXNET 1.0.1

[Meghna Baijal]

I agree. If the release candidate is being cut from the master branch, it
should be considered a minor release.

Anyway the effort involved in the release process is exactly the same in
either case.

Thanks,
Meghna

On Jan 24, 2018 8:56 PM, "Marco de Abreu" 
wrote:

> Are there any particular reasons why we are classifying this release as
> patch instead of minor release? As far as I know, we don't have any tests
> in place to determine API changes and thus can't guarantee that this is an
> actual patch release. Considering the fact that PRs have been merged
> without having semantic versioning in place, this could be quite risky.
>
> Instead, I'd rather propose to make a minor release 1.1 instead of patch
> release 1.0.1.
>
> -Marco
>
> Am 24.01.2018 7:20 nachm. schrieb "Zha, Sheng" :
>
> > There’s an experimental API for text data indexing and embedding in
> > mx.contrib.text.
> >
> > - Sent by my thumb
> >
> > > On Jan 24, 2018, at 7:08 PM, Chris Olivier 
> > wrote:
> > >
> > > the profiling PR contains a small breaking change, but i don’t think
> it’s
> > > going into 1.0.1
> > >
> > >> On Wed, Jan 24, 2018 at 6:48 PM Haibin Lin 
> > wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> Since the plan was to cut a branch from the master branch, the code
> will
> > >> include changes other than the bug fix PRs noted in the release note.
> Is
> > >> anyone aware of any API changes in the current MXNet master branch? In
> > >> particular, are there backward incompatible ones?
> > >>
> > >> Best,
> > >> Haibin
> > >>
> > >> On Tue, Jan 23, 2018 at 11:25 AM, Haibin Lin <
> haibin.lin@gmail.com>
> > >> wrote:
> > >>
> > >>> Hi Sheng,
> > >>>
> > >>> 1. I've been following the discussion on the branching & versioning
> > >>> thread. Features like MKLDNN integration should not go to patch
> release
> > >>> 1.0.1, and it's risky to merge large PRs right before the release.
> I've
> > >>> removed the MKLDNN section from the release note.
> https://cwiki.apache
> > .
> > >>> org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+
> > >>> 1.0.1+Release+Notes
> > >>>
> > >>> 2. I agree that we should aim for better test coverage & stable CI,
> and
> > >>> get those disabled/flaky tests fixed eventually. Fixing these
> requires
> > >>> efforts from the community and I strongly encourage contributors to
> > help.
> > >>> Removing the corresponding feature from the release doesn't sound
> > >> practical
> > >>> since users might be already using some of those. I suggest that we
> > keep
> > >>> track of these tests on Apache Wiki and make sure they are addressed
> > for
> > >>> the release after 1.0.1.
> > >>>
> > >>> Hi everyone,
> > >>>
> > >>> In terms of the current status for this release, all critical bug
> fixes
> > >>> are merged (to the best of my knowledge) and we have made good
> progress
> > >>> fixing license issues. As Meghna mentioned, a list of open questions
> > >>> regarding license is at
> > >> https://cwiki.apache.org/confluence/display/MXNET/
> > >>> MXNet+Source+Licenses section D - it would be great if we can get
> more
> > >>> clarification/help/feedback from Apache mentors.
> > >>>
> > >>> I suggest that we shoot for code freeze for 1.0.1 rc0 this Wednesday.
> > >> Does
> > >>> anyone have concern or objection on this?
> > >>>
> > >>> Best,
> > >>> Haibin
> > >>>
> > >>> On Tue, Jan 23, 2018 at 7:51 AM, Steffen Rochel <
> > steffenroc...@gmail.com
> > >>>
> > >>> wrote:
> > >>>
> >  Hi Sheng -
> >  1. branch usage and versioning - lets converge our discussion and
> > >> document
> >  the agreement on wiki. I started a draft summarizing my
> understanding
> > of
> >  the proposal at
> >  https://cwiki.apache.org/confluence/display/MXNET/Release+
> >  Versioning+and+Branching.
> >  Lets work together to refine and clarify the draft, so we have
> clarity
> >  going forward. I'm inviting everyone to contribute to this
> discussion.
> >  As MKLDNN integration is not ready yet and we want to release all
> the
> > >> good
> >  improvements including updates in tutorials and documentation I
> > suggest
> > >> we
> >  move forward with the release asap. As we don't have major features
> or
> >  non-compatible API changes (to best of my knowledge) I think it is
> >  appropriate to label the release as 1.0.1.
> >  Note: This label indicates a patch release. Patch releases should be
> >  created from the related release branch. As we didn't plan for it
> and
> > to
> >  minimize overhead I suggest we make a one time exception to cut the
> > >> 1.0.1
> >  release from master branch and clearly communicate in release notes.
> > >> Going
> >  forward we should follow the methodology for versioning and
> branching
> > to
> >  whatever we agree on.
> >  2. Disabled tests: I agree with your concerns that we had to disable
> > 13
> 

Re: Release plan - MXNET 1.0.1

[Marco de Abreu]

Are there any particular reasons why we are classifying this release as
patch instead of minor release? As far as I know, we don't have any tests
in place to determine API changes and thus can't guarantee that this is an
actual patch release. Considering the fact that PRs have been merged
without having semantic versioning in place, this could be quite risky.

Instead, I'd rather propose to make a minor release 1.1 instead of patch
release 1.0.1.

-Marco

Am 24.01.2018 7:20 nachm. schrieb "Zha, Sheng" :

> There’s an experimental API for text data indexing and embedding in
> mx.contrib.text.
>
> - Sent by my thumb
>
> > On Jan 24, 2018, at 7:08 PM, Chris Olivier 
> wrote:
> >
> > the profiling PR contains a small breaking change, but i don’t think it’s
> > going into 1.0.1
> >
> >> On Wed, Jan 24, 2018 at 6:48 PM Haibin Lin 
> wrote:
> >>
> >> Hi everyone,
> >>
> >> Since the plan was to cut a branch from the master branch, the code will
> >> include changes other than the bug fix PRs noted in the release note. Is
> >> anyone aware of any API changes in the current MXNet master branch? In
> >> particular, are there backward incompatible ones?
> >>
> >> Best,
> >> Haibin
> >>
> >> On Tue, Jan 23, 2018 at 11:25 AM, Haibin Lin 
> >> wrote:
> >>
> >>> Hi Sheng,
> >>>
> >>> 1. I've been following the discussion on the branching & versioning
> >>> thread. Features like MKLDNN integration should not go to patch release
> >>> 1.0.1, and it's risky to merge large PRs right before the release. I've
> >>> removed the MKLDNN section from the release note. https://cwiki.apache
> .
> >>> org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+
> >>> 1.0.1+Release+Notes
> >>>
> >>> 2. I agree that we should aim for better test coverage & stable CI, and
> >>> get those disabled/flaky tests fixed eventually. Fixing these requires
> >>> efforts from the community and I strongly encourage contributors to
> help.
> >>> Removing the corresponding feature from the release doesn't sound
> >> practical
> >>> since users might be already using some of those. I suggest that we
> keep
> >>> track of these tests on Apache Wiki and make sure they are addressed
> for
> >>> the release after 1.0.1.
> >>>
> >>> Hi everyone,
> >>>
> >>> In terms of the current status for this release, all critical bug fixes
> >>> are merged (to the best of my knowledge) and we have made good progress
> >>> fixing license issues. As Meghna mentioned, a list of open questions
> >>> regarding license is at
> >> https://cwiki.apache.org/confluence/display/MXNET/
> >>> MXNet+Source+Licenses section D - it would be great if we can get more
> >>> clarification/help/feedback from Apache mentors.
> >>>
> >>> I suggest that we shoot for code freeze for 1.0.1 rc0 this Wednesday.
> >> Does
> >>> anyone have concern or objection on this?
> >>>
> >>> Best,
> >>> Haibin
> >>>
> >>> On Tue, Jan 23, 2018 at 7:51 AM, Steffen Rochel <
> steffenroc...@gmail.com
> >>>
> >>> wrote:
> >>>
>  Hi Sheng -
>  1. branch usage and versioning - lets converge our discussion and
> >> document
>  the agreement on wiki. I started a draft summarizing my understanding
> of
>  the proposal at
>  https://cwiki.apache.org/confluence/display/MXNET/Release+
>  Versioning+and+Branching.
>  Lets work together to refine and clarify the draft, so we have clarity
>  going forward. I'm inviting everyone to contribute to this discussion.
>  As MKLDNN integration is not ready yet and we want to release all the
> >> good
>  improvements including updates in tutorials and documentation I
> suggest
> >> we
>  move forward with the release asap. As we don't have major features or
>  non-compatible API changes (to best of my knowledge) I think it is
>  appropriate to label the release as 1.0.1.
>  Note: This label indicates a patch release. Patch releases should be
>  created from the related release branch. As we didn't plan for it and
> to
>  minimize overhead I suggest we make a one time exception to cut the
> >> 1.0.1
>  release from master branch and clearly communicate in release notes.
> >> Going
>  forward we should follow the methodology for versioning and branching
> to
>  whatever we agree on.
>  2. Disabled tests: I agree with your concerns that we had to disable
> 13
>  tests due to non-deterministic behavior (see issues
>  ). I'm
> calling
> >> on
>  all contributors to help to resolve the non-deterministic behavior, so
> >> we
>  can improve our test coverage. As we discussed offline, lets tests
>  manually
>  short term, document the known issue in the release notes and
> prioritize
>  efforts post 1.0.1 release.
> 
>  Regards,
>  Steffen
> 
> > On Wed, Jan 17, 2018 at 5:05 PM Sheng Zha 
> 

Re: Release plan - MXNET 1.0.1

[Chris Olivier]

the profiling PR contains a small breaking change, but i don’t think it’s
going into 1.0.1

On Wed, Jan 24, 2018 at 6:48 PM Haibin Lin  wrote:

> Hi everyone,
>
> Since the plan was to cut a branch from the master branch, the code will
> include changes other than the bug fix PRs noted in the release note. Is
> anyone aware of any API changes in the current MXNet master branch? In
> particular, are there backward incompatible ones?
>
> Best,
> Haibin
>
> On Tue, Jan 23, 2018 at 11:25 AM, Haibin Lin 
> wrote:
>
> > Hi Sheng,
> >
> > 1. I've been following the discussion on the branching & versioning
> > thread. Features like MKLDNN integration should not go to patch release
> > 1.0.1, and it's risky to merge large PRs right before the release. I've
> > removed the MKLDNN section from the release note. https://cwiki.apache.
> > org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+
> > 1.0.1+Release+Notes
> >
> > 2. I agree that we should aim for better test coverage & stable CI, and
> > get those disabled/flaky tests fixed eventually. Fixing these requires
> > efforts from the community and I strongly encourage contributors to help.
> > Removing the corresponding feature from the release doesn't sound
> practical
> > since users might be already using some of those. I suggest that we keep
> > track of these tests on Apache Wiki and make sure they are addressed for
> > the release after 1.0.1.
> >
> > Hi everyone,
> >
> > In terms of the current status for this release, all critical bug fixes
> > are merged (to the best of my knowledge) and we have made good progress
> > fixing license issues. As Meghna mentioned, a list of open questions
> > regarding license is at
> https://cwiki.apache.org/confluence/display/MXNET/
> > MXNet+Source+Licenses section D - it would be great if we can get more
> > clarification/help/feedback from Apache mentors.
> >
> > I suggest that we shoot for code freeze for 1.0.1 rc0 this Wednesday.
> Does
> > anyone have concern or objection on this?
> >
> > Best,
> > Haibin
> >
> > On Tue, Jan 23, 2018 at 7:51 AM, Steffen Rochel  >
> > wrote:
> >
> >> Hi Sheng -
> >> 1. branch usage and versioning - lets converge our discussion and
> document
> >> the agreement on wiki. I started a draft summarizing my understanding of
> >> the proposal at
> >> https://cwiki.apache.org/confluence/display/MXNET/Release+
> >> Versioning+and+Branching.
> >> Lets work together to refine and clarify the draft, so we have clarity
> >> going forward. I'm inviting everyone to contribute to this discussion.
> >> As MKLDNN integration is not ready yet and we want to release all the
> good
> >> improvements including updates in tutorials and documentation I suggest
> we
> >> move forward with the release asap. As we don't have major features or
> >> non-compatible API changes (to best of my knowledge) I think it is
> >> appropriate to label the release as 1.0.1.
> >> Note: This label indicates a patch release. Patch releases should be
> >> created from the related release branch. As we didn't plan for it and to
> >> minimize overhead I suggest we make a one time exception to cut the
> 1.0.1
> >> release from master branch and clearly communicate in release notes.
> Going
> >> forward we should follow the methodology for versioning and branching to
> >> whatever we agree on.
> >> 2. Disabled tests: I agree with your concerns that we had to disable 13
> >> tests due to non-deterministic behavior (see issues
> >> ). I'm calling
> on
> >> all contributors to help to resolve the non-deterministic behavior, so
> we
> >> can improve our test coverage. As we discussed offline, lets tests
> >> manually
> >> short term, document the known issue in the release notes and prioritize
> >> efforts post 1.0.1 release.
> >>
> >> Regards,
> >> Steffen
> >>
> >> On Wed, Jan 17, 2018 at 5:05 PM Sheng Zha  wrote:
> >>
> >> > Hi Haibin,
> >> >
> >> > Thanks for leading this. I suggest that we hold onto this release
> until
> >> we
> >> > have clarity on the following items.
> >> >
> >> > 1. branch usage and versioning
> >> > Given that we are past 1.0 and we're changing APIs, I'd like to
> suggest
> >> > that we first agree on how
> >> > versioning works in mxnet. If we follow semantic versioning, it would
> >> > suggest that features like
> >> > MKL-DNN should go at least into 1.1 (minor version change) instead of
> >> > 1.0.1 (patch release).
> >> > Also, assuming that new release will come from a new forked branch, I
> >> > suggest that we clarify on how to
> >> > name the branches too.
> >> > You can find relevant thread at
> >> > https://lists.apache.org/thread.html/c52f8353f63c1e63b2646ec
> >> 3b08d9a8180a1381787d777b41b8ac69f@%3Cdev.mxnet.apache.org%3E
> >> >
> >> > 2. disabled tests
> >> > For the purpose of stabilizing test automation system, many tests were
> >> > 

Re: Release plan - MXNET 1.0.1

[Haibin Lin]

Hi everyone,

Since the plan was to cut a branch from the master branch, the code will
include changes other than the bug fix PRs noted in the release note. Is
anyone aware of any API changes in the current MXNet master branch? In
particular, are there backward incompatible ones?

Best,
Haibin

On Tue, Jan 23, 2018 at 11:25 AM, Haibin Lin 
wrote:

> Hi Sheng,
>
> 1. I've been following the discussion on the branching & versioning
> thread. Features like MKLDNN integration should not go to patch release
> 1.0.1, and it's risky to merge large PRs right before the release. I've
> removed the MKLDNN section from the release note. https://cwiki.apache.
> org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+
> 1.0.1+Release+Notes
>
> 2. I agree that we should aim for better test coverage & stable CI, and
> get those disabled/flaky tests fixed eventually. Fixing these requires
> efforts from the community and I strongly encourage contributors to help.
> Removing the corresponding feature from the release doesn't sound practical
> since users might be already using some of those. I suggest that we keep
> track of these tests on Apache Wiki and make sure they are addressed for
> the release after 1.0.1.
>
> Hi everyone,
>
> In terms of the current status for this release, all critical bug fixes
> are merged (to the best of my knowledge) and we have made good progress
> fixing license issues. As Meghna mentioned, a list of open questions
> regarding license is at https://cwiki.apache.org/confluence/display/MXNET/
> MXNet+Source+Licenses section D - it would be great if we can get more
> clarification/help/feedback from Apache mentors.
>
> I suggest that we shoot for code freeze for 1.0.1 rc0 this Wednesday. Does
> anyone have concern or objection on this?
>
> Best,
> Haibin
>
> On Tue, Jan 23, 2018 at 7:51 AM, Steffen Rochel 
> wrote:
>
>> Hi Sheng -
>> 1. branch usage and versioning - lets converge our discussion and document
>> the agreement on wiki. I started a draft summarizing my understanding of
>> the proposal at
>> https://cwiki.apache.org/confluence/display/MXNET/Release+
>> Versioning+and+Branching.
>> Lets work together to refine and clarify the draft, so we have clarity
>> going forward. I'm inviting everyone to contribute to this discussion.
>> As MKLDNN integration is not ready yet and we want to release all the good
>> improvements including updates in tutorials and documentation I suggest we
>> move forward with the release asap. As we don't have major features or
>> non-compatible API changes (to best of my knowledge) I think it is
>> appropriate to label the release as 1.0.1.
>> Note: This label indicates a patch release. Patch releases should be
>> created from the related release branch. As we didn't plan for it and to
>> minimize overhead I suggest we make a one time exception to cut the 1.0.1
>> release from master branch and clearly communicate in release notes. Going
>> forward we should follow the methodology for versioning and branching to
>> whatever we agree on.
>> 2. Disabled tests: I agree with your concerns that we had to disable 13
>> tests due to non-deterministic behavior (see issues
>> ). I'm calling on
>> all contributors to help to resolve the non-deterministic behavior, so we
>> can improve our test coverage. As we discussed offline, lets tests
>> manually
>> short term, document the known issue in the release notes and prioritize
>> efforts post 1.0.1 release.
>>
>> Regards,
>> Steffen
>>
>> On Wed, Jan 17, 2018 at 5:05 PM Sheng Zha  wrote:
>>
>> > Hi Haibin,
>> >
>> > Thanks for leading this. I suggest that we hold onto this release until
>> we
>> > have clarity on the following items.
>> >
>> > 1. branch usage and versioning
>> > Given that we are past 1.0 and we're changing APIs, I'd like to suggest
>> > that we first agree on how
>> > versioning works in mxnet. If we follow semantic versioning, it would
>> > suggest that features like
>> > MKL-DNN should go at least into 1.1 (minor version change) instead of
>> > 1.0.1 (patch release).
>> > Also, assuming that new release will come from a new forked branch, I
>> > suggest that we clarify on how to
>> > name the branches too.
>> > You can find relevant thread at
>> > https://lists.apache.org/thread.html/c52f8353f63c1e63b2646ec
>> 3b08d9a8180a1381787d777b41b8ac69f@%3Cdev.mxnet.apache.org%3E
>> >
>> > 2. disabled tests
>> > For the purpose of stabilizing test automation system, many tests were
>> > disabled. In order to avoid
>> > releasing untested features, we should mitigate the situation of having
>> > disabled tests.
>> > That means we can fix the tests before the release, or remove the
>> > corresponding feature from release
>> > (might be hard to do, e.g. for optimizer). Otherwise, we must
>> collectively
>> > decide that a feature is
>> > OK to release without tests.
>> > The thread on 

test_operator_gpu.test_correlation fails on Python 3 MKLML GPU

[Marco de Abreu]

Hello,

we just had a test failure in test_operator_gpu.test_correlation (sourced
from unittest/test_operator.py) on the master branch (tracked at
https://github.com/apache/incubator-mxnet/issues/9553).

Could somebody please have a look?

Best regards,
Marco

Re: Please Help Fix MXNet Licensing Issues for the next Release!

[Meghna Baijal]

Marco,
Thanks a lot for looking through this ! Some comments below -

   1. *R-package:* Before we create the final tarball for the release, the
   R-package is explicitly removed from the cloned MXNet repo. The only info I
   have in this regard is that “there are some unresolved licensing issues in
   this package and cannot be released”.
   2. *Dockerfiles:* You can refer to this PR for details
   https://github.com/apache/incubator-mxnet/pull/9500. I plan to handle
   this differently next time.
   3. *perl-package*: There were some copyright issues in the past with
   this folder. I just excluded it to be on the safer side, but I think it
   should be ok to add the ASF header here.
   4. *docs/** - Yes, agreed. I will add the licenses where needed but I
   still think its safer to exclude the folder as a whole from the RAT check.
   5. *CODEOWNERS* - agreed, will add to the list of excluded files.
   6. *appveyor.yml:* Is this file relevant anymore? I will add a license
   anyway.
   7. *tests/ci_build/pylintrc:* ok
   8. *example/image-classification/predict-cpp/image-classification-predict.cc
   * - yes, mutiple opinions on this one
   during the voting process too.
   9. *gradle-wrapper *- yes, I remember that one too. I am hoping for some
   suggestion on how this can be handled without breaking anything.

Best,
Meghna

On Wed, Jan 24, 2018 at 4:47 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> Hi Meghna,
>
> thank you for driving the licensing issues!
>
> - R-package: In the linked wiki, you're mentioning that R-package is not a
> part of the release. Could you please elaborate? From my understand, all
> files in the GitHub repository are part of the release.
> - Dockerfiles: I just checked another Apache-project [1] and it seems like
> they are successfully applying the license to dockerfiles. Do you see any
> issues in doing so?
> - perl-package: Same as R-package
> - docs/*: Just my personal opinion, but I agree that it might not be a good
> idea to have the license inside every file as some of them are directly
> getting sent out. But we have some shell-scripts inside this directory, so
> they'll need proper licensing.
> - CODEOWNERS: This is a setting file got our GitHub repository and not part
> of the release or the software itself. Thus I'd say that there's no need
> for a license - especially considering that the content itself has no
> value.
> - appveyor.yml: I'd treat this like the Jenkinsfile and apply a license.
> - tests/ci_build/pylintrc: I'd add a license
> - example/image-classification/predict-cpp/image-
> classification-predict.cc:
> It seems like Mu has had issues with the licensing of this file in the
> past. Maybe consult him
> - gradle-wrapper: I don't have a link, but I'm very sure that there was a
> discussion regarding this jar-file during the last release.
>
> Anybody, please feel free to correct me if I made a wrong assumption.
>
> Best regards,
> Marco
>
> [1]: https://github.com/apache/bookkeeper/blob/master/docker/Dockerfile
>
> On Wed, Jan 24, 2018 at 4:27 PM, Meghna Baijal  >
> wrote:
>
> > Hello,
> >
> > This is an update on the current status of the license fixes (all details
> > in the wiki linked below)–
> >
> >1. I am constantly updating this wiki, so you can check it at any time
> >to know the status -
> >https://cwiki.apache.org/confluence/display/MXNET/
> MXNet+Source+Licenses
> >2. All 7 PRs have been merged however if anyone has any comments on
> >these changes please let me know.
> >3. There are still 6-7 files that do not have a license and are
> failing
> >the RAT check. These are files I was not entirely confident about
> > adding an
> >apache header to.
> >4. There is a list of file formats, files and directories that have
> >currently been excluded from the RAT check. I have mentioned the exact
> >reason for adding these to this list in the wiki. However, this list
> > needs
> >to be reviewed and validated.
> >
> >
> > *Coming Up Later –*
> >
> > *1. *Once points 3 and 4 above have been fixed, I will set up a RAT job
> in
> > CI which will run a nightly check (This is currently being run in a local
> > Jenkins setup)
> >
> > 2. I will also add a rat-excludes file to the mxnet repo so that anyone
> can
> > run a RAT check locally to check the licenses.
> >
> >
> > I am still looking for the MXNet community and the Mentors to review the
> > open questions in the wiki and help me resolve these before the upcoming
> > release!
> >
> >
> > Thank you,
> >
> > Meghna Baijal
> >
> >
> >
> > On Thu, Jan 18, 2018 at 9:14 PM, Meghna Baijal <
> meghnabaijal2...@gmail.com
> > >
> > wrote:
> >
> > > Hello All!
> > >
> > > I am currently attempting to fix the licensing issues in MXNet. These
> are
> > > being tracked in this wiki -
> > >
> > > *https://cwiki.apache.org/confluence/display/MXNET/
> MXNet+Source+Licenses
> > > 

Re: Please Help Fix MXNet Licensing Issues for the next Release!

[Marco de Abreu]

Hi Meghna,

thank you for driving the licensing issues!

- R-package: In the linked wiki, you're mentioning that R-package is not a
part of the release. Could you please elaborate? From my understand, all
files in the GitHub repository are part of the release.
- Dockerfiles: I just checked another Apache-project [1] and it seems like
they are successfully applying the license to dockerfiles. Do you see any
issues in doing so?
- perl-package: Same as R-package
- docs/*: Just my personal opinion, but I agree that it might not be a good
idea to have the license inside every file as some of them are directly
getting sent out. But we have some shell-scripts inside this directory, so
they'll need proper licensing.
- CODEOWNERS: This is a setting file got our GitHub repository and not part
of the release or the software itself. Thus I'd say that there's no need
for a license - especially considering that the content itself has no value.
- appveyor.yml: I'd treat this like the Jenkinsfile and apply a license.
- tests/ci_build/pylintrc: I'd add a license
- example/image-classification/predict-cpp/image-classification-predict.cc:
It seems like Mu has had issues with the licensing of this file in the
past. Maybe consult him
- gradle-wrapper: I don't have a link, but I'm very sure that there was a
discussion regarding this jar-file during the last release.

Anybody, please feel free to correct me if I made a wrong assumption.

Best regards,
Marco

[1]: https://github.com/apache/bookkeeper/blob/master/docker/Dockerfile

On Wed, Jan 24, 2018 at 4:27 PM, Meghna Baijal 
wrote:

> Hello,
>
> This is an update on the current status of the license fixes (all details
> in the wiki linked below)–
>
>1. I am constantly updating this wiki, so you can check it at any time
>to know the status -
>https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses
>2. All 7 PRs have been merged however if anyone has any comments on
>these changes please let me know.
>3. There are still 6-7 files that do not have a license and are failing
>the RAT check. These are files I was not entirely confident about
> adding an
>apache header to.
>4. There is a list of file formats, files and directories that have
>currently been excluded from the RAT check. I have mentioned the exact
>reason for adding these to this list in the wiki. However, this list
> needs
>to be reviewed and validated.
>
>
> *Coming Up Later –*
>
> *1. *Once points 3 and 4 above have been fixed, I will set up a RAT job in
> CI which will run a nightly check (This is currently being run in a local
> Jenkins setup)
>
> 2. I will also add a rat-excludes file to the mxnet repo so that anyone can
> run a RAT check locally to check the licenses.
>
>
> I am still looking for the MXNet community and the Mentors to review the
> open questions in the wiki and help me resolve these before the upcoming
> release!
>
>
> Thank you,
>
> Meghna Baijal
>
>
>
> On Thu, Jan 18, 2018 at 9:14 PM, Meghna Baijal  >
> wrote:
>
> > Hello All!
> >
> > I am currently attempting to fix the licensing issues in MXNet. These are
> > being tracked in this wiki -
> >
> > *https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses
> >  >*
> >
> > You can follow the links in this wiki to find the following details -
> > 1. Links to relevant email threads which point the license issues out.
> > 2. Links to Github Issues created based on these emails.
> > 3. Apache pages which details the licensing policies.
> > 4. *The PRs created to fix these issues.* (These need review and all help
> > is welcome!)
> > 5. A table to track the high level issues and their progress.
> > 6. And a list of open *issues/questions/doubts/concerns* that need some
> > answers.
> >
> > I would appreciate any comments/ feedback/ suggestions from the community
> > regarding this work and it would be particularly helpful if you could
> > help review and validate the PRs and other planned changes.
> >
> > This is still a work in progress and there are a few files/folders that
> > are currently excluded from the Apache RAT checks. Also, there are around
> > 30 files that are still failing Apache RAT check (both lists are in the
> > wiki). If you know how to fix any of these remaining issues, please let
> me
> > know or even better create a PR!
> >
> > Do let me know if I can provide more details on any of the points.
> >
> > Thanks,
> > Meghna Baijal
> >
>

Re: Please Help Fix MXNet Licensing Issues for the next Release!

[Meghna Baijal]

Hello,

This is an update on the current status of the license fixes (all details
in the wiki linked below)–

   1. I am constantly updating this wiki, so you can check it at any time
   to know the status -
   https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses
   2. All 7 PRs have been merged however if anyone has any comments on
   these changes please let me know.
   3. There are still 6-7 files that do not have a license and are failing
   the RAT check. These are files I was not entirely confident about adding an
   apache header to.
   4. There is a list of file formats, files and directories that have
   currently been excluded from the RAT check. I have mentioned the exact
   reason for adding these to this list in the wiki. However, this list needs
   to be reviewed and validated.


*Coming Up Later –*

*1. *Once points 3 and 4 above have been fixed, I will set up a RAT job in
CI which will run a nightly check (This is currently being run in a local
Jenkins setup)

2. I will also add a rat-excludes file to the mxnet repo so that anyone can
run a RAT check locally to check the licenses.


I am still looking for the MXNet community and the Mentors to review the
open questions in the wiki and help me resolve these before the upcoming
release!


Thank you,

Meghna Baijal



On Thu, Jan 18, 2018 at 9:14 PM, Meghna Baijal 
wrote:

> Hello All!
>
> I am currently attempting to fix the licensing issues in MXNet. These are
> being tracked in this wiki -
>
> *https://cwiki.apache.org/confluence/display/MXNET/MXNet+Source+Licenses
> *
>
> You can follow the links in this wiki to find the following details -
> 1. Links to relevant email threads which point the license issues out.
> 2. Links to Github Issues created based on these emails.
> 3. Apache pages which details the licensing policies.
> 4. *The PRs created to fix these issues.* (These need review and all help
> is welcome!)
> 5. A table to track the high level issues and their progress.
> 6. And a list of open *issues/questions/doubts/concerns* that need some
> answers.
>
> I would appreciate any comments/ feedback/ suggestions from the community
> regarding this work and it would be particularly helpful if you could
> help review and validate the PRs and other planned changes.
>
> This is still a work in progress and there are a few files/folders that
> are currently excluded from the Apache RAT checks. Also, there are around
> 30 files that are still failing Apache RAT check (both lists are in the
> wiki). If you know how to fix any of these remaining issues, please let me
> know or even better create a PR!
>
> Do let me know if I can provide more details on any of the points.
>
> Thanks,
> Meghna Baijal
>

cuda CUDNN auto tune, optimal parameters of cuda kernels

[Pedro Larroy]

Hi

We have identified that cuda cudnn autotune produces a significant
spike of ram usage when finding the best convolution algorithm.

As far as we understand this is inside the cudnn library. But in
platforms like the TX1 where we only have 4G this is problematic as
the spike is close to 4G.

auto tune can be disabled with an environment variable, but for these
platforms might be interesting to save these kind of parameters once
and not have them run every time at runtime, otherwise you are
probably doing convolutions with slower kernels.

The second topic I wanted to bring up is, would it be a good idea to
have configurable kernel launch parameters to optimize SM resource
utilization?

Either via maybe a compile time approach based on the target arch:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4640924/

Or based on a runtime profile.

Any thoughts on these topics?

Pedro.