Re: [DISCUSS] Remove amalgamation
I went down the path for this and was disuaded by the errors I had and the open issues about the same errors. It's one thing to leave something around that works, but another to leave something around that wastes a lot of time and causes abandonment. The project needs a mobile solution. What's there doesn't cut it, IMO. It needs some love... On Fri, Sep 6, 2019, 17:27 Naveen Swamy wrote: > +1. > I have heard this before elsewhere if you don't understand the code, give > it a name like "hacky", "does not follow the pattern", "unmaintainable", > etc., may all that be true but it does not help making cliched and > disrespectful comments about someone else's contributions. > the code is not going on a ramp walk for a beauty contest. Instead of > subscribing to such software fallacies, it would help the community to make > a decision if concrete examples of limitations, drawbacks, missing features > are given. > > > > On Fri, Sep 6, 2019 at 3:56 PM Chris Olivier > wrote: > > > Hi Pedro, > > > > While I was not involved with amalgamation or its development in any way, > > can you please refrain from referring to the work of others as a "hacky > > solution"? This is derogatory slang and the statement was not supported > > with any justification for such name-calling. Someone spent a good deal > of > > time on this solution at some point in time and I am sure it worked for > its > > purpose at that time -- I think it was used in the original javascript > port > > as well, actually -- and it is disrespectful to call their efforts > > "hacky". Please respect what came before. > > > > Thanks for understanding, > > > > -Chris > > > > > > On Fri, Sep 6, 2019 at 3:07 PM Pedro Larroy < > pedro.larroy.li...@gmail.com> > > wrote: > > > > > Hi > > > > > > I would like to propose to remove amalgamation from MXNet and CI, users > > > have reported that they couldn't use it successfully in Android, and > > > instead they were able to use the cross compiled docker build > > successfully. > > > > > > Any reason why we shouldn't remove this hacky solution? > > > > > > Pedro. > > > > > >
Re: [DISCUSS] Remove amalgamation
+1. I have heard this before elsewhere if you don't understand the code, give it a name like "hacky", "does not follow the pattern", "unmaintainable", etc., may all that be true but it does not help making cliched and disrespectful comments about someone else's contributions. the code is not going on a ramp walk for a beauty contest. Instead of subscribing to such software fallacies, it would help the community to make a decision if concrete examples of limitations, drawbacks, missing features are given. On Fri, Sep 6, 2019 at 3:56 PM Chris Olivier wrote: > Hi Pedro, > > While I was not involved with amalgamation or its development in any way, > can you please refrain from referring to the work of others as a "hacky > solution"? This is derogatory slang and the statement was not supported > with any justification for such name-calling. Someone spent a good deal of > time on this solution at some point in time and I am sure it worked for its > purpose at that time -- I think it was used in the original javascript port > as well, actually -- and it is disrespectful to call their efforts > "hacky". Please respect what came before. > > Thanks for understanding, > > -Chris > > > On Fri, Sep 6, 2019 at 3:07 PM Pedro Larroy > wrote: > > > Hi > > > > I would like to propose to remove amalgamation from MXNet and CI, users > > have reported that they couldn't use it successfully in Android, and > > instead they were able to use the cross compiled docker build > successfully. > > > > Any reason why we shouldn't remove this hacky solution? > > > > Pedro. > > >
Re: [DISCUSS] Remove amalgamation
I can recall that we had quite a few issues where people tried to use amalgamation. Have we identified these use cases so far and documented the alternative. I think the compilation only takes a few seconds and I think we also have some nightly tests for it. So far it seemed very low maintenance, so I'd lean towards keeping it. But if there's literally nobody using it and it's no longer useful, I'm happy to see it removed. Do we have some data on amalgamation usage? -Marco Chris Olivier schrieb am Sa., 7. Sep. 2019, 00:56: > Hi Pedro, > > While I was not involved with amalgamation or its development in any way, > can you please refrain from referring to the work of others as a "hacky > solution"? This is derogatory slang and the statement was not supported > with any justification for such name-calling. Someone spent a good deal of > time on this solution at some point in time and I am sure it worked for its > purpose at that time -- I think it was used in the original javascript port > as well, actually -- and it is disrespectful to call their efforts > "hacky". Please respect what came before. > > Thanks for understanding, > > -Chris > > > On Fri, Sep 6, 2019 at 3:07 PM Pedro Larroy > wrote: > > > Hi > > > > I would like to propose to remove amalgamation from MXNet and CI, users > > have reported that they couldn't use it successfully in Android, and > > instead they were able to use the cross compiled docker build > successfully. > > > > Any reason why we shouldn't remove this hacky solution? > > > > Pedro. > > >
Re: [DISCUSS] Remove amalgamation
Hi Pedro, While I was not involved with amalgamation or its development in any way, can you please refrain from referring to the work of others as a "hacky solution"? This is derogatory slang and the statement was not supported with any justification for such name-calling. Someone spent a good deal of time on this solution at some point in time and I am sure it worked for its purpose at that time -- I think it was used in the original javascript port as well, actually -- and it is disrespectful to call their efforts "hacky". Please respect what came before. Thanks for understanding, -Chris On Fri, Sep 6, 2019 at 3:07 PM Pedro Larroy wrote: > Hi > > I would like to propose to remove amalgamation from MXNet and CI, users > have reported that they couldn't use it successfully in Android, and > instead they were able to use the cross compiled docker build successfully. > > Any reason why we shouldn't remove this hacky solution? > > Pedro. >
Re: [VOTE] Python 2 Removal for MXNet 1.6
No, the vote was cancelled. Pedro Larroy schrieb am Sa., 7. Sep. 2019, 00:05: > Did this vote pass? Can we remove Python2 support from master? > > On Tue, Aug 27, 2019 at 2:51 PM Pedro Larroy > > wrote: > > > +1 > > > > On Tue, Aug 27, 2019 at 3:49 AM Leonard Lausen > wrote: > > > >> Due to References: header the prior email was still sorted in the > >> discussion thread. Cancelling this and resending without that header. > >> > >> Leonard Lausen writes: > >> > >> > Marco de Abreu writes: > >> >> 1. Which Python version to support. 3.5 vs 3.6 is currently in the > >> >> discussion due to Ubuntu 16.04 being shipped with 3.5 while the > biggest > >> >> market share being 3.6 as of now. > >> > > >> > We could drop Python 2 even before deciding when to drop 3.5. > >> > > >> >> 2. When to do the deprecation. EOY to match with official Python 2 > >> >> deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with > >> the > >> >> next major release (2.0) to adhere to semantic versioning. > >> > > >> > From a Semantic Versioning standepoint, "Given a version number > >> > MAJOR.MINOR.PATCH, increment the: MAJOR version when you make > >> > incompatible API changes, MINOR version when you add functionality in > a > >> > backwards compatible manner, [...]" [1]. > >> > > >> > Based on Semantic Versioning, the question is if we consider Python 2 > >> > support to be part of our API, or rather independent. In the latter > >> > case, dropping for 1.6 is fine. > >> > > >> > From a user-experience perspective, users that want to continue using > >> > Python 2 for the next 127 days (until EOL date) currently have bigger > >> > worries than needing to upgrade to the next upcoming MXNet release. > They > >> > must transition their codebase to Py3 within 127 days. For those days, > >> > they may just stay on MXNet 1.5? > >> > > >> > [1]: https://semver.org/ > >> > > >> >> Once these points (and any future ones) have been properly discussed > >> and > >> >> the community came to an agreement, we can formalize it with a voting > >> >> thread. Until then, I'd recommend to refrain from any actions or > >> >> user-facing communication regarding this topic. > >> > > >> > Thus, let's start a vote on dropping Python 2 for MXNet 1.6. > >> > It's fine if this vote fails, but we need to get a clear understanding > >> > how we want to move forward. > >> > > >> > For better visibility, I'm removing the In-Reply-To: header, which was > >> > pointing to > >> cahtwjdorqsrbau0a89xjwasawgbvgz7bojsu6tkmxdl+ruh...@mail.gmail.com > >> > > >> >> On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy < > >> pedro.larroy.li...@gmail.com> > >> >> wrote: > >> >> > >> >>> I have sent a PR that removes Python2 from CI. But was closed. I > >> thought > >> >>> everyone was +1 on this one. This would remove quite a bit of load > on > >> CI: > >> >>> > >> >>> https://github.com/apache/incubator-mxnet/pull/15990 > >> >>> > >> >>> If it's not the right time to do this, what steps do we need to > take? > >> >>> > >> >>> Pedro. > >> > > >
[DISCUSS] Remove amalgamation
Hi I would like to propose to remove amalgamation from MXNet and CI, users have reported that they couldn't use it successfully in Android, and instead they were able to use the cross compiled docker build successfully. Any reason why we shouldn't remove this hacky solution? Pedro.
Re: [VOTE] Python 2 Removal for MXNet 1.6
Did this vote pass? Can we remove Python2 support from master? On Tue, Aug 27, 2019 at 2:51 PM Pedro Larroy wrote: > +1 > > On Tue, Aug 27, 2019 at 3:49 AM Leonard Lausen wrote: > >> Due to References: header the prior email was still sorted in the >> discussion thread. Cancelling this and resending without that header. >> >> Leonard Lausen writes: >> >> > Marco de Abreu writes: >> >> 1. Which Python version to support. 3.5 vs 3.6 is currently in the >> >> discussion due to Ubuntu 16.04 being shipped with 3.5 while the biggest >> >> market share being 3.6 as of now. >> > >> > We could drop Python 2 even before deciding when to drop 3.5. >> > >> >> 2. When to do the deprecation. EOY to match with official Python 2 >> >> deprecation, in 1.5 years to be in line with Ubuntu 16.04 LTS or with >> the >> >> next major release (2.0) to adhere to semantic versioning. >> > >> > From a Semantic Versioning standepoint, "Given a version number >> > MAJOR.MINOR.PATCH, increment the: MAJOR version when you make >> > incompatible API changes, MINOR version when you add functionality in a >> > backwards compatible manner, [...]" [1]. >> > >> > Based on Semantic Versioning, the question is if we consider Python 2 >> > support to be part of our API, or rather independent. In the latter >> > case, dropping for 1.6 is fine. >> > >> > From a user-experience perspective, users that want to continue using >> > Python 2 for the next 127 days (until EOL date) currently have bigger >> > worries than needing to upgrade to the next upcoming MXNet release. They >> > must transition their codebase to Py3 within 127 days. For those days, >> > they may just stay on MXNet 1.5? >> > >> > [1]: https://semver.org/ >> > >> >> Once these points (and any future ones) have been properly discussed >> and >> >> the community came to an agreement, we can formalize it with a voting >> >> thread. Until then, I'd recommend to refrain from any actions or >> >> user-facing communication regarding this topic. >> > >> > Thus, let's start a vote on dropping Python 2 for MXNet 1.6. >> > It's fine if this vote fails, but we need to get a clear understanding >> > how we want to move forward. >> > >> > For better visibility, I'm removing the In-Reply-To: header, which was >> > pointing to >> cahtwjdorqsrbau0a89xjwasawgbvgz7bojsu6tkmxdl+ruh...@mail.gmail.com >> > >> >> On Tue, Aug 27, 2019 at 1:29 AM Pedro Larroy < >> pedro.larroy.li...@gmail.com> >> >> wrote: >> >> >> >>> I have sent a PR that removes Python2 from CI. But was closed. I >> thought >> >>> everyone was +1 on this one. This would remove quite a bit of load on >> CI: >> >>> >> >>> https://github.com/apache/incubator-mxnet/pull/15990 >> >>> >> >>> If it's not the right time to do this, what steps do we need to take? >> >>> >> >>> Pedro. >> >
Re: new website
The new website looks great Aaron. Nice work to everyone involved !
On Thu, Aug 29, 2019 at 5:26 PM Aaron Markham
wrote:
> Hi everyone,
>
> I'm very excited to share a preview and the pull requests for a new
> website and new documentation pipelines.
>
> The following link is using Apache's new staging site setup. It is
> built from the new docs publishing pipelines in CI where a Jekyll
> website is built, and documentation artifacts from Clojure, CPP, Java,
> Julia, Python, R, and Scala are combined into one website.
>
> https://mxnet-beta.staged.apache.org
>
> It is the culmination of a lot of effort of several MXNet contributors.
>
> * A huge shout out goes to Thomas Delteil for the work on the new
> Jekyll-backend and beautiful-looking website, and for helping me out
> whenever I'd get stuck on revamping the 7 different API docs systems
> in CI.
> * Soji Adeshina and Vishaal Kapoor both helping me with the system
> design for the new docs pipelines.
> * Per Goncalves da Silva and Marco de Abreu both helped me with
> figuring out CI issues.
> * We also ported over Mu Li's beta site for the Python & R APIs which
> had many contributors there. Thanks goes to Mu, Ivy Bazan, Jonas
> Mueller, Aston Zhang, and Zhi Zhang for their help & contributions. I
> apologize in advance if I missed anyone.
>
> Highlights:
>
> * R docs are now generated as part of CI. There were issues with R
> docs coming from beta repo. They were not reproducible. So I began the
> process of creating the pdf doc that is expected by R users as an
> alternative. Thomas fixed a CPP bug that was blocking 90% of the docs
> from appearing. The R docs are 10x in length compared to the pdf we're
> hosting now!
>
> * Each other API is built in a micro-site fashion. You will notice
> that the reference API links will open up the site that is generated
> by that language's docs tools. We tried to keep the navigation common
> and do this for the Python API. This is something that can be expanded
> on for the other APIs in later updates to the website.
>
> * Each doc set can be generated separately with functions that will
> run in Docker and generate the docs artifacts. This means you can now
> focus on your preferred API and not have to deal with anything else.
>
> * Website changes are now much easier. You can serve Jekyll locally,
> and have it do incremental updates, so you can see your changes live
> without having to build MXNet or anything else. It's a pure front-end
> setup.
>
> * For website publishing, the MXNet binary is built once and then
> shared with the other docs generation pipelines.
>
> * For individual docs runs, you can run a "lite" binary build, then
> follow it up with the docs run you want.
>
> ---
>
> For example to build MXNet:
>
> ci/build.py --docker-registry mxnetcidev --platform ubuntu_cpu_lite
> /work/runtime_functions.sh build_ubuntu_cpu_docs
>
> Then to build the R docs:
>
> ci/build.py --docker-registry mxnetcidev --platform ubuntu_cpu_r
> /work/runtime_functions.sh build_r_docs
>
> There is now a Docker image and a runtime_function for each API
> (except Perl which is built offsite). Python is like this:
>
> ci/build.py --docker-registry mxnetcidev --platform ubuntu_cpu_python
> /work/runtime_functions.sh build_python_docs
>
> The pattern for platform is ubuntu_cpu_{api} and runtime_functions.sh
> is build_{api}_docs.
>
> Further information is on the developer wiki:
> https://cwiki.apache.org/confluence/display/MXNET/Building+the+New+Website
>
>
> Ok, now this is where YOU come in. We need reviewers and testers.
>
> There are a lot of changes. My original PR was over 1,000 files with
> 83k additions and 55k deletions. So, Thomas broke this up into three
> pull requests that stack.
>
> Step 1 New Content https://github.com/apache/incubator-mxnet/pull/15884
> Step 2 Remove Old Content
> https://github.com/apache/incubator-mxnet/pull/15885
> Step 3 Setup New Jenkins
> https://github.com/apache/incubator-mxnet/pull/15886
>
> For reviewing purposes, start with the new content - what's easily
> visible on the preview website. This is mostly happening in the first
> PR:
> https://github.com/apache/incubator-mxnet/pull/15884
> You can also look at these helper PRs that show you the differences so
> it is easier to review what's happening in Steps 2 and 3. You can
> review these now as well.
> Step 1->2: https://github.com/ThomasDelteil/incubator-mxnet/pull/5
> Step 2->3: https://github.com/ThomasDelteil/incubator-mxnet/pull/6
>
> I really appreciate everyone's support on this effort.
>
> Cheers,
> Aaron
>
Re: Code freeze for 1.5.1 patch release
Update: Artifacts of 1.5.1.rc0 have been uploaded to github and Apache dist. Before voting, we still need some time to build packages for Scala, Clojure and R. Thank you for your patience. -tao On Thu, Sep 5, 2019 at 10:15 PM Tao Lv wrote: > > Following the release process [1], I just created the tag for 1.5.1.rc0 > [2]. Artifacts uploading and validation are still WIP. Will keep you > posted. Hopefully we can start the veto soon for a new release. :) > > Let me know if you any question or suggestion for the release. > > Thanks, > -tao > > [1] https://cwiki.apache.org/confluence/display/MXNET/Release+Process > [2] https://github.com/apache/incubator-mxnet/releases/tag/1.5.1.rc0 > > > On Wed, Sep 4, 2019 at 9:23 AM Tao Lv wrote: > >> >> Code freezing! >> >> If you happen to be around github, please help to review the PR [1] for >> bumping version strings on the release branch. Thanks. >> >> I will continue working on the rest steps for the release. >> >> Thanks, >> -tao >> >> [1] https://github.com/apache/incubator-mxnet/pull/16072 >> >> On Mon, Sep 2, 2019 at 9:51 PM Tao Lv wrote: >> >>> >>> I drafted the release notes for 1.5.1 patch release: >>> https://cwiki.apache.org/confluence/display/MXNET/1.5.1+Release+Notes >>> >>> Any comments or suggestions are highly appreciated! >>> >>> -tao >>> >>> On Mon, Sep 2, 2019 at 2:00 PM kellen sunderland < >>> kellen.sunderl...@gmail.com> wrote: >>> Thanks for organizing the release Tao. On Sun, Sep 1, 2019, 5:53 PM Tao Lv wrote: > Hi Community, > > Code freeze for 1.5.1 patch release will be 9/3 6pm PST (9/4 9am CST). If > you have any additional fix in progress and would like to include it in > this release, please assure they have been merged before code freeze. > > Thanks for all your support and contribution. > > -tao > >>>
