Re: Stop redistributing source code of 3rdparty dependencies to avoid licensing issues

[Marco de Abreu]

I agree with Tianqi. We may change our build system, but this won't free us
from the necessity to validate the licenses of our dependencies.

The question at this point is whether we are allowed to differentiate
between our main-source and hold it to the strict standards while treating
the third party folder as dependency, where we only have to verify that the
projects are licensed with an Apache compatible license.

At the moment, the project already treats them different: our license
checks exclude third party. I think this is where the disparity is coming
from. I'd recommend we discuss with Apache how we can handle this
situation: package third party code for user convenience while limiting
responsibility.

In the end, we still have to ensure that everything is licensed properly,
so maybe we should try to align both processes to match the real world
instead of changing the real world to match the process.

-Marco

Tianqi Chen  schrieb am Fr., 17. Jan. 2020, 20:44:

> I don't have an opinion, but would like to list pros and cons of doing so.
>
> The pro of doing so is that it indeed simplifies the release process, as
> these additional dependencies becomes category-B level dependencies as in
> https://www.apache.org/legal/resolved.html
>
> The con of doing so is that it brings additional burden to the users of the
> software to check the license of these dependencies, in some sense,
> including these information in the
> license actually gives an extra level of transparency.
>
> The copyright message in some of the dependencies are a bit unfortunate,
> one potential way to run the check is to write a python script to go
> through the files and detect the line Copyright and cross match and add
> them.
>
> Note that good models to follow are
> - hadoop: https://github.com/apache/hadoop/tree/trunk/licenses
> - flink: https://github.com/apache/flink
>
> Each of the repo have a licenses folder that contains licenses, and things
> points to them.
>
> I am not a lawyer, but the case for ps-lite seems can be resolved as long
> as we can confirm these files follows Apache-2.0, as
> https://www.apache.org/licenses/LICENSE-2.0 only requires us to
> redistribute
> the license and anything in the NOTICE, but we do not have the obligation
> to list all the copyright messages in the source content.
>
> TQ
>
> On Fri, Jan 17, 2020 at 11:10 AM Yuan Tang 
> wrote:
>
> > +1
> >
> > On Fri, Jan 17, 2020 at 1:59 PM Chris Olivier 
> > wrote:
> >
> > > +1
> > >
> > > On Fri, Jan 17, 2020 at 10:19 AM Lausen, Leonard
> >  > > >
> > > wrote:
> > >
> > > > Dear MXNet community,
> > > >
> > > > as per recent mail on gene...@incubator.apache.org [1] there are a
> > > number
> > > > of
> > > > licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I
> believe
> > > > there
> > > > has been no release so far without any licensing issues, which is a
> > > > blocker to
> > > > MXNet graduating from it's incubating status. One contributing factor
> > is
> > > > that we
> > > > bundle 3rdparty source code in our releases [2].
> > > >
> > > > One key factor is that 3rdparty projects don't always enforce
> licensing
> > > > best
> > > > practice in the way we do. For example, 3rdparty/ps-lite doesn't
> > enforce
> > > > license
> > > > headers in the source files and there has been confusion about the
> > > license
> > > > of
> > > > recent contributions by ByteDance (See [1]).
> > > >
> > > > To avoid such licensing issues in MXNet releases a simple solution is
> > to
> > > > stop
> > > > distributing the 3rdparty code in our source releases. Instead, we
> can
> > > > adapt our
> > > > buildsystem to download 3rdparty code as part of the build
> > configuration
> > > > process. CMake makes this very easy with the FetchContent module [3].
> > > >
> > > > For development purpose involving changes to the 3rdparty source or
> > build
> > > > systems that can't access the internet, there are easy means for
> > > > specifying the
> > > > location of local sources (instead of downloading), via the
> > > > FETCHCONTENT_SOURCE_DIR_ variable [4].
> > > >
> > > > Would there be any concerns about such approach? Obviously it can
> only
> > be
> > > > fully
> > > > implemented as soon as the CMake build system is feature complete and
> > the
> > > > Makefile build can be dropped. (Note that the Makefile build is being
> > > > deprecated
> > > > and removed as part of MXNet 2 roadmap [5])
> > > >
> > > > Best regards
> > > > Leonard
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E
> > > > [2]: See the .tar.gz files at
> > > > https://incubator.apache.org/clutch/mxnet.html
> > > > [3]: https://cmake.org/cmake/help/latest/module/FetchContent.html
> > > > [4]: https://cmake.org/pipermail/cmake/2019-June/069709.html
> > > > [5]: https://github.com/apache/incubator-mxnet/issues/16167
> > > >
> > >
> >
>

Re: Stop redistributing source code of 3rdparty dependencies to avoid licensing issues

[Tianqi Chen]

I don't have an opinion, but would like to list pros and cons of doing so.

The pro of doing so is that it indeed simplifies the release process, as
these additional dependencies becomes category-B level dependencies as in
https://www.apache.org/legal/resolved.html

The con of doing so is that it brings additional burden to the users of the
software to check the license of these dependencies, in some sense,
including these information in the
license actually gives an extra level of transparency.

The copyright message in some of the dependencies are a bit unfortunate,
one potential way to run the check is to write a python script to go
through the files and detect the line Copyright and cross match and add
them.

Note that good models to follow are
- hadoop: https://github.com/apache/hadoop/tree/trunk/licenses
- flink: https://github.com/apache/flink

Each of the repo have a licenses folder that contains licenses, and things
points to them.

I am not a lawyer, but the case for ps-lite seems can be resolved as long
as we can confirm these files follows Apache-2.0, as
https://www.apache.org/licenses/LICENSE-2.0 only requires us to redistribute
the license and anything in the NOTICE, but we do not have the obligation
to list all the copyright messages in the source content.

TQ

On Fri, Jan 17, 2020 at 11:10 AM Yuan Tang  wrote:

> +1
>
> On Fri, Jan 17, 2020 at 1:59 PM Chris Olivier 
> wrote:
>
> > +1
> >
> > On Fri, Jan 17, 2020 at 10:19 AM Lausen, Leonard
>  > >
> > wrote:
> >
> > > Dear MXNet community,
> > >
> > > as per recent mail on gene...@incubator.apache.org [1] there are a
> > number
> > > of
> > > licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I believe
> > > there
> > > has been no release so far without any licensing issues, which is a
> > > blocker to
> > > MXNet graduating from it's incubating status. One contributing factor
> is
> > > that we
> > > bundle 3rdparty source code in our releases [2].
> > >
> > > One key factor is that 3rdparty projects don't always enforce licensing
> > > best
> > > practice in the way we do. For example, 3rdparty/ps-lite doesn't
> enforce
> > > license
> > > headers in the source files and there has been confusion about the
> > license
> > > of
> > > recent contributions by ByteDance (See [1]).
> > >
> > > To avoid such licensing issues in MXNet releases a simple solution is
> to
> > > stop
> > > distributing the 3rdparty code in our source releases. Instead, we can
> > > adapt our
> > > buildsystem to download 3rdparty code as part of the build
> configuration
> > > process. CMake makes this very easy with the FetchContent module [3].
> > >
> > > For development purpose involving changes to the 3rdparty source or
> build
> > > systems that can't access the internet, there are easy means for
> > > specifying the
> > > location of local sources (instead of downloading), via the
> > > FETCHCONTENT_SOURCE_DIR_ variable [4].
> > >
> > > Would there be any concerns about such approach? Obviously it can only
> be
> > > fully
> > > implemented as soon as the CMake build system is feature complete and
> the
> > > Makefile build can be dropped. (Note that the Makefile build is being
> > > deprecated
> > > and removed as part of MXNet 2 roadmap [5])
> > >
> > > Best regards
> > > Leonard
> > >
> > > [1]:
> > >
> > >
> >
> https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E
> > > [2]: See the .tar.gz files at
> > > https://incubator.apache.org/clutch/mxnet.html
> > > [3]: https://cmake.org/cmake/help/latest/module/FetchContent.html
> > > [4]: https://cmake.org/pipermail/cmake/2019-June/069709.html
> > > [5]: https://github.com/apache/incubator-mxnet/issues/16167
> > >
> >
>

Re: Stop redistributing source code of 3rdparty dependencies to avoid licensing issues

[Yuan Tang]

+1

On Fri, Jan 17, 2020 at 1:59 PM Chris Olivier  wrote:

> +1
>
> On Fri, Jan 17, 2020 at 10:19 AM Lausen, Leonard  >
> wrote:
>
> > Dear MXNet community,
> >
> > as per recent mail on gene...@incubator.apache.org [1] there are a
> number
> > of
> > licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I believe
> > there
> > has been no release so far without any licensing issues, which is a
> > blocker to
> > MXNet graduating from it's incubating status. One contributing factor is
> > that we
> > bundle 3rdparty source code in our releases [2].
> >
> > One key factor is that 3rdparty projects don't always enforce licensing
> > best
> > practice in the way we do. For example, 3rdparty/ps-lite doesn't enforce
> > license
> > headers in the source files and there has been confusion about the
> license
> > of
> > recent contributions by ByteDance (See [1]).
> >
> > To avoid such licensing issues in MXNet releases a simple solution is to
> > stop
> > distributing the 3rdparty code in our source releases. Instead, we can
> > adapt our
> > buildsystem to download 3rdparty code as part of the build configuration
> > process. CMake makes this very easy with the FetchContent module [3].
> >
> > For development purpose involving changes to the 3rdparty source or build
> > systems that can't access the internet, there are easy means for
> > specifying the
> > location of local sources (instead of downloading), via the
> > FETCHCONTENT_SOURCE_DIR_ variable [4].
> >
> > Would there be any concerns about such approach? Obviously it can only be
> > fully
> > implemented as soon as the CMake build system is feature complete and the
> > Makefile build can be dropped. (Note that the Makefile build is being
> > deprecated
> > and removed as part of MXNet 2 roadmap [5])
> >
> > Best regards
> > Leonard
> >
> > [1]:
> >
> >
> https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E
> > [2]: See the .tar.gz files at
> > https://incubator.apache.org/clutch/mxnet.html
> > [3]: https://cmake.org/cmake/help/latest/module/FetchContent.html
> > [4]: https://cmake.org/pipermail/cmake/2019-June/069709.html
> > [5]: https://github.com/apache/incubator-mxnet/issues/16167
> >
>

Re: Stop redistributing source code of 3rdparty dependencies to avoid licensing issues

[Chris Olivier]

+1

On Fri, Jan 17, 2020 at 10:19 AM Lausen, Leonard 
wrote:

> Dear MXNet community,
>
> as per recent mail on gene...@incubator.apache.org [1] there are a number
> of
> licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I believe
> there
> has been no release so far without any licensing issues, which is a
> blocker to
> MXNet graduating from it's incubating status. One contributing factor is
> that we
> bundle 3rdparty source code in our releases [2].
>
> One key factor is that 3rdparty projects don't always enforce licensing
> best
> practice in the way we do. For example, 3rdparty/ps-lite doesn't enforce
> license
> headers in the source files and there has been confusion about the license
> of
> recent contributions by ByteDance (See [1]).
>
> To avoid such licensing issues in MXNet releases a simple solution is to
> stop
> distributing the 3rdparty code in our source releases. Instead, we can
> adapt our
> buildsystem to download 3rdparty code as part of the build configuration
> process. CMake makes this very easy with the FetchContent module [3].
>
> For development purpose involving changes to the 3rdparty source or build
> systems that can't access the internet, there are easy means for
> specifying the
> location of local sources (instead of downloading), via the
> FETCHCONTENT_SOURCE_DIR_ variable [4].
>
> Would there be any concerns about such approach? Obviously it can only be
> fully
> implemented as soon as the CMake build system is feature complete and the
> Makefile build can be dropped. (Note that the Makefile build is being
> deprecated
> and removed as part of MXNet 2 roadmap [5])
>
> Best regards
> Leonard
>
> [1]:
>
> https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E
> [2]: See the .tar.gz files at
> https://incubator.apache.org/clutch/mxnet.html
> [3]: https://cmake.org/cmake/help/latest/module/FetchContent.html
> [4]: https://cmake.org/pipermail/cmake/2019-June/069709.html
> [5]: https://github.com/apache/incubator-mxnet/issues/16167
>

Re: MXNet 1.6 as last release with Python 2 support?

[Lai Wei]

+1


Best Regards

Lai


On Fri, Jan 17, 2020 at 10:39 AM Lin Yuan  wrote:

> +1
>
> On Fri, Jan 17, 2020 at 10:04 AM Xingjian SHI 
> wrote:
>
> > +1. We should move to support Python>=3.5 only.
> >
> > Get Outlook for iOS
> > 
> > From: Lausen, Leonard 
> > Sent: Friday, January 17, 2020 10:02:30 AM
> > To: d...@mxnet.apache.org 
> > Subject: Re: MXNet 1.6 as last release with Python 2 support?
> >
> > If the lazy consensus passes, I believe the minimum Python version
> > supported
> > would be Python 3.5.
> >
> > Python 3.5 because it seems to be the minimum Python 3 version tested by
> > our CI,
> > specifically in the jobs running on Ubuntu 16.04.
> >
> > Best regards
> > Leonard
> >
> > On Fri, 2020-01-17 at 17:36 +, Lausen, Leonard wrote:
> > > Dear MXNet community,
> > >
> > > as effective January 1, 2020, no new bug reports, fixes, or changes
> will
> > be
> > > made
> > > to Python 2, and as MXNet 1.6 will be released after January 1, 2020, I
> > > suggest
> > > to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last
> > release
> > > supporting Python 2.
> > >
> > > We have previously reached consensus on announcing that Python 2 is
> > dropped in
> > > the next major release (ie. MXNet 2), however, given the delay in 1.6
> > release,
> > > the plan to release 1.7 in the future and that Python 2 is dead
> already I
> > > think
> > > we can revisit this assumption.
> > >
> > > Advantages are
> > > - Time savings for developers, as Python 3 standard library contains
> more
> > >   features than Python 2, and it is more efficient to target only 1
> > language
> > >   (Python 3) instead of 2 languages (Python 2 & 3)
> > > - Simplification and cost savings for CI
> > >
> > > I thus suggest 72h lazy consensus for announcing dropping of Python 2
> as
> > > described above. If you disagree, please veto (send "-1") and we can
> > continue
> > > supporting Python 2 in all 1.x releases as per previous consensus. Note
> > that
> > > at
> > > the time of previous consensus, no 1.7 release was planned.
> > >
> > > Best regards
> > > Leonard
> >
>

Re: MXNet 1.6 as last release with Python 2 support?

[Lin Yuan]

+1

On Fri, Jan 17, 2020 at 10:04 AM Xingjian SHI  wrote:

> +1. We should move to support Python>=3.5 only.
>
> Get Outlook for iOS
> 
> From: Lausen, Leonard 
> Sent: Friday, January 17, 2020 10:02:30 AM
> To: d...@mxnet.apache.org 
> Subject: Re: MXNet 1.6 as last release with Python 2 support?
>
> If the lazy consensus passes, I believe the minimum Python version
> supported
> would be Python 3.5.
>
> Python 3.5 because it seems to be the minimum Python 3 version tested by
> our CI,
> specifically in the jobs running on Ubuntu 16.04.
>
> Best regards
> Leonard
>
> On Fri, 2020-01-17 at 17:36 +, Lausen, Leonard wrote:
> > Dear MXNet community,
> >
> > as effective January 1, 2020, no new bug reports, fixes, or changes will
> be
> > made
> > to Python 2, and as MXNet 1.6 will be released after January 1, 2020, I
> > suggest
> > to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last
> release
> > supporting Python 2.
> >
> > We have previously reached consensus on announcing that Python 2 is
> dropped in
> > the next major release (ie. MXNet 2), however, given the delay in 1.6
> release,
> > the plan to release 1.7 in the future and that Python 2 is dead already I
> > think
> > we can revisit this assumption.
> >
> > Advantages are
> > - Time savings for developers, as Python 3 standard library contains more
> >   features than Python 2, and it is more efficient to target only 1
> language
> >   (Python 3) instead of 2 languages (Python 2 & 3)
> > - Simplification and cost savings for CI
> >
> > I thus suggest 72h lazy consensus for announcing dropping of Python 2 as
> > described above. If you disagree, please veto (send "-1") and we can
> continue
> > supporting Python 2 in all 1.x releases as per previous consensus. Note
> that
> > at
> > the time of previous consensus, no 1.7 release was planned.
> >
> > Best regards
> > Leonard
>

Stop redistributing source code of 3rdparty dependencies to avoid licensing issues

[Lausen, Leonard]

Dear MXNet community,

as per recent mail on gene...@incubator.apache.org [1] there are a number of
licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I believe there
has been no release so far without any licensing issues, which is a blocker to
MXNet graduating from it's incubating status. One contributing factor is that we
bundle 3rdparty source code in our releases [2].

One key factor is that 3rdparty projects don't always enforce licensing best
practice in the way we do. For example, 3rdparty/ps-lite doesn't enforce license
headers in the source files and there has been confusion about the license of
recent contributions by ByteDance (See [1]).

To avoid such licensing issues in MXNet releases a simple solution is to stop
distributing the 3rdparty code in our source releases. Instead, we can adapt our
buildsystem to download 3rdparty code as part of the build configuration
process. CMake makes this very easy with the FetchContent module [3].

For development purpose involving changes to the 3rdparty source or build
systems that can't access the internet, there are easy means for specifying the
location of local sources (instead of downloading), via the
FETCHCONTENT_SOURCE_DIR_ variable [4].

Would there be any concerns about such approach? Obviously it can only be fully
implemented as soon as the CMake build system is feature complete and the
Makefile build can be dropped. (Note that the Makefile build is being deprecated
and removed as part of MXNet 2 roadmap [5])

Best regards
Leonard

[1]: 
https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E
[2]: See the .tar.gz files at https://incubator.apache.org/clutch/mxnet.html
[3]: https://cmake.org/cmake/help/latest/module/FetchContent.html
[4]: https://cmake.org/pipermail/cmake/2019-June/069709.html
[5]: https://github.com/apache/incubator-mxnet/issues/16167

Re: MXNet 1.6 as last release with Python 2 support?

[Xingjian SHI]

+1. We should move to support Python>=3.5 only.

Get Outlook for iOS

From: Lausen, Leonard 
Sent: Friday, January 17, 2020 10:02:30 AM
To: d...@mxnet.apache.org 
Subject: Re: MXNet 1.6 as last release with Python 2 support?

If the lazy consensus passes, I believe the minimum Python version supported
would be Python 3.5.

Python 3.5 because it seems to be the minimum Python 3 version tested by our CI,
specifically in the jobs running on Ubuntu 16.04.

Best regards
Leonard

On Fri, 2020-01-17 at 17:36 +, Lausen, Leonard wrote:
> Dear MXNet community,
>
> as effective January 1, 2020, no new bug reports, fixes, or changes will be
> made
> to Python 2, and as MXNet 1.6 will be released after January 1, 2020, I
> suggest
> to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last release
> supporting Python 2.
>
> We have previously reached consensus on announcing that Python 2 is dropped in
> the next major release (ie. MXNet 2), however, given the delay in 1.6 release,
> the plan to release 1.7 in the future and that Python 2 is dead already I
> think
> we can revisit this assumption.
>
> Advantages are
> - Time savings for developers, as Python 3 standard library contains more
>   features than Python 2, and it is more efficient to target only 1 language
>   (Python 3) instead of 2 languages (Python 2 & 3)
> - Simplification and cost savings for CI
>
> I thus suggest 72h lazy consensus for announcing dropping of Python 2 as
> described above. If you disagree, please veto (send "-1") and we can continue
> supporting Python 2 in all 1.x releases as per previous consensus. Note that
> at
> the time of previous consensus, no 1.7 release was planned.
>
> Best regards
> Leonard

Re: MXNet 1.6 as last release with Python 2 support?

[Lausen, Leonard]

If the lazy consensus passes, I believe the minimum Python version supported
would be Python 3.5.

Python 3.5 because it seems to be the minimum Python 3 version tested by our CI,
specifically in the jobs running on Ubuntu 16.04.

Best regards
Leonard

On Fri, 2020-01-17 at 17:36 +, Lausen, Leonard wrote:
> Dear MXNet community,
> 
> as effective January 1, 2020, no new bug reports, fixes, or changes will be
> made
> to Python 2, and as MXNet 1.6 will be released after January 1, 2020, I
> suggest
> to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last release
> supporting Python 2.
> 
> We have previously reached consensus on announcing that Python 2 is dropped in
> the next major release (ie. MXNet 2), however, given the delay in 1.6 release,
> the plan to release 1.7 in the future and that Python 2 is dead already I
> think
> we can revisit this assumption.
> 
> Advantages are
> - Time savings for developers, as Python 3 standard library contains more
>   features than Python 2, and it is more efficient to target only 1 language 
>   (Python 3) instead of 2 languages (Python 2 & 3)
> - Simplification and cost savings for CI
> 
> I thus suggest 72h lazy consensus for announcing dropping of Python 2 as
> described above. If you disagree, please veto (send "-1") and we can continue
> supporting Python 2 in all 1.x releases as per previous consensus. Note that
> at
> the time of previous consensus, no 1.7 release was planned.
> 
> Best regards
> Leonard

Re: MXNet 1.6 as last release with Python 2 support?

[Yuan Tang]

+1. It's interesting to see that you framed Python 2 and Python 3 as 2
languages.

On Fri, Jan 17, 2020 at 12:43 PM Chaitanya Bapat 
wrote:

> +1
> Taking the advantages into consideration, it makes sense to call off py2
> support from next release onwards.
>
> On Fri, Jan 17, 2020, 9:37 AM Lausen, Leonard 
> wrote:
>
> > Dear MXNet community,
> >
> > as effective January 1, 2020, no new bug reports, fixes, or changes will
> > be made
> > to Python 2, and as MXNet 1.6 will be released after January 1, 2020, I
> > suggest
> > to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last
> > release
> > supporting Python 2.
> >
> > We have previously reached consensus on announcing that Python 2 is
> > dropped in
> > the next major release (ie. MXNet 2), however, given the delay in 1.6
> > release,
> > the plan to release 1.7 in the future and that Python 2 is dead already I
> > think
> > we can revisit this assumption.
> >
> > Advantages are
> > - Time savings for developers, as Python 3 standard library contains more
> >   features than Python 2, and it is more efficient to target only 1
> > language
> >   (Python 3) instead of 2 languages (Python 2 & 3)
> > - Simplification and cost savings for CI
> >
> > I thus suggest 72h lazy consensus for announcing dropping of Python 2 as
> > described above. If you disagree, please veto (send "-1") and we can
> > continue
> > supporting Python 2 in all 1.x releases as per previous consensus. Note
> > that at
> > the time of previous consensus, no 1.7 release was planned.
> >
> > Best regards
> > Leonard
> >
>

Re: MXNet 1.6 as last release with Python 2 support?

[Chaitanya Bapat]

+1
Taking the advantages into consideration, it makes sense to call off py2
support from next release onwards.

On Fri, Jan 17, 2020, 9:37 AM Lausen, Leonard 
wrote:

> Dear MXNet community,
>
> as effective January 1, 2020, no new bug reports, fixes, or changes will
> be made
> to Python 2, and as MXNet 1.6 will be released after January 1, 2020, I
> suggest
> to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last
> release
> supporting Python 2.
>
> We have previously reached consensus on announcing that Python 2 is
> dropped in
> the next major release (ie. MXNet 2), however, given the delay in 1.6
> release,
> the plan to release 1.7 in the future and that Python 2 is dead already I
> think
> we can revisit this assumption.
>
> Advantages are
> - Time savings for developers, as Python 3 standard library contains more
>   features than Python 2, and it is more efficient to target only 1
> language
>   (Python 3) instead of 2 languages (Python 2 & 3)
> - Simplification and cost savings for CI
>
> I thus suggest 72h lazy consensus for announcing dropping of Python 2 as
> described above. If you disagree, please veto (send "-1") and we can
> continue
> supporting Python 2 in all 1.x releases as per previous consensus. Note
> that at
> the time of previous consensus, no 1.7 release was planned.
>
> Best regards
> Leonard
>

MXNet 1.6 as last release with Python 2 support?

[Lausen, Leonard]

Dear MXNet community,

as effective January 1, 2020, no new bug reports, fixes, or changes will be made
to Python 2, and as MXNet 1.6 will be released after January 1, 2020, I suggest
to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last release
supporting Python 2.

We have previously reached consensus on announcing that Python 2 is dropped in
the next major release (ie. MXNet 2), however, given the delay in 1.6 release,
the plan to release 1.7 in the future and that Python 2 is dead already I think
we can revisit this assumption.

Advantages are
- Time savings for developers, as Python 3 standard library contains more
  features than Python 2, and it is more efficient to target only 1 language 
  (Python 3) instead of 2 languages (Python 2 & 3)
- Simplification and cost savings for CI

I thus suggest 72h lazy consensus for announcing dropping of Python 2 as
described above. If you disagree, please veto (send "-1") and we can continue
supporting Python 2 in all 1.x releases as per previous consensus. Note that at
the time of previous consensus, no 1.7 release was planned.

Best regards
Leonard