Re: Update for 1.5.1 patch release
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
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
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
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
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
Re: [DISCUSS] Remove amalgamation
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
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. > > > > > > > > > > > > > >
Update for 1.5.1 patch release
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
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
Re: [DISCUSS] Remove amalgamation
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 > > >
