Re: [Announcement] New Committer - Anirudh Acharya

[Sheng Zha]

Congrats! Now Anirudh is officially the most popular name among the MXNet 
committers :P

-sz

On 2019/09/27 22:57:22, Furkan KAMACI  wrote: 
> Hi,
> 
> Congrats Anirudh!
> 
> Kind Regards,
> Furkan KAMCI
> 
> 28 Eyl 2019 Cmt, saat 01:34 tarihinde Marco de Abreu <
> marco.g.ab...@gmail.com> şunu yazdı:
> 
> > Welcome!
> >
> >
> > On Sat, Sep 28, 2019 at 12:06 AM Chaitanya Bapat 
> > wrote:
> >
> > > Congratulations Anirudh! Well deserved!
> > >
> > > On Thu, 26 Sep 2019 at 10:10, Chris Olivier 
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Please join me in welcoming Anirudh Acharya as a new committer of
> > Apache
> > > > MXNet (incubating)!
> > > >
> > > > Anirudh Acharya has been contributing to the MXNet project for a year
> > and
> > > > half now and has made several improvements to the MXNet R project and
> > > > continues to contribute by adding optimizers, fixing tests and actively
> > > > providing feedback on the PRs and has good understanding of building
> > > > operators in MXNet and architecture in general.
> > > >
> > > > Welcome, Anirudh!
> > > >
> > >
> > >
> > > --
> > > *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: Podling Report Reminder - October 2019

[Sheng Zha]

I'm working on a draft now. Once ready, I will post the draft to the wiki page 
and reply back here.

-sz

On 2019/09/29 00:44:27, jmcl...@apache.org wrote: 
> Dear podling,
> 
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
> 
> The board meeting is scheduled for Wed, 16 October 2019, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, October 02).
> 
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
> 
> Candidate names should not be made public before people are actually
> elected, so please do not include the names of potential committers or
> PPMC members in your report.
> 
> Thanks,
> 
> The Apache Incubator PMC
> 
> Submitting your Report
> 
> --
> 
> Your report should contain the following:
> 
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
> 
> This should be appended to the Incubator Wiki page at:
> 
> https://cwiki.apache.org/confluence/display/INCUBATOR/October2019
> 
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
> 
> Note: The format of the report has changed to use markdown.
> 
> Mentors
> ---
> 
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
> 
> Incubator PMC
> 

Re: Update for 1.5.1 patch release

[Sheng Zha]

Here's what I did for the past few releases:
1. For 3.1.1
- check out the rc version tag locally in git and tag it with the release 
version. (i.e. duplicate 1.5.1.rc0 and name it 1.5.1)
- edit the last release candidate pre-release on github. update the title and 
tag to reflect the new release, and uncheck this is a pre-release checkbox.
- update the release artifact in the release with the artifacts from 3.1.2.
- delete the old rc tag locally and on github.

2. For 3.1.2
- Since folder name needs to be changed inside the archive, the signature and 
hash need to be produced again. I usually just untar the old file, rename the 
folder name to remove mentions of "rc", and follow step 1.10 to tar, sign, and 
digest.
- SVN repo also needs to be updated with the correct folder name and path, and 
the updated artifacts. The end result should be that the old rc artifacts are 
removed from the dev repo, and the release artifacts are uploaded to the dist 
repo.

3. Aaron has been helping with 3.2.

-sz

On 2019/09/28 20:47:37, Lin Yuan  wrote: 
> Ping @Sheng and @Lai who released 1.5.0 for help.
> 
> Could you please update the Release Process doc after you find the right
> answers to these questions?
> 
> Thanks,
> 
> Lin
> 
> On Sat, Sep 28, 2019 at 7:49 AM Tao Lv  wrote:
> 
> > Hi dev,
> >
> > I'm glad to say that the rc0 of 1.5.1 patch release has passed the vote on
> > general@. Please find the voting thread at:
> >
> > https://lists.apache.org/thread.html/282f7911768dab61ddf8f70adcce34ef0afb285046093b3ff0bafb7e@%3Cgeneral.incubator.apache.org%3E
> >
> >
> > Now I'm proceeding the release process and have several questions there.
> > Hope someone can help to answer:
> >
> > 1. Change the 1.5.1.rc0 tag to formal 1.5.1. Seems the step 3.1.1 on the
> > cwiki page [1] doesn't work. It says:
> >
> > "Go to the GitHub repo’s “releases” tab
> >
> > Click “Draft a new release”
> >
> > Provide the release tag in the form of “..”
> > Select the commit by clicking Target: master > the passing release
> > candidate tag"
> >
> > But I cannot find "the passing release candidate tag" in the drop list.
> > There're branches and recent commits. Once I create a new tag, how about
> > the old tag of 1.5.1.rc0?
> >
> > 2. Step 3.1.2 is also confusing to me. Not sure what should be done at step
> > 3 and what need to be uploaded at step 4.
> >
> > 3. As we have a new website now, I guess there are some changes for the
> > step 3.2. Can anyone help to clarify this?
> >
> > Thanks,
> > -tao
> >
> > [1] https://cwiki.apache.org/confluence/display/MXNET/Release+Process
> >
> 

Podling Report Reminder - October 2019

[jmclean]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 16 October 2019, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, October 02).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Candidate names should not be made public before people are actually
elected, so please do not include the names of potential committers or
PPMC members in your report.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://cwiki.apache.org/confluence/display/INCUBATOR/October2019

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Note: The format of the report has changed to use markdown.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: Update for 1.5.1 patch release

[Lin Yuan]

Ping @Sheng and @Lai who released 1.5.0 for help.

Could you please update the Release Process doc after you find the right
answers to these questions?

Thanks,

Lin

On Sat, Sep 28, 2019 at 7:49 AM Tao Lv  wrote:

> Hi dev,
>
> I'm glad to say that the rc0 of 1.5.1 patch release has passed the vote on
> general@. Please find the voting thread at:
>
> https://lists.apache.org/thread.html/282f7911768dab61ddf8f70adcce34ef0afb285046093b3ff0bafb7e@%3Cgeneral.incubator.apache.org%3E
>
>
> Now I'm proceeding the release process and have several questions there.
> Hope someone can help to answer:
>
> 1. Change the 1.5.1.rc0 tag to formal 1.5.1. Seems the step 3.1.1 on the
> cwiki page [1] doesn't work. It says:
>
> "Go to the GitHub repo’s “releases” tab
>
> Click “Draft a new release”
>
> Provide the release tag in the form of “..”
> Select the commit by clicking Target: master > the passing release
> candidate tag"
>
> But I cannot find "the passing release candidate tag" in the drop list.
> There're branches and recent commits. Once I create a new tag, how about
> the old tag of 1.5.1.rc0?
>
> 2. Step 3.1.2 is also confusing to me. Not sure what should be done at step
> 3 and what need to be uploaded at step 4.
>
> 3. As we have a new website now, I guess there are some changes for the
> step 3.2. Can anyone help to clarify this?
>
> Thanks,
> -tao
>
> [1] https://cwiki.apache.org/confluence/display/MXNET/Release+Process
>

Re: [DISCUSS] Remove amalgamation

[Tianqi Chen]

The main trade off is that you can do it as long as the all the dependency
is contained easy to build. If you start to involve things like cuda code
you want to switch to formal build system. That is why I explained most
usecases is for a small runtime component

On Sat, Sep 28, 2019 at 10:48 AM Chris Olivier 
wrote:

> This seems similar to sqlite which offers (maybe now by default?) a single
> c file that is the whole DB engine and makes it quite attractive as a local
> db option.
>
> I have no strong opinion on whether or not to keep amalgamation, but I
> wasn’t actually aware of this use-case for mxnet and I recall how much I
> liked sqlite for this.
>
> On Sat, Sep 28, 2019 at 10:17 AM Tianqi Chen 
> wrote:
>
> > To give a complete picture. I will talk a bit about my experience on
> using
> > the all-in-one file approach and a few examples in the tvm project.
> >
> > Currently, tvm uses all-in-one build for its lightweight runtime in cases
> > where we want a separate build system and do not want to bother to use
> > CMake, this include
> >
> > - Standalone deployment:
> > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> > - Android projects where we need to use NDK for cross compilation.
> > - iOS where we need to use XCode.
> >
> > In all these cases, all-in-one build provide the benefit of easy to
> > incorporate into the target project. However, we only use all-in-one
> build
> > for the "minimum runtime" that is necessary to run a model. But will not
> > include components that compiles and optimizes the model as things will
> get
> > out of hand pretty quickly and in those cases, having a build system
> > out-weights the gains of the single file.
> >
> > So if there is a minimum runtime that MXNet wants to incorporate into the
> > users' env and the developers do not want to code up a CMake recipe for
> > that, it is a possible route. And in that case, I would still suggest to
> > move away from the current approach that create a single file but follow
> > the approach in the above link. In both cases, the current amalgamation
> is
> > not fulfilling its function so I think it is fine to remove and add new
> > ones with thoughts if necessary
> >
> > TQ
> >
> > On Sat, Sep 28, 2019 at 9:49 AM Tianqi Chen 
> > wrote:
> >
> > > The main use of amalgamation(aka all in one file build) for cases where
> > it
> > > is hard to setup a Make system. Most user knows how to include a single
> > > file into their project, but it is relatively harder to incorporate an
> > > entire build system.
> > >
> > > As a result, all-in-one file runtime is still being quite widely used
> and
> > > I personally liked the approach, I just suggested that the current
> > approach
> > > may not be the best way to go and creates some maintenance burden.
> > >
> > > See the link of an example project that uses new all-in-one approach
> that
> > > i mentioned(which illustrates the usecase of all-in-one file as well)
> > > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> > >
> > > TQ
> > >
> > > On Sat, Sep 28, 2019 at 3:46 AM Marco de Abreu <
> marco.g.ab...@gmail.com>
> > > wrote:
> > >
> > >> Do we have a good knowledge and overview over all the use cases that
> use
> > >> Amalgamation? At least from my perspective I don't feel well informed
> > >> about
> > >> the blast radius.
> > >>
> > >> -Marco
> > >>
> > >> Junru Shao  schrieb am Sa., 28. Sep. 2019,
> > >> 09:14:
> > >>
> > >> > As Tianqi and Sheng mentioned, given the fact that we are able to do
> > >> > deployment in a possibly better way (correct me if I was wrong), I
> > would
> > >> > love to +1 to Pedro’s proposal.
> > >> >
> > >> > In the meantime, as a healthy open source community, I also agree
> with
> > >> > Naveen’s point that we should do more homework for both our
> developers
> > >> and
> > >> > customers. IMHO, for example, it would be super helpful if Pedro may
> > >> bring
> > >> > up some documentation describing what is the “best practice” of
> using
> > >> the
> > >> > alternative of amalgamation, if our community agree to deprecate it.
> > >> >
> > >> > Thank you guys so much for the discussion!
> > >> >
> > >> > Junru
> > >> >
> > >> > On Fri, Sep 27, 2019 at 17:00 Tianqi Chen  >
> > >> > wrote:
> > >> >
> > >> > > The original amalgamation tries to generate a single file for
> > >> compilation
> > >> > > via a script.  This is largely un-necessary, having a file that
> > >> include
> > >> > the
> > >> > > dependent files and compile that one is relatively easy and
> > sometimes
> > >> > more
> > >> > > robust(without expanding everything into a single file).
> > >> > >
> > >> > > I think it might makes sense to deprecate and remove the current
> one
> > >> > given
> > >> > > that it is no longer properly functioning. If someone is
> interested,
> > >> > create
> > >> > > another deployment example that is more standalone without the
> file
> > >> > > expansion. Here is an reference of the "new style" used in the tvm
> > >> >

Re: [DISCUSS] Remove amalgamation

[Chris Olivier]

This seems similar to sqlite which offers (maybe now by default?) a single
c file that is the whole DB engine and makes it quite attractive as a local
db option.

I have no strong opinion on whether or not to keep amalgamation, but I
wasn’t actually aware of this use-case for mxnet and I recall how much I
liked sqlite for this.

On Sat, Sep 28, 2019 at 10:17 AM Tianqi Chen 
wrote:

> To give a complete picture. I will talk a bit about my experience on using
> the all-in-one file approach and a few examples in the tvm project.
>
> Currently, tvm uses all-in-one build for its lightweight runtime in cases
> where we want a separate build system and do not want to bother to use
> CMake, this include
>
> - Standalone deployment:
> https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> - Android projects where we need to use NDK for cross compilation.
> - iOS where we need to use XCode.
>
> In all these cases, all-in-one build provide the benefit of easy to
> incorporate into the target project. However, we only use all-in-one build
> for the "minimum runtime" that is necessary to run a model. But will not
> include components that compiles and optimizes the model as things will get
> out of hand pretty quickly and in those cases, having a build system
> out-weights the gains of the single file.
>
> So if there is a minimum runtime that MXNet wants to incorporate into the
> users' env and the developers do not want to code up a CMake recipe for
> that, it is a possible route. And in that case, I would still suggest to
> move away from the current approach that create a single file but follow
> the approach in the above link. In both cases, the current amalgamation is
> not fulfilling its function so I think it is fine to remove and add new
> ones with thoughts if necessary
>
> TQ
>
> On Sat, Sep 28, 2019 at 9:49 AM Tianqi Chen 
> wrote:
>
> > The main use of amalgamation(aka all in one file build) for cases where
> it
> > is hard to setup a Make system. Most user knows how to include a single
> > file into their project, but it is relatively harder to incorporate an
> > entire build system.
> >
> > As a result, all-in-one file runtime is still being quite widely used and
> > I personally liked the approach, I just suggested that the current
> approach
> > may not be the best way to go and creates some maintenance burden.
> >
> > See the link of an example project that uses new all-in-one approach that
> > i mentioned(which illustrates the usecase of all-in-one file as well)
> > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> >
> > TQ
> >
> > On Sat, Sep 28, 2019 at 3:46 AM Marco de Abreu 
> > wrote:
> >
> >> Do we have a good knowledge and overview over all the use cases that use
> >> Amalgamation? At least from my perspective I don't feel well informed
> >> about
> >> the blast radius.
> >>
> >> -Marco
> >>
> >> Junru Shao  schrieb am Sa., 28. Sep. 2019,
> >> 09:14:
> >>
> >> > As Tianqi and Sheng mentioned, given the fact that we are able to do
> >> > deployment in a possibly better way (correct me if I was wrong), I
> would
> >> > love to +1 to Pedro’s proposal.
> >> >
> >> > In the meantime, as a healthy open source community, I also agree with
> >> > Naveen’s point that we should do more homework for both our developers
> >> and
> >> > customers. IMHO, for example, it would be super helpful if Pedro may
> >> bring
> >> > up some documentation describing what is the “best practice” of using
> >> the
> >> > alternative of amalgamation, if our community agree to deprecate it.
> >> >
> >> > Thank you guys so much for the discussion!
> >> >
> >> > Junru
> >> >
> >> > On Fri, Sep 27, 2019 at 17:00 Tianqi Chen 
> >> > wrote:
> >> >
> >> > > The original amalgamation tries to generate a single file for
> >> compilation
> >> > > via a script.  This is largely un-necessary, having a file that
> >> include
> >> > the
> >> > > dependent files and compile that one is relatively easy and
> sometimes
> >> > more
> >> > > robust(without expanding everything into a single file).
> >> > >
> >> > > I think it might makes sense to deprecate and remove the current one
> >> > given
> >> > > that it is no longer properly functioning. If someone is interested,
> >> > create
> >> > > another deployment example that is more standalone without the file
> >> > > expansion. Here is an reference of the "new style" used in the tvm
> >> > project
> >> > > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> >> > >
> >> > > TQ
> >> > >
> >> > > On Fri, Sep 27, 2019 at 4:49 PM Sheng Zha 
> >> wrote:
> >> > >
> >> > > > As an alternative to amalgamation, could we simply ask users to
> >> > > statically
> >> > > > link to libmxnet.a, and then prune the symbol table to get rid of
> >> the
> >> > > > binary of unused functions? Though I don't know the full context
> of
> >> > > > amalgamation, based on my knowledge on this feature I'm not aware
> of
> >> > any
> >> > > > difference in the end result, compared to the code

Re: [DISCUSS] Remove amalgamation

[Tianqi Chen]

To give a complete picture. I will talk a bit about my experience on using
the all-in-one file approach and a few examples in the tvm project.

Currently, tvm uses all-in-one build for its lightweight runtime in cases
where we want a separate build system and do not want to bother to use
CMake, this include

- Standalone deployment:
https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
- Android projects where we need to use NDK for cross compilation.
- iOS where we need to use XCode.

In all these cases, all-in-one build provide the benefit of easy to
incorporate into the target project. However, we only use all-in-one build
for the "minimum runtime" that is necessary to run a model. But will not
include components that compiles and optimizes the model as things will get
out of hand pretty quickly and in those cases, having a build system
out-weights the gains of the single file.

So if there is a minimum runtime that MXNet wants to incorporate into the
users' env and the developers do not want to code up a CMake recipe for
that, it is a possible route. And in that case, I would still suggest to
move away from the current approach that create a single file but follow
the approach in the above link. In both cases, the current amalgamation is
not fulfilling its function so I think it is fine to remove and add new
ones with thoughts if necessary

TQ

On Sat, Sep 28, 2019 at 9:49 AM Tianqi Chen 
wrote:

> The main use of amalgamation(aka all in one file build) for cases where it
> is hard to setup a Make system. Most user knows how to include a single
> file into their project, but it is relatively harder to incorporate an
> entire build system.
>
> As a result, all-in-one file runtime is still being quite widely used and
> I personally liked the approach, I just suggested that the current approach
> may not be the best way to go and creates some maintenance burden.
>
> See the link of an example project that uses new all-in-one approach that
> i mentioned(which illustrates the usecase of all-in-one file as well)
> https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
>
> TQ
>
> On Sat, Sep 28, 2019 at 3:46 AM Marco de Abreu 
> wrote:
>
>> Do we have a good knowledge and overview over all the use cases that use
>> Amalgamation? At least from my perspective I don't feel well informed
>> about
>> the blast radius.
>>
>> -Marco
>>
>> Junru Shao  schrieb am Sa., 28. Sep. 2019,
>> 09:14:
>>
>> > As Tianqi and Sheng mentioned, given the fact that we are able to do
>> > deployment in a possibly better way (correct me if I was wrong), I would
>> > love to +1 to Pedro’s proposal.
>> >
>> > In the meantime, as a healthy open source community, I also agree with
>> > Naveen’s point that we should do more homework for both our developers
>> and
>> > customers. IMHO, for example, it would be super helpful if Pedro may
>> bring
>> > up some documentation describing what is the “best practice” of using
>> the
>> > alternative of amalgamation, if our community agree to deprecate it.
>> >
>> > Thank you guys so much for the discussion!
>> >
>> > Junru
>> >
>> > On Fri, Sep 27, 2019 at 17:00 Tianqi Chen 
>> > wrote:
>> >
>> > > The original amalgamation tries to generate a single file for
>> compilation
>> > > via a script.  This is largely un-necessary, having a file that
>> include
>> > the
>> > > dependent files and compile that one is relatively easy and sometimes
>> > more
>> > > robust(without expanding everything into a single file).
>> > >
>> > > I think it might makes sense to deprecate and remove the current one
>> > given
>> > > that it is no longer properly functioning. If someone is interested,
>> > create
>> > > another deployment example that is more standalone without the file
>> > > expansion. Here is an reference of the "new style" used in the tvm
>> > project
>> > > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
>> > >
>> > > TQ
>> > >
>> > > On Fri, Sep 27, 2019 at 4:49 PM Sheng Zha 
>> wrote:
>> > >
>> > > > As an alternative to amalgamation, could we simply ask users to
>> > > statically
>> > > > link to libmxnet.a, and then prune the symbol table to get rid of
>> the
>> > > > binary of unused functions? Though I don't know the full context of
>> > > > amalgamation, based on my knowledge on this feature I'm not aware of
>> > any
>> > > > difference in the end result, compared to the code-inlining approach
>> > that
>> > > > amalgamation takes.
>> > > >
>> > > > -sz
>> > > >
>> > > > On 2019/09/12 17:29:02, Naveen Swamy  wrote:
>> > > > > so the original email suggesting to remove was after all
>> self-serving
>> > > :)
>> > > > >
>> > > > > let's encourage if someone wants to maintain and make use of the
>> > > original
>> > > > > work and make it better.
>> > > > >
>> > > > > -1 to remove at this point
>> > > > >
>> > > > > P.S: I suggest to do some due diligence before bringing topics up
>> for
>> > > > > discussion.
>> > > > >
>> > > > > On Wed, Sep 11, 2019 at 8:10 AM Lv, Tao A 
>> >

Re: [DISCUSS] Remove amalgamation

[Tianqi Chen]

The main use of amalgamation(aka all in one file build) for cases where it
is hard to setup a Make system. Most user knows how to include a single
file into their project, but it is relatively harder to incorporate an
entire build system.

As a result, all-in-one file runtime is still being quite widely used and I
personally liked the approach, I just suggested that the current approach
may not be the best way to go and creates some maintenance burden.

See the link of an example project that uses new all-in-one approach that i
mentioned(which illustrates the usecase of all-in-one file as well)
https://github.com/dmlc/tvm/tree/master/apps/howto_deploy

TQ

On Sat, Sep 28, 2019 at 3:46 AM Marco de Abreu 
wrote:

> Do we have a good knowledge and overview over all the use cases that use
> Amalgamation? At least from my perspective I don't feel well informed about
> the blast radius.
>
> -Marco
>
> Junru Shao  schrieb am Sa., 28. Sep. 2019, 09:14:
>
> > As Tianqi and Sheng mentioned, given the fact that we are able to do
> > deployment in a possibly better way (correct me if I was wrong), I would
> > love to +1 to Pedro’s proposal.
> >
> > In the meantime, as a healthy open source community, I also agree with
> > Naveen’s point that we should do more homework for both our developers
> and
> > customers. IMHO, for example, it would be super helpful if Pedro may
> bring
> > up some documentation describing what is the “best practice” of using the
> > alternative of amalgamation, if our community agree to deprecate it.
> >
> > Thank you guys so much for the discussion!
> >
> > Junru
> >
> > On Fri, Sep 27, 2019 at 17:00 Tianqi Chen 
> > wrote:
> >
> > > The original amalgamation tries to generate a single file for
> compilation
> > > via a script.  This is largely un-necessary, having a file that include
> > the
> > > dependent files and compile that one is relatively easy and sometimes
> > more
> > > robust(without expanding everything into a single file).
> > >
> > > I think it might makes sense to deprecate and remove the current one
> > given
> > > that it is no longer properly functioning. If someone is interested,
> > create
> > > another deployment example that is more standalone without the file
> > > expansion. Here is an reference of the "new style" used in the tvm
> > project
> > > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> > >
> > > TQ
> > >
> > > On Fri, Sep 27, 2019 at 4:49 PM Sheng Zha  wrote:
> > >
> > > > As an alternative to amalgamation, could we simply ask users to
> > > statically
> > > > link to libmxnet.a, and then prune the symbol table to get rid of the
> > > > binary of unused functions? Though I don't know the full context of
> > > > amalgamation, based on my knowledge on this feature I'm not aware of
> > any
> > > > difference in the end result, compared to the code-inlining approach
> > that
> > > > amalgamation takes.
> > > >
> > > > -sz
> > > >
> > > > On 2019/09/12 17:29:02, Naveen Swamy  wrote:
> > > > > so the original email suggesting to remove was after all
> self-serving
> > > :)
> > > > >
> > > > > let's encourage if someone wants to maintain and make use of the
> > > original
> > > > > work and make it better.
> > > > >
> > > > > -1 to remove at this point
> > > > >
> > > > > P.S: I suggest to do some due diligence before bringing topics up
> for
> > > > > discussion.
> > > > >
> > > > > On Wed, Sep 11, 2019 at 8:10 AM Lv, Tao A 
> > wrote:
> > > > >
> > > > > > Sorry to chime in.
> > > > > >
> > > > > > There is a PR to fix amalgamation. I was pinged several times to
> > > merge
> > > > it
> > > > > > but I don't think I have enough knowledge to do that. So it would
> > be
> > > > great
> > > > > > if someone from this thread can help to review.
> > > > > >
> > > > > > https://github.com/apache/incubator-mxnet/pull/15303
> > > > > >
> > > > > > thanks,
> > > > > > -tao
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Marco de Abreu 
> > > > > > Sent: Wednesday, September 11, 2019 9:38 PM
> > > > > > To: dev@mxnet.incubator.apache.org
> > > > > > Subject: Re: [DISCUSS] Remove amalgamation
> > > > > >
> > > > > > Is Amalgamation only used on Android though? Are there any other
> > use
> > > > cases?
> > > > > >
> > > > > > -Marco
> > > > > >
> > > > > > Pedro Larroy  schrieb am Mi., 11.
> > Sep.
> > > > 2019,
> > > > > > 11:57:
> > > > > >
> > > > > > > Hi Anirudh
> > > > > > >
> > > > > > > Appreciate your feedback and sorry if my email came across that
> > way
> > > > to
> > > > > > > you, I think you might miss some context. I don't think calling
> > > > > > > something hacky is anything bad and isn't supposed to be the
> > topic
> > > of
> > > > > > > the discussion. It was reported as not working by users, hence
> > the
> > > > > > > original thread. It was a request for opinions from people who
> > > might
> > > > > > > actually have tried to work in Mxnet on Android.
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > P

Update for 1.5.1 patch release

[Tao Lv]

Hi dev,

I'm glad to say that the rc0 of 1.5.1 patch release has passed the vote on
general@. Please find the voting thread at:
https://lists.apache.org/thread.html/282f7911768dab61ddf8f70adcce34ef0afb285046093b3ff0bafb7e@%3Cgeneral.incubator.apache.org%3E


Now I'm proceeding the release process and have several questions there.
Hope someone can help to answer:

1. Change the 1.5.1.rc0 tag to formal 1.5.1. Seems the step 3.1.1 on the
cwiki page [1] doesn't work. It says:

"Go to the GitHub repo’s “releases” tab

Click “Draft a new release”

Provide the release tag in the form of “..”
Select the commit by clicking Target: master > the passing release
candidate tag"

But I cannot find "the passing release candidate tag" in the drop list.
There're branches and recent commits. Once I create a new tag, how about
the old tag of 1.5.1.rc0?

2. Step 3.1.2 is also confusing to me. Not sure what should be done at step
3 and what need to be uploaded at step 4.

3. As we have a new website now, I guess there are some changes for the
step 3.2. Can anyone help to clarify this?

Thanks,
-tao

[1] https://cwiki.apache.org/confluence/display/MXNET/Release+Process

Re: [DISCUSS] Remove amalgamation

[Marco de Abreu]

Do we have a good knowledge and overview over all the use cases that use
Amalgamation? At least from my perspective I don't feel well informed about
the blast radius.

-Marco

Junru Shao  schrieb am Sa., 28. Sep. 2019, 09:14:

> As Tianqi and Sheng mentioned, given the fact that we are able to do
> deployment in a possibly better way (correct me if I was wrong), I would
> love to +1 to Pedro’s proposal.
>
> In the meantime, as a healthy open source community, I also agree with
> Naveen’s point that we should do more homework for both our developers and
> customers. IMHO, for example, it would be super helpful if Pedro may bring
> up some documentation describing what is the “best practice” of using the
> alternative of amalgamation, if our community agree to deprecate it.
>
> Thank you guys so much for the discussion!
>
> Junru
>
> On Fri, Sep 27, 2019 at 17:00 Tianqi Chen 
> wrote:
>
> > The original amalgamation tries to generate a single file for compilation
> > via a script.  This is largely un-necessary, having a file that include
> the
> > dependent files and compile that one is relatively easy and sometimes
> more
> > robust(without expanding everything into a single file).
> >
> > I think it might makes sense to deprecate and remove the current one
> given
> > that it is no longer properly functioning. If someone is interested,
> create
> > another deployment example that is more standalone without the file
> > expansion. Here is an reference of the "new style" used in the tvm
> project
> > https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
> >
> > TQ
> >
> > On Fri, Sep 27, 2019 at 4:49 PM Sheng Zha  wrote:
> >
> > > As an alternative to amalgamation, could we simply ask users to
> > statically
> > > link to libmxnet.a, and then prune the symbol table to get rid of the
> > > binary of unused functions? Though I don't know the full context of
> > > amalgamation, based on my knowledge on this feature I'm not aware of
> any
> > > difference in the end result, compared to the code-inlining approach
> that
> > > amalgamation takes.
> > >
> > > -sz
> > >
> > > On 2019/09/12 17:29:02, Naveen Swamy  wrote:
> > > > so the original email suggesting to remove was after all self-serving
> > :)
> > > >
> > > > let's encourage if someone wants to maintain and make use of the
> > original
> > > > work and make it better.
> > > >
> > > > -1 to remove at this point
> > > >
> > > > P.S: I suggest to do some due diligence before bringing topics up for
> > > > discussion.
> > > >
> > > > On Wed, Sep 11, 2019 at 8:10 AM Lv, Tao A 
> wrote:
> > > >
> > > > > Sorry to chime in.
> > > > >
> > > > > There is a PR to fix amalgamation. I was pinged several times to
> > merge
> > > it
> > > > > but I don't think I have enough knowledge to do that. So it would
> be
> > > great
> > > > > if someone from this thread can help to review.
> > > > >
> > > > > https://github.com/apache/incubator-mxnet/pull/15303
> > > > >
> > > > > thanks,
> > > > > -tao
> > > > >
> > > > > -Original Message-
> > > > > From: Marco de Abreu 
> > > > > Sent: Wednesday, September 11, 2019 9:38 PM
> > > > > To: dev@mxnet.incubator.apache.org
> > > > > Subject: Re: [DISCUSS] Remove amalgamation
> > > > >
> > > > > Is Amalgamation only used on Android though? Are there any other
> use
> > > cases?
> > > > >
> > > > > -Marco
> > > > >
> > > > > Pedro Larroy  schrieb am Mi., 11.
> Sep.
> > > 2019,
> > > > > 11:57:
> > > > >
> > > > > > Hi Anirudh
> > > > > >
> > > > > > Appreciate your feedback and sorry if my email came across that
> way
> > > to
> > > > > > you, I think you might miss some context. I don't think calling
> > > > > > something hacky is anything bad and isn't supposed to be the
> topic
> > of
> > > > > > the discussion. It was reported as not working by users, hence
> the
> > > > > > original thread. It was a request for opinions from people who
> > might
> > > > > > actually have tried to work in Mxnet on Android.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Pedro.
> > > > > >
> > > > > >
> > > > > > On Tuesday, September 10, 2019, Anirudh Subramanian
> > > > > >  > > > > > >
> > > > > > wrote:
> > > > > > > Hi Pedro,
> > > > > > >
> > > > > > > I don't see anything "destructive" with Chris asking for
> > > > > > > justification
> > > > > > for
> > > > > > > you calling something "hacky". The only email in this thread
> > where
> > > I
> > > > > > > see
> > > > > > ad
> > > > > > > hominems and disrespectful comments is your email.
> > > > > > >
> > > > > > > On Sat, Sep 7, 2019, 10:18 PM Pedro Larroy
> > > > > > >  > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Apache mentors should have a look at these reincident
> harassment
> > > > > > >> and destructive behaviors which demotivate contributions and
> > take
> > > > > > >> action. It takes only one bad apple to ruin a community.
> > > > > > >>
> > > > > > >> The mobile solution that is known to work as of know is cross
> > > > > > >> compiling wit

Re: [DISCUSS] Remove amalgamation

[Junru Shao]

As Tianqi and Sheng mentioned, given the fact that we are able to do
deployment in a possibly better way (correct me if I was wrong), I would
love to +1 to Pedro’s proposal.

In the meantime, as a healthy open source community, I also agree with
Naveen’s point that we should do more homework for both our developers and
customers. IMHO, for example, it would be super helpful if Pedro may bring
up some documentation describing what is the “best practice” of using the
alternative of amalgamation, if our community agree to deprecate it.

Thank you guys so much for the discussion!

Junru

On Fri, Sep 27, 2019 at 17:00 Tianqi Chen  wrote:

> The original amalgamation tries to generate a single file for compilation
> via a script.  This is largely un-necessary, having a file that include the
> dependent files and compile that one is relatively easy and sometimes more
> robust(without expanding everything into a single file).
>
> I think it might makes sense to deprecate and remove the current one given
> that it is no longer properly functioning. If someone is interested, create
> another deployment example that is more standalone without the file
> expansion. Here is an reference of the "new style" used in the tvm project
> https://github.com/dmlc/tvm/tree/master/apps/howto_deploy
>
> TQ
>
> On Fri, Sep 27, 2019 at 4:49 PM Sheng Zha  wrote:
>
> > As an alternative to amalgamation, could we simply ask users to
> statically
> > link to libmxnet.a, and then prune the symbol table to get rid of the
> > binary of unused functions? Though I don't know the full context of
> > amalgamation, based on my knowledge on this feature I'm not aware of any
> > difference in the end result, compared to the code-inlining approach that
> > amalgamation takes.
> >
> > -sz
> >
> > On 2019/09/12 17:29:02, Naveen Swamy  wrote:
> > > so the original email suggesting to remove was after all self-serving
> :)
> > >
> > > let's encourage if someone wants to maintain and make use of the
> original
> > > work and make it better.
> > >
> > > -1 to remove at this point
> > >
> > > P.S: I suggest to do some due diligence before bringing topics up for
> > > discussion.
> > >
> > > On Wed, Sep 11, 2019 at 8:10 AM Lv, Tao A  wrote:
> > >
> > > > Sorry to chime in.
> > > >
> > > > There is a PR to fix amalgamation. I was pinged several times to
> merge
> > it
> > > > but I don't think I have enough knowledge to do that. So it would be
> > great
> > > > if someone from this thread can help to review.
> > > >
> > > > https://github.com/apache/incubator-mxnet/pull/15303
> > > >
> > > > thanks,
> > > > -tao
> > > >
> > > > -Original Message-
> > > > From: Marco de Abreu 
> > > > Sent: Wednesday, September 11, 2019 9:38 PM
> > > > To: dev@mxnet.incubator.apache.org
> > > > Subject: Re: [DISCUSS] Remove amalgamation
> > > >
> > > > Is Amalgamation only used on Android though? Are there any other use
> > cases?
> > > >
> > > > -Marco
> > > >
> > > > Pedro Larroy  schrieb am Mi., 11. Sep.
> > 2019,
> > > > 11:57:
> > > >
> > > > > Hi Anirudh
> > > > >
> > > > > Appreciate your feedback and sorry if my email came across that way
> > to
> > > > > you, I think you might miss some context. I don't think calling
> > > > > something hacky is anything bad and isn't supposed to be the topic
> of
> > > > > the discussion. It was reported as not working by users, hence the
> > > > > original thread. It was a request for opinions from people who
> might
> > > > > actually have tried to work in Mxnet on Android.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Pedro.
> > > > >
> > > > >
> > > > > On Tuesday, September 10, 2019, Anirudh Subramanian
> > > > >  > > > > >
> > > > > wrote:
> > > > > > Hi Pedro,
> > > > > >
> > > > > > I don't see anything "destructive" with Chris asking for
> > > > > > justification
> > > > > for
> > > > > > you calling something "hacky". The only email in this thread
> where
> > I
> > > > > > see
> > > > > ad
> > > > > > hominems and disrespectful comments is your email.
> > > > > >
> > > > > > On Sat, Sep 7, 2019, 10:18 PM Pedro Larroy
> > > > > >  > > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Apache mentors should have a look at these reincident harassment
> > > > > >> and destructive behaviors which demotivate contributions and
> take
> > > > > >> action. It takes only one bad apple to ruin a community.
> > > > > >>
> > > > > >> The mobile solution that is known to work as of know is cross
> > > > > >> compiling with "ci/build.py -p build.android_armv8" or
> > > > > >> "build.android_armv7". The only advantage of amalgamation is to
> > > > > >> provide a smaller binary that we
> > > > > could
> > > > > >> accomplish with the C preprocessor.
> > > > > >>
> > > > > >> My technical contributions speak for themselves, including
> porting
> > > > > >> MXNet
> > > > > to
> > > > > >> Android and ARM and helping many users run MXNet in Jetson,
> > > > > >> Raspberry Pi and Android amongst many other topics. I have never
> > >