Proposal of MxNet-to-ONNX exporter
def mxnet.contrib.onnx._export.export_model( sym, params, input_shape, output): """ Exports a given MXNet symbol object file or path to saved file to ONNX model file. Input Parameters - -- sym - A str object (path to json file) or mxnet symbol object or checkpointed mxnet symbol object params - A str object (path to params file) or dict object containing the model params input_shape - list of tuple object , specifies the shape of each input to the model output - path to the output file, including the filename. Default: current path , filename: model.onnx Return Type – -- onnx_model_path - str object , path to saved .onnx file. """ ... return onnx_model_path
Re: Proposal of MxNet-to-ONNX exporter
Marek, Can you add more details on your proposal? (Implementation details, operator coverage, test coverage planned) I am aware of similar work done by other contributors (Roshani, Rajan and Anirudh) - how is this going to align? Should you guys work together? Hagay On Mon, May 21, 2018, 11:17 Marek Kolodziej wrote: > def mxnet.contrib.onnx._export.export_model( sym, params, input_shape, > output): > """ > Exports a given MXNet symbol object file or path to saved file to ONNX > model file. > Input Parameters - > -- > sym - > A str object (path to json file) or mxnet symbol object or > checkpointed mxnet symbol object > params - > A str object (path to params file) or dict object containing the > model params > input_shape - > list of tuple object , specifies the shape of each input to the > model > output - > path to the output file, including the filename. Default: current > path , filename: model.onnx > > Return Type – > -- > onnx_model_path - > str object , path to saved .onnx file. > """ > ... > return onnx_model_path >
Scala Packages in Maven
I am working on publishing MXNet Scala packages of the 1.2 release to maven and observed that there are about 20 packages that needs to be published. I think this is too many of them and probably will confuse the users. I think we can cut down the number of packages, I wanted ask if someone knows why the below packages were published and if it is ok not publish them going forward. Proposing to not publish --- mxnet-full-parent_2.11 mxnet-parent_2.11 mxnet-scala-native-parent Any other packages that you propose to remove? --- ---Full List -- libmxnet-init-scala-{platform} x 2 libmxnet-scala-{platform} x 3 mxnet-core_2.11 mxnet-examples_2.11 mxnet-full-parent_2.11 mxnet-full_2.11-{platform} x 3 mxnet-infer_2.11 mxnet-init_2.11 mxnet-macros_2.11 mxnet-parent_2.11 mxnet-scala-init-native-parent mxnet-scala-native-parent mxnet-spark_2.11 --- Please let me know your thoughts? Thanks, Naveen
MXNet issues labeling
Hi, Some of us here at Amazon as a part of our day job, are triaging Github issues to find where MXNet users are experiencing difficulty and help the community focus on those areas. This is done by assigning labels to the Github issues. We do know that only labeling won’t solve the real problem but we will expand our scope to also attempt to resolve the issues. Categorizing issues could also help contributors and maintainers who know a particular area to pick up the issue and help the user. Right now, we just manually go through the issues. If they are questions, we redirect users to start a discussion on discuss forum, find the appropriate labels and then ask one of the committers to add those labels. This process is not very smooth as its completely manual and every time we need to ask committers to add labels. We want to be able to automate/simplify this issue labeling process. Right now, as far as I know, there's no way for non-committers to add labels. So, I want to propose two options: - Using a separate account having minimum permissions to run the bot script which will do the labeling. For this, we will need an account to be created from Apache infrastructure with proper access and they can control the access for the account through https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html - Using one of the committers auth token to run the script. Please let me know if you have any other ideas to do this. Thanks, Roshani
Re: MXNet issues labeling
Thanks, Roshani for starting this thread. Yes, I think labeling the issues will help a lot in driving the attention of contributors to specific areas and make it easy for new contributors to search and pick their contribution. I agree manually doing it all the time is not scalable and efficient. Your proposal on bot script to auto-label, similar to the working of Jenkins bot to re-test, re-build actions, will be very useful and effective. Hence, I am more inclined to your *option 1* to have a bot account to add labels. Best, Sandeep On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote wrote: > Hi, > > Some of us here at Amazon as a part of our day job, are triaging Github > issues to find where MXNet users are experiencing difficulty and help the > community focus on those areas. This is done by assigning labels to the > Github issues. We do know that only labeling won’t solve the real problem > but we will expand our scope to also attempt to resolve the issues. > Categorizing issues could also help contributors and maintainers who know a > particular area to pick up the issue and help the user. > > Right now, we just manually go through the issues. If they are questions, > we redirect users to start a discussion on discuss forum, find the > appropriate labels and then ask one of the committers to add those labels. > This process is not very smooth as its completely manual and every time we > need to ask committers to add labels. > > We want to be able to automate/simplify this issue labeling process. > Right now, as far as I know, there's no way for non-committers to add > labels. So, I want to propose two options: > > - Using a separate account having minimum permissions to run the bot script > which will do the labeling. For this, we will need an account to be created > from Apache infrastructure with proper access and they can control the > access for the account through > https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html > > - Using one of the committers auth token to run the script. > > Please let me know if you have any other ideas to do this. > > Thanks, > Roshani > -- Sandeep Krishnamurthy
Re: Scala Packages in Maven
I think this needs quite a bit of rework to clean up, currently I am thinking to publish only the mxnet-full_2.11-{platform} x 3 and revisit what the other packages should be published by the next release On Mon, May 21, 2018 at 3:49 PM, Naveen Swamy wrote: > I am working on publishing MXNet Scala packages of the 1.2 release to > maven and observed that there are about 20 packages that needs to be > published. I think this is too many of them and probably will confuse the > users. > > I think we can cut down the number of packages, I wanted ask if someone > knows why the below packages were published and if it is ok not publish > them going forward. > > Proposing to not publish > --- > > mxnet-full-parent_2.11 > mxnet-parent_2.11 > mxnet-scala-native-parent > Any other packages that you propose to remove? > --- > > ---Full List -- > libmxnet-init-scala-{platform} x 2 > libmxnet-scala-{platform} x 3 > mxnet-core_2.11 > mxnet-examples_2.11 > mxnet-full-parent_2.11 > mxnet-full_2.11-{platform} x 3 > mxnet-infer_2.11 > mxnet-init_2.11 > mxnet-macros_2.11 > mxnet-parent_2.11 > mxnet-scala-init-native-parent > mxnet-scala-native-parent > mxnet-spark_2.11 > --- > > Please let me know your thoughts? > > Thanks, Naveen >
Re: MXNet issues labeling
Great topic! Vote for Option 1 Labelling and problem triaging process should be a lot simpler for all developers and bring less load to committers. Thanks, Qing On 5/21/18, 4:26 PM, "sandeep krishnamurthy" wrote: Thanks, Roshani for starting this thread. Yes, I think labeling the issues will help a lot in driving the attention of contributors to specific areas and make it easy for new contributors to search and pick their contribution. I agree manually doing it all the time is not scalable and efficient. Your proposal on bot script to auto-label, similar to the working of Jenkins bot to re-test, re-build actions, will be very useful and effective. Hence, I am more inclined to your *option 1* to have a bot account to add labels. Best, Sandeep On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote wrote: > Hi, > > Some of us here at Amazon as a part of our day job, are triaging Github > issues to find where MXNet users are experiencing difficulty and help the > community focus on those areas. This is done by assigning labels to the > Github issues. We do know that only labeling won’t solve the real problem > but we will expand our scope to also attempt to resolve the issues. > Categorizing issues could also help contributors and maintainers who know a > particular area to pick up the issue and help the user. > > Right now, we just manually go through the issues. If they are questions, > we redirect users to start a discussion on discuss forum, find the > appropriate labels and then ask one of the committers to add those labels. > This process is not very smooth as its completely manual and every time we > need to ask committers to add labels. > > We want to be able to automate/simplify this issue labeling process. > Right now, as far as I know, there's no way for non-committers to add > labels. So, I want to propose two options: > > - Using a separate account having minimum permissions to run the bot script > which will do the labeling. For this, we will need an account to be created > from Apache infrastructure with proper access and they can control the > access for the account through > https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html > > - Using one of the committers auth token to run the script. > > Please let me know if you have any other ideas to do this. > > Thanks, > Roshani > -- Sandeep Krishnamurthy
Re: MXNet issues labeling
+1 for the proposal to triage issues, I think committers should also do this exercise to understand the customer pain. I am also inclined to use a bot account like how Tensorflow and other repos do it, https://github.com/googlebot. https://github.com/tensorflow/tensorflow/pull/19445#event-1638027271 --> This is auto-tagged by the bot, it would be cool if we could do that as well. On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy < sandeep.krishn...@gmail.com> wrote: > Thanks, > > Roshani for starting this thread. > > Yes, I think labeling the issues will help a lot in driving the attention > of contributors to specific areas and make it easy for new contributors to > search and pick their contribution. > > I agree manually doing it all the time is not scalable and efficient. Your > proposal on bot script to auto-label, similar to the working of Jenkins bot > to re-test, re-build actions, will be very useful and effective. Hence, I > am more inclined to your *option 1* to have a bot account to add labels. > > Best, > Sandeep > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote < > roshaninagmo...@gmail.com> > wrote: > > > Hi, > > > > Some of us here at Amazon as a part of our day job, are triaging Github > > issues to find where MXNet users are experiencing difficulty and help the > > community focus on those areas. This is done by assigning labels to the > > Github issues. We do know that only labeling won’t solve the real problem > > but we will expand our scope to also attempt to resolve the issues. > > Categorizing issues could also help contributors and maintainers who > know a > > particular area to pick up the issue and help the user. > > > > Right now, we just manually go through the issues. If they are questions, > > we redirect users to start a discussion on discuss forum, find the > > appropriate labels and then ask one of the committers to add those > labels. > > This process is not very smooth as its completely manual and every time > we > > need to ask committers to add labels. > > > > We want to be able to automate/simplify this issue labeling process. > > Right now, as far as I know, there's no way for non-committers to add > > labels. So, I want to propose two options: > > > > - Using a separate account having minimum permissions to run the bot > script > > which will do the labeling. For this, we will need an account to be > created > > from Apache infrastructure with proper access and they can control the > > access for the account through > > https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html > > > > - Using one of the committers auth token to run the script. > > > > Please let me know if you have any other ideas to do this. > > > > Thanks, > > Roshani > > > > > > -- > Sandeep Krishnamurthy >
Invitation: Apache MXNet release post mortem and next release brainstorm @ Tue May 29, 2018 8am - 9am (PDT) (dev@mxnet.incubator.apache.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20180529T15Z DTEND:20180529T16Z DTSTAMP:20180521T235736Z ORGANIZER;CN=Steffen Rochel:mailto:steffenroc...@gmail.com UID:7b5ldve1b5d1en46mkpgqiu...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Steffen Rochel;X-NUM-GUESTS=0:mailto:steffenroc...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:d...@mxnet.incu bator.apache.org CREATED:20180521T235736Z DESCRIPTION:Hi - we would like to follow up to discuss what went well or no t so well with MXNet release v1.2 and brainstorm about the next release - c ontent and schedule.\nWe will do two sessions on May 29 - 8am and 5pm PDT t o allow for call ins from different time zones. Please let me know if you n eed additional sessions and times.\n\n\n\nYou have been invited to an onlin e meeting\, powered by Amazon Chime.\n\n1. Click to join the meeting:\n\nht tps://chime.aws/1656021019\n\nMeeting ID: 1656 02 1019\n\n2. You can use yo ur computer’s microphone and speakers\, however\, a headset is recommended. Or\, call in using your phone:\n\nUnited States Toll-Free: +1 855-552-4463 \nMeeting PIN: 1656 02 1019\n\nOne-click Mobile Dial-in (United States (1)) : +1 206-462-5569\,\,1656021019#\n\nUnited States (1): +1 206-462-5569\nInt ernational: https://chime.aws/dialinnumbers/\n\n\nMeeting PIN: 1656021019#\ n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: ~:~:~:~::~:~::-\nPlease do not edit this section of the description.\n\nVie w your event at https://www.google.com/calendar/event?action=VIEW&eid=N2I1b GR2ZTFiNWQxZW40Nm1rcGdxaXVlZHIgZGV2QG14bmV0LmluY3ViYXRvci5hcGFjaGUub3Jn&tok =MjMjc3RlZmZlbnJvY2hlbEBnbWFpbC5jb204MzYwMzU4NzNlMjEyMjY0OWQ1YTZhNGVlZmMxOT QxN2ZjNDgzZjY0&ctz=America%2FLos_Angeles&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20180521T235736Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Apache MXNet release post mortem and next release brainstorm TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite.ics Description: application/ics
Re: MXNet issues labeling
Hi Roshani, Good suggestion! How will the bot decide what labels to add ? Anirudh On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy wrote: > +1 for the proposal to triage issues, I think committers should also do > this exercise to understand the customer pain. > > I am also inclined to use a bot account like how Tensorflow and other repos > do it, https://github.com/googlebot. > https://github.com/tensorflow/tensorflow/pull/19445#event-1638027271 --> > This is auto-tagged by the bot, it would be cool if we could do that as > well. > > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy < > sandeep.krishn...@gmail.com> wrote: > > > Thanks, > > > > Roshani for starting this thread. > > > > Yes, I think labeling the issues will help a lot in driving the attention > > of contributors to specific areas and make it easy for new contributors > to > > search and pick their contribution. > > > > I agree manually doing it all the time is not scalable and efficient. > Your > > proposal on bot script to auto-label, similar to the working of Jenkins > bot > > to re-test, re-build actions, will be very useful and effective. Hence, I > > am more inclined to your *option 1* to have a bot account to add labels. > > > > Best, > > Sandeep > > > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote < > > roshaninagmo...@gmail.com> > > wrote: > > > > > Hi, > > > > > > Some of us here at Amazon as a part of our day job, are triaging Github > > > issues to find where MXNet users are experiencing difficulty and help > the > > > community focus on those areas. This is done by assigning labels to the > > > Github issues. We do know that only labeling won’t solve the real > problem > > > but we will expand our scope to also attempt to resolve the issues. > > > Categorizing issues could also help contributors and maintainers who > > know a > > > particular area to pick up the issue and help the user. > > > > > > Right now, we just manually go through the issues. If they are > questions, > > > we redirect users to start a discussion on discuss forum, find the > > > appropriate labels and then ask one of the committers to add those > > labels. > > > This process is not very smooth as its completely manual and every time > > we > > > need to ask committers to add labels. > > > > > > We want to be able to automate/simplify this issue labeling process. > > > Right now, as far as I know, there's no way for non-committers to add > > > labels. So, I want to propose two options: > > > > > > - Using a separate account having minimum permissions to run the bot > > script > > > which will do the labeling. For this, we will need an account to be > > created > > > from Apache infrastructure with proper access and they can control the > > > access for the account through > > > https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html > > > > > > - Using one of the committers auth token to run the script. > > > > > > Please let me know if you have any other ideas to do this. > > > > > > Thanks, > > > Roshani > > > > > > > > > > > -- > > Sandeep Krishnamurthy > > >
Re: MXNet issues labeling
AI obviously. On Mon, May 21, 2018 at 5:01 PM, Anirudh wrote: > Hi Roshani, > > Good suggestion! How will the bot decide what labels to add ? > > Anirudh > > On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy wrote: > > > +1 for the proposal to triage issues, I think committers should also do > > this exercise to understand the customer pain. > > > > I am also inclined to use a bot account like how Tensorflow and other > repos > > do it, https://github.com/googlebot. > > https://github.com/tensorflow/tensorflow/pull/19445#event-1638027271 --> > > This is auto-tagged by the bot, it would be cool if we could do that as > > well. > > > > > > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy < > > sandeep.krishn...@gmail.com> wrote: > > > > > Thanks, > > > > > > Roshani for starting this thread. > > > > > > Yes, I think labeling the issues will help a lot in driving the > attention > > > of contributors to specific areas and make it easy for new contributors > > to > > > search and pick their contribution. > > > > > > I agree manually doing it all the time is not scalable and efficient. > > Your > > > proposal on bot script to auto-label, similar to the working of Jenkins > > bot > > > to re-test, re-build actions, will be very useful and effective. > Hence, I > > > am more inclined to your *option 1* to have a bot account to add > labels. > > > > > > Best, > > > Sandeep > > > > > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote < > > > roshaninagmo...@gmail.com> > > > wrote: > > > > > > > Hi, > > > > > > > > Some of us here at Amazon as a part of our day job, are triaging > Github > > > > issues to find where MXNet users are experiencing difficulty and help > > the > > > > community focus on those areas. This is done by assigning labels to > the > > > > Github issues. We do know that only labeling won’t solve the real > > problem > > > > but we will expand our scope to also attempt to resolve the issues. > > > > Categorizing issues could also help contributors and maintainers who > > > know a > > > > particular area to pick up the issue and help the user. > > > > > > > > Right now, we just manually go through the issues. If they are > > questions, > > > > we redirect users to start a discussion on discuss forum, find the > > > > appropriate labels and then ask one of the committers to add those > > > labels. > > > > This process is not very smooth as its completely manual and every > time > > > we > > > > need to ask committers to add labels. > > > > > > > > We want to be able to automate/simplify this issue labeling process. > > > > Right now, as far as I know, there's no way for non-committers to add > > > > labels. So, I want to propose two options: > > > > > > > > - Using a separate account having minimum permissions to run the bot > > > script > > > > which will do the labeling. For this, we will need an account to be > > > created > > > > from Apache infrastructure with proper access and they can control > the > > > > access for the account through > > > > https://docs.aws.amazon.com/secretsmanager/latest/ > userguide/intro.html > > > > > > > > - Using one of the committers auth token to run the script. > > > > > > > > Please let me know if you have any other ideas to do this. > > > > > > > > Thanks, > > > > Roshani > > > > > > > > > > > > > > > > -- > > > Sandeep Krishnamurthy > > > > > >
Re: MXNet issues labeling
Yes, I guessed that :). Was looking for more details. On Mon, May 21, 2018 at 5:03 PM, Aaron Markham wrote: > AI obviously. > > On Mon, May 21, 2018 at 5:01 PM, Anirudh wrote: > > > Hi Roshani, > > > > Good suggestion! How will the bot decide what labels to add ? > > > > Anirudh > > > > On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy > wrote: > > > > > +1 for the proposal to triage issues, I think committers should also do > > > this exercise to understand the customer pain. > > > > > > I am also inclined to use a bot account like how Tensorflow and other > > repos > > > do it, https://github.com/googlebot. > > > https://github.com/tensorflow/tensorflow/pull/19445#event-1638027271 > --> > > > This is auto-tagged by the bot, it would be cool if we could do that as > > > well. > > > > > > > > > > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy < > > > sandeep.krishn...@gmail.com> wrote: > > > > > > > Thanks, > > > > > > > > Roshani for starting this thread. > > > > > > > > Yes, I think labeling the issues will help a lot in driving the > > attention > > > > of contributors to specific areas and make it easy for new > contributors > > > to > > > > search and pick their contribution. > > > > > > > > I agree manually doing it all the time is not scalable and efficient. > > > Your > > > > proposal on bot script to auto-label, similar to the working of > Jenkins > > > bot > > > > to re-test, re-build actions, will be very useful and effective. > > Hence, I > > > > am more inclined to your *option 1* to have a bot account to add > > labels. > > > > > > > > Best, > > > > Sandeep > > > > > > > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote < > > > > roshaninagmo...@gmail.com> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > Some of us here at Amazon as a part of our day job, are triaging > > Github > > > > > issues to find where MXNet users are experiencing difficulty and > help > > > the > > > > > community focus on those areas. This is done by assigning labels to > > the > > > > > Github issues. We do know that only labeling won’t solve the real > > > problem > > > > > but we will expand our scope to also attempt to resolve the issues. > > > > > Categorizing issues could also help contributors and maintainers > who > > > > know a > > > > > particular area to pick up the issue and help the user. > > > > > > > > > > Right now, we just manually go through the issues. If they are > > > questions, > > > > > we redirect users to start a discussion on discuss forum, find the > > > > > appropriate labels and then ask one of the committers to add those > > > > labels. > > > > > This process is not very smooth as its completely manual and every > > time > > > > we > > > > > need to ask committers to add labels. > > > > > > > > > > We want to be able to automate/simplify this issue labeling > process. > > > > > Right now, as far as I know, there's no way for non-committers to > add > > > > > labels. So, I want to propose two options: > > > > > > > > > > - Using a separate account having minimum permissions to run the > bot > > > > script > > > > > which will do the labeling. For this, we will need an account to be > > > > created > > > > > from Apache infrastructure with proper access and they can control > > the > > > > > access for the account through > > > > > https://docs.aws.amazon.com/secretsmanager/latest/ > > userguide/intro.html > > > > > > > > > > - Using one of the committers auth token to run the script. > > > > > > > > > > Please let me know if you have any other ideas to do this. > > > > > > > > > > Thanks, > > > > > Roshani > > > > > > > > > > > > > > > > > > > > > -- > > > > Sandeep Krishnamurthy > > > > > > > > > >
Re: Config for Scala Maven Package
Hi Naveen, thank you for driving the releases for the Scala packages! For CPU, I'd propose add MKL/MKLDNN builds. For GPU, do we have to specify the minor version of CUDA up front or are they interchangeable? CUDA 9.2, for example, received some quite significant performance updates and it would be great if our users could use them. Best regards, Marco On Fri, May 18, 2018 at 8:28 PM, Naveen Swamy wrote: > I am working on publishing the Scala package from 1.2.0 release. What do > you recommend should be the configuration for the Scala Packages ? > > I am thinking of the below > For CPU build with > OPENBLAS > LAPACK > > For GPU build with > OPENBLAS > CUDA 9.0 > NCCL > > Let me know if you concerns or recommendations. > > Thanks, Naveen >
Re: Scala Packages in Maven
Agree, we should make a proper assessment of what all these packages are before we try managing them. Do you know who published them before? Moving forward, it'd be great if you could document the entire process (and all issues you encounter) in confluence. This would allow us to re-visit decisions later on and give us a source of information for questions exactly like this one. If we decide to add a new package to the publish process, we could just document it there and have a central point to look it up. -Marco On Tue, May 22, 2018 at 1:34 AM, Naveen Swamy wrote: > I think this needs quite a bit of rework to clean up, currently I am > thinking to publish only the mxnet-full_2.11-{platform} x 3 and revisit > what the other packages should be published by the next release > > On Mon, May 21, 2018 at 3:49 PM, Naveen Swamy wrote: > > > I am working on publishing MXNet Scala packages of the 1.2 release to > > maven and observed that there are about 20 packages that needs to be > > published. I think this is too many of them and probably will confuse the > > users. > > > > I think we can cut down the number of packages, I wanted ask if someone > > knows why the below packages were published and if it is ok not publish > > them going forward. > > > > Proposing to not publish > > --- > > > > mxnet-full-parent_2.11 > > mxnet-parent_2.11 > > mxnet-scala-native-parent > > Any other packages that you propose to remove? > > --- > > > > ---Full List -- > > libmxnet-init-scala-{platform} x 2 > > libmxnet-scala-{platform} x 3 > > mxnet-core_2.11 > > mxnet-examples_2.11 > > mxnet-full-parent_2.11 > > mxnet-full_2.11-{platform} x 3 > > mxnet-infer_2.11 > > mxnet-init_2.11 > > mxnet-macros_2.11 > > mxnet-parent_2.11 > > mxnet-scala-init-native-parent > > mxnet-scala-native-parent > > mxnet-spark_2.11 > > --- > > > > Please let me know your thoughts? > > > > Thanks, Naveen > > >
Re: Scala Packages in Maven
I am not sure who published it in the past, hence this discussion. I am already in the process of documenting them here, I clean it up and add more info as I make progress. 1) https://cwiki.apache.org/confluence/display/MXNET/Release+Process#ReleaseProcess-Step1.12.CreateScalaMavenPackages(WIP) 2) https://cwiki.apache.org/confluence/display/MXNET/MXNet-Scala On Mon, May 21, 2018 at 5:37 PM, Marco de Abreu < marco.g.ab...@googlemail.com> wrote: > Agree, we should make a proper assessment of what all these packages are > before we try managing them. Do you know who published them before? > > Moving forward, it'd be great if you could document the entire process (and > all issues you encounter) in confluence. This would allow us to re-visit > decisions later on and give us a source of information for questions > exactly like this one. If we decide to add a new package to the publish > process, we could just document it there and have a central point to look > it up. > > -Marco > > On Tue, May 22, 2018 at 1:34 AM, Naveen Swamy wrote: > > > I think this needs quite a bit of rework to clean up, currently I am > > thinking to publish only the mxnet-full_2.11-{platform} x 3 and revisit > > what the other packages should be published by the next release > > > > On Mon, May 21, 2018 at 3:49 PM, Naveen Swamy > wrote: > > > > > I am working on publishing MXNet Scala packages of the 1.2 release to > > > maven and observed that there are about 20 packages that needs to be > > > published. I think this is too many of them and probably will confuse > the > > > users. > > > > > > I think we can cut down the number of packages, I wanted ask if someone > > > knows why the below packages were published and if it is ok not publish > > > them going forward. > > > > > > Proposing to not publish > > > --- > > > > > > mxnet-full-parent_2.11 > > > mxnet-parent_2.11 > > > mxnet-scala-native-parent > > > Any other packages that you propose to remove? > > > --- > > > > > > ---Full List -- > > > libmxnet-init-scala-{platform} x 2 > > > libmxnet-scala-{platform} x 3 > > > mxnet-core_2.11 > > > mxnet-examples_2.11 > > > mxnet-full-parent_2.11 > > > mxnet-full_2.11-{platform} x 3 > > > mxnet-infer_2.11 > > > mxnet-init_2.11 > > > mxnet-macros_2.11 > > > mxnet-parent_2.11 > > > mxnet-scala-init-native-parent > > > mxnet-scala-native-parent > > > mxnet-spark_2.11 > > > --- > > > > > > Please let me know your thoughts? > > > > > > Thanks, Naveen > > > > > >
Re: MXNet issues labeling
Definitely a good idea. I think maybe we can also try out the new gluon NLP toolkit on this task? On 5/21/18, 5:24 PM, "Anirudh" wrote: Yes, I guessed that :). Was looking for more details. On Mon, May 21, 2018 at 5:03 PM, Aaron Markham wrote: > AI obviously. > > On Mon, May 21, 2018 at 5:01 PM, Anirudh wrote: > > > Hi Roshani, > > > > Good suggestion! How will the bot decide what labels to add ? > > > > Anirudh > > > > On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy > wrote: > > > > > +1 for the proposal to triage issues, I think committers should also do > > > this exercise to understand the customer pain. > > > > > > I am also inclined to use a bot account like how Tensorflow and other > > repos > > > do it, https://github.com/googlebot. > > > https://github.com/tensorflow/tensorflow/pull/19445#event-1638027271 > --> > > > This is auto-tagged by the bot, it would be cool if we could do that as > > > well. > > > > > > > > > > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy < > > > sandeep.krishn...@gmail.com> wrote: > > > > > > > Thanks, > > > > > > > > Roshani for starting this thread. > > > > > > > > Yes, I think labeling the issues will help a lot in driving the > > attention > > > > of contributors to specific areas and make it easy for new > contributors > > > to > > > > search and pick their contribution. > > > > > > > > I agree manually doing it all the time is not scalable and efficient. > > > Your > > > > proposal on bot script to auto-label, similar to the working of > Jenkins > > > bot > > > > to re-test, re-build actions, will be very useful and effective. > > Hence, I > > > > am more inclined to your *option 1* to have a bot account to add > > labels. > > > > > > > > Best, > > > > Sandeep > > > > > > > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote < > > > > roshaninagmo...@gmail.com> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > Some of us here at Amazon as a part of our day job, are triaging > > Github > > > > > issues to find where MXNet users are experiencing difficulty and > help > > > the > > > > > community focus on those areas. This is done by assigning labels to > > the > > > > > Github issues. We do know that only labeling won’t solve the real > > > problem > > > > > but we will expand our scope to also attempt to resolve the issues. > > > > > Categorizing issues could also help contributors and maintainers > who > > > > know a > > > > > particular area to pick up the issue and help the user. > > > > > > > > > > Right now, we just manually go through the issues. If they are > > > questions, > > > > > we redirect users to start a discussion on discuss forum, find the > > > > > appropriate labels and then ask one of the committers to add those > > > > labels. > > > > > This process is not very smooth as its completely manual and every > > time > > > > we > > > > > need to ask committers to add labels. > > > > > > > > > > We want to be able to automate/simplify this issue labeling > process. > > > > > Right now, as far as I know, there's no way for non-committers to > add > > > > > labels. So, I want to propose two options: > > > > > > > > > > - Using a separate account having minimum permissions to run the > bot > > > > script > > > > > which will do the labeling. For this, we will need an account to be > > > > created > > > > > from Apache infrastructure with proper access and they can control > > the > > > > > access for the account through > > > > > https://docs.aws.amazon.com/secretsmanager/latest/ > > userguide/intro.html > > > > > > > > > > - Using one of the committers auth token to run the script. > > > > > > > > > > Please let me know if you have any other ideas to do this. > > > > > > > > > > Thanks, > > > > > Roshani > > > > > > > > > > > > > > > > > > > > > -- > > > > Sandeep Krishnamurthy > > > > > > > > > >
Re: MXNet issues labeling
Haha, Aaron could work in marketing - AI solves everything! :P But yeah, a bit more details would be good. As an alternative approach, I'd like to propose a bot that does actions on your behalf. In this case, we could have a bit that listens for comments and (based on a whitelist), it would apply labels if certain contributors commented and requested the labels to be assigned. I know that this still involves manual work, but it would greatly reduce the round trip time since the bot would assign them instantaneously. This means, the only difference for contributors would be to make a comment instead of pressing the "labels" button. Would this solution also be feasible? -Marco On Tue, May 22, 2018 at 2:24 AM, Anirudh wrote: > Yes, I guessed that :). Was looking for more details. > > On Mon, May 21, 2018 at 5:03 PM, Aaron Markham > wrote: > > > AI obviously. > > > > On Mon, May 21, 2018 at 5:01 PM, Anirudh wrote: > > > > > Hi Roshani, > > > > > > Good suggestion! How will the bot decide what labels to add ? > > > > > > Anirudh > > > > > > On Mon, May 21, 2018 at 4:39 PM, Naveen Swamy > > wrote: > > > > > > > +1 for the proposal to triage issues, I think committers should also > do > > > > this exercise to understand the customer pain. > > > > > > > > I am also inclined to use a bot account like how Tensorflow and other > > > repos > > > > do it, https://github.com/googlebot. > > > > https://github.com/tensorflow/tensorflow/pull/19445#event-1638027271 > > --> > > > > This is auto-tagged by the bot, it would be cool if we could do that > as > > > > well. > > > > > > > > > > > > > > > > On Mon, May 21, 2018 at 4:25 PM, sandeep krishnamurthy < > > > > sandeep.krishn...@gmail.com> wrote: > > > > > > > > > Thanks, > > > > > > > > > > Roshani for starting this thread. > > > > > > > > > > Yes, I think labeling the issues will help a lot in driving the > > > attention > > > > > of contributors to specific areas and make it easy for new > > contributors > > > > to > > > > > search and pick their contribution. > > > > > > > > > > I agree manually doing it all the time is not scalable and > efficient. > > > > Your > > > > > proposal on bot script to auto-label, similar to the working of > > Jenkins > > > > bot > > > > > to re-test, re-build actions, will be very useful and effective. > > > Hence, I > > > > > am more inclined to your *option 1* to have a bot account to add > > > labels. > > > > > > > > > > Best, > > > > > Sandeep > > > > > > > > > > On Mon, May 21, 2018 at 4:16 PM, Roshani Nagmote < > > > > > roshaninagmo...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > Some of us here at Amazon as a part of our day job, are triaging > > > Github > > > > > > issues to find where MXNet users are experiencing difficulty and > > help > > > > the > > > > > > community focus on those areas. This is done by assigning labels > to > > > the > > > > > > Github issues. We do know that only labeling won’t solve the real > > > > problem > > > > > > but we will expand our scope to also attempt to resolve the > issues. > > > > > > Categorizing issues could also help contributors and maintainers > > who > > > > > know a > > > > > > particular area to pick up the issue and help the user. > > > > > > > > > > > > Right now, we just manually go through the issues. If they are > > > > questions, > > > > > > we redirect users to start a discussion on discuss forum, find > the > > > > > > appropriate labels and then ask one of the committers to add > those > > > > > labels. > > > > > > This process is not very smooth as its completely manual and > every > > > time > > > > > we > > > > > > need to ask committers to add labels. > > > > > > > > > > > > We want to be able to automate/simplify this issue labeling > > process. > > > > > > Right now, as far as I know, there's no way for non-committers to > > add > > > > > > labels. So, I want to propose two options: > > > > > > > > > > > > - Using a separate account having minimum permissions to run the > > bot > > > > > script > > > > > > which will do the labeling. For this, we will need an account to > be > > > > > created > > > > > > from Apache infrastructure with proper access and they can > control > > > the > > > > > > access for the account through > > > > > > https://docs.aws.amazon.com/secretsmanager/latest/ > > > userguide/intro.html > > > > > > > > > > > > - Using one of the committers auth token to run the script. > > > > > > > > > > > > Please let me know if you have any other ideas to do this. > > > > > > > > > > > > Thanks, > > > > > > Roshani > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sandeep Krishnamurthy > > > > > > > > > > > > > > >
Re: Config for Scala Maven Package
Hi Marco, For MKL/MKLDNN --> I don't think we should build since its still experimental. Its sad that MKLML was removed without a proper discussion, granted I have not tested with CUDA 9.2, I will building on a AWS Ubuntu instance that is built with CUDA 9.0, I presume it should work fine. On Mon, May 21, 2018 at 5:31 PM, Marco de Abreu < marco.g.ab...@googlemail.com> wrote: > Hi Naveen, > > thank you for driving the releases for the Scala packages! > > For CPU, I'd propose add MKL/MKLDNN builds. > > For GPU, do we have to specify the minor version of CUDA up front or are > they interchangeable? CUDA 9.2, for example, received some quite > significant performance updates and it would be great if our users could > use them. > > Best regards, > Marco > > On Fri, May 18, 2018 at 8:28 PM, Naveen Swamy wrote: > > > I am working on publishing the Scala package from 1.2.0 release. What do > > you recommend should be the configuration for the Scala Packages ? > > > > I am thinking of the below > > For CPU build with > > OPENBLAS > > LAPACK > > > > For GPU build with > > OPENBLAS > > CUDA 9.0 > > NCCL > > > > Let me know if you concerns or recommendations. > > > > Thanks, Naveen > > >
Re: Scala Packages in Maven
Great, thanks a lot. This looks great! Is the result of your process going to be a script we can run to generate the artefacts? AFAIK, there's been attempts in the community to push towards CD, thus it'd be great if this process could directly be designed with an automated processing step in mind. -Marco On Tue, May 22, 2018 at 2:41 AM, Naveen Swamy wrote: > I am not sure who published it in the past, hence this discussion. > > I am already in the process of documenting them here, I clean it up and add > more info as I make progress. > 1) > https://cwiki.apache.org/confluence/display/MXNET/Release+Process# > ReleaseProcess-Step1.12.CreateScalaMavenPackages(WIP) > > 2) https://cwiki.apache.org/confluence/display/MXNET/MXNet-Scala > > On Mon, May 21, 2018 at 5:37 PM, Marco de Abreu < > marco.g.ab...@googlemail.com> wrote: > > > Agree, we should make a proper assessment of what all these packages are > > before we try managing them. Do you know who published them before? > > > > Moving forward, it'd be great if you could document the entire process > (and > > all issues you encounter) in confluence. This would allow us to re-visit > > decisions later on and give us a source of information for questions > > exactly like this one. If we decide to add a new package to the publish > > process, we could just document it there and have a central point to look > > it up. > > > > -Marco > > > > On Tue, May 22, 2018 at 1:34 AM, Naveen Swamy > wrote: > > > > > I think this needs quite a bit of rework to clean up, currently I am > > > thinking to publish only the mxnet-full_2.11-{platform} x 3 and revisit > > > what the other packages should be published by the next release > > > > > > On Mon, May 21, 2018 at 3:49 PM, Naveen Swamy > > wrote: > > > > > > > I am working on publishing MXNet Scala packages of the 1.2 release to > > > > maven and observed that there are about 20 packages that needs to be > > > > published. I think this is too many of them and probably will confuse > > the > > > > users. > > > > > > > > I think we can cut down the number of packages, I wanted ask if > someone > > > > knows why the below packages were published and if it is ok not > publish > > > > them going forward. > > > > > > > > Proposing to not publish > > > > --- > > > > > > > > mxnet-full-parent_2.11 > > > > mxnet-parent_2.11 > > > > mxnet-scala-native-parent > > > > Any other packages that you propose to remove? > > > > --- > > > > > > > > ---Full List -- > > > > libmxnet-init-scala-{platform} x 2 > > > > libmxnet-scala-{platform} x 3 > > > > mxnet-core_2.11 > > > > mxnet-examples_2.11 > > > > mxnet-full-parent_2.11 > > > > mxnet-full_2.11-{platform} x 3 > > > > mxnet-infer_2.11 > > > > mxnet-init_2.11 > > > > mxnet-macros_2.11 > > > > mxnet-parent_2.11 > > > > mxnet-scala-init-native-parent > > > > mxnet-scala-native-parent > > > > mxnet-spark_2.11 > > > > --- > > > > > > > > Please let me know your thoughts? > > > > > > > > Thanks, Naveen > > > > > > > > > >
Re: Scala Packages in Maven
not at the moment, certainly is in my radar. Apache release requires a committer's LDAP username/password. we could see how we can leverage CI setup to do this On Mon, May 21, 2018 at 5:44 PM, Marco de Abreu < marco.g.ab...@googlemail.com> wrote: > Great, thanks a lot. This looks great! > > Is the result of your process going to be a script we can run to generate > the artefacts? AFAIK, there's been attempts in the community to push > towards CD, thus it'd be great if this process could directly be designed > with an automated processing step in mind. > > -Marco > > On Tue, May 22, 2018 at 2:41 AM, Naveen Swamy wrote: > > > I am not sure who published it in the past, hence this discussion. > > > > I am already in the process of documenting them here, I clean it up and > add > > more info as I make progress. > > 1) > > https://cwiki.apache.org/confluence/display/MXNET/Release+Process# > > ReleaseProcess-Step1.12.CreateScalaMavenPackages(WIP) > > > > 2) https://cwiki.apache.org/confluence/display/MXNET/MXNet-Scala > > > > On Mon, May 21, 2018 at 5:37 PM, Marco de Abreu < > > marco.g.ab...@googlemail.com> wrote: > > > > > Agree, we should make a proper assessment of what all these packages > are > > > before we try managing them. Do you know who published them before? > > > > > > Moving forward, it'd be great if you could document the entire process > > (and > > > all issues you encounter) in confluence. This would allow us to > re-visit > > > decisions later on and give us a source of information for questions > > > exactly like this one. If we decide to add a new package to the publish > > > process, we could just document it there and have a central point to > look > > > it up. > > > > > > -Marco > > > > > > On Tue, May 22, 2018 at 1:34 AM, Naveen Swamy > > wrote: > > > > > > > I think this needs quite a bit of rework to clean up, currently I am > > > > thinking to publish only the mxnet-full_2.11-{platform} x 3 and > revisit > > > > what the other packages should be published by the next release > > > > > > > > On Mon, May 21, 2018 at 3:49 PM, Naveen Swamy > > > wrote: > > > > > > > > > I am working on publishing MXNet Scala packages of the 1.2 release > to > > > > > maven and observed that there are about 20 packages that needs to > be > > > > > published. I think this is too many of them and probably will > confuse > > > the > > > > > users. > > > > > > > > > > I think we can cut down the number of packages, I wanted ask if > > someone > > > > > knows why the below packages were published and if it is ok not > > publish > > > > > them going forward. > > > > > > > > > > Proposing to not publish > > > > > --- > > > > > > > > > > mxnet-full-parent_2.11 > > > > > mxnet-parent_2.11 > > > > > mxnet-scala-native-parent > > > > > Any other packages that you propose to remove? > > > > > --- > > > > > > > > > > ---Full List -- > > > > > libmxnet-init-scala-{platform} x 2 > > > > > libmxnet-scala-{platform} x 3 > > > > > mxnet-core_2.11 > > > > > mxnet-examples_2.11 > > > > > mxnet-full-parent_2.11 > > > > > mxnet-full_2.11-{platform} x 3 > > > > > mxnet-infer_2.11 > > > > > mxnet-init_2.11 > > > > > mxnet-macros_2.11 > > > > > mxnet-parent_2.11 > > > > > mxnet-scala-init-native-parent > > > > > mxnet-scala-native-parent > > > > > mxnet-spark_2.11 > > > > > --- > > > > > > > > > > Please let me know your thoughts? > > > > > > > > > > Thanks, Naveen > > > > > > > > > > > > > > >
Re: Scala Packages in Maven
+1 for a CD for publishing to Maven +1 for reducing the number of packages. Do we really need more than full, infer and spark (x3 platforms)? On Mon, May 21, 2018 at 5:47 PM, Naveen Swamy wrote: > not at the moment, certainly is in my radar. Apache release requires a > committer's LDAP username/password. we could see how we can leverage CI > setup to do this > > On Mon, May 21, 2018 at 5:44 PM, Marco de Abreu < > marco.g.ab...@googlemail.com> wrote: > > > Great, thanks a lot. This looks great! > > > > Is the result of your process going to be a script we can run to generate > > the artefacts? AFAIK, there's been attempts in the community to push > > towards CD, thus it'd be great if this process could directly be designed > > with an automated processing step in mind. > > > > -Marco > > > > On Tue, May 22, 2018 at 2:41 AM, Naveen Swamy > wrote: > > > > > I am not sure who published it in the past, hence this discussion. > > > > > > I am already in the process of documenting them here, I clean it up and > > add > > > more info as I make progress. > > > 1) > > > https://cwiki.apache.org/confluence/display/MXNET/Release+Process# > > > ReleaseProcess-Step1.12.CreateScalaMavenPackages(WIP) > > > > > > 2) https://cwiki.apache.org/confluence/display/MXNET/MXNet-Scala > > > > > > On Mon, May 21, 2018 at 5:37 PM, Marco de Abreu < > > > marco.g.ab...@googlemail.com> wrote: > > > > > > > Agree, we should make a proper assessment of what all these packages > > are > > > > before we try managing them. Do you know who published them before? > > > > > > > > Moving forward, it'd be great if you could document the entire > process > > > (and > > > > all issues you encounter) in confluence. This would allow us to > > re-visit > > > > decisions later on and give us a source of information for questions > > > > exactly like this one. If we decide to add a new package to the > publish > > > > process, we could just document it there and have a central point to > > look > > > > it up. > > > > > > > > -Marco > > > > > > > > On Tue, May 22, 2018 at 1:34 AM, Naveen Swamy > > > wrote: > > > > > > > > > I think this needs quite a bit of rework to clean up, currently I > am > > > > > thinking to publish only the mxnet-full_2.11-{platform} x 3 and > > revisit > > > > > what the other packages should be published by the next release > > > > > > > > > > On Mon, May 21, 2018 at 3:49 PM, Naveen Swamy > > > > wrote: > > > > > > > > > > > I am working on publishing MXNet Scala packages of the 1.2 > release > > to > > > > > > maven and observed that there are about 20 packages that needs to > > be > > > > > > published. I think this is too many of them and probably will > > confuse > > > > the > > > > > > users. > > > > > > > > > > > > I think we can cut down the number of packages, I wanted ask if > > > someone > > > > > > knows why the below packages were published and if it is ok not > > > publish > > > > > > them going forward. > > > > > > > > > > > > Proposing to not publish > > > > > > --- > > > > > > > > > > > > mxnet-full-parent_2.11 > > > > > > mxnet-parent_2.11 > > > > > > mxnet-scala-native-parent > > > > > > Any other packages that you propose to remove? > > > > > > --- > > > > > > > > > > > > ---Full List -- > > > > > > libmxnet-init-scala-{platform} x 2 > > > > > > libmxnet-scala-{platform} x 3 > > > > > > mxnet-core_2.11 > > > > > > mxnet-examples_2.11 > > > > > > mxnet-full-parent_2.11 > > > > > > mxnet-full_2.11-{platform} x 3 > > > > > > mxnet-infer_2.11 > > > > > > mxnet-init_2.11 > > > > > > mxnet-macros_2.11 > > > > > > mxnet-parent_2.11 > > > > > > mxnet-scala-init-native-parent > > > > > > mxnet-scala-native-parent > > > > > > mxnet-spark_2.11 > > > > > > --- > > > > > > > > > > > > Please let me know your thoughts? > > > > > > > > > > > > Thanks, Naveen > > > > > > > > > > > > > > > > > > > > >
Re: Scala Packages in Maven
I am working to publish the full package for the 3 platforms that also contains infer package. Spark package does not have any tests at the moment. I think it needs some testing before we can publish to maven. On Mon, May 21, 2018 at 9:19 PM, Hagay Lupesko wrote: > +1 for a CD for publishing to Maven > +1 for reducing the number of packages. Do we really need more than full, > infer and spark (x3 platforms)? > > On Mon, May 21, 2018 at 5:47 PM, Naveen Swamy wrote: > > > not at the moment, certainly is in my radar. Apache release requires a > > committer's LDAP username/password. we could see how we can leverage CI > > setup to do this > > > > On Mon, May 21, 2018 at 5:44 PM, Marco de Abreu < > > marco.g.ab...@googlemail.com> wrote: > > > > > Great, thanks a lot. This looks great! > > > > > > Is the result of your process going to be a script we can run to > generate > > > the artefacts? AFAIK, there's been attempts in the community to push > > > towards CD, thus it'd be great if this process could directly be > designed > > > with an automated processing step in mind. > > > > > > -Marco > > > > > > On Tue, May 22, 2018 at 2:41 AM, Naveen Swamy > > wrote: > > > > > > > I am not sure who published it in the past, hence this discussion. > > > > > > > > I am already in the process of documenting them here, I clean it up > and > > > add > > > > more info as I make progress. > > > > 1) > > > > https://cwiki.apache.org/confluence/display/MXNET/Release+Process# > > > > ReleaseProcess-Step1.12.CreateScalaMavenPackages(WIP) > > > > > > > > 2) https://cwiki.apache.org/confluence/display/MXNET/MXNet-Scala > > > > > > > > On Mon, May 21, 2018 at 5:37 PM, Marco de Abreu < > > > > marco.g.ab...@googlemail.com> wrote: > > > > > > > > > Agree, we should make a proper assessment of what all these > packages > > > are > > > > > before we try managing them. Do you know who published them before? > > > > > > > > > > Moving forward, it'd be great if you could document the entire > > process > > > > (and > > > > > all issues you encounter) in confluence. This would allow us to > > > re-visit > > > > > decisions later on and give us a source of information for > questions > > > > > exactly like this one. If we decide to add a new package to the > > publish > > > > > process, we could just document it there and have a central point > to > > > look > > > > > it up. > > > > > > > > > > -Marco > > > > > > > > > > On Tue, May 22, 2018 at 1:34 AM, Naveen Swamy > > > > wrote: > > > > > > > > > > > I think this needs quite a bit of rework to clean up, currently I > > am > > > > > > thinking to publish only the mxnet-full_2.11-{platform} x 3 and > > > revisit > > > > > > what the other packages should be published by the next release > > > > > > > > > > > > On Mon, May 21, 2018 at 3:49 PM, Naveen Swamy < > mnnav...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > I am working on publishing MXNet Scala packages of the 1.2 > > release > > > to > > > > > > > maven and observed that there are about 20 packages that needs > to > > > be > > > > > > > published. I think this is too many of them and probably will > > > confuse > > > > > the > > > > > > > users. > > > > > > > > > > > > > > I think we can cut down the number of packages, I wanted ask if > > > > someone > > > > > > > knows why the below packages were published and if it is ok not > > > > publish > > > > > > > them going forward. > > > > > > > > > > > > > > Proposing to not publish > > > > > > > --- > > > > > > > > > > > > > > mxnet-full-parent_2.11 > > > > > > > mxnet-parent_2.11 > > > > > > > mxnet-scala-native-parent > > > > > > > Any other packages that you propose to remove? > > > > > > > --- > > > > > > > > > > > > > > ---Full List -- > > > > > > > libmxnet-init-scala-{platform} x 2 > > > > > > > libmxnet-scala-{platform} x 3 > > > > > > > mxnet-core_2.11 > > > > > > > mxnet-examples_2.11 > > > > > > > mxnet-full-parent_2.11 > > > > > > > mxnet-full_2.11-{platform} x 3 > > > > > > > mxnet-infer_2.11 > > > > > > > mxnet-init_2.11 > > > > > > > mxnet-macros_2.11 > > > > > > > mxnet-parent_2.11 > > > > > > > mxnet-scala-init-native-parent > > > > > > > mxnet-scala-native-parent > > > > > > > mxnet-spark_2.11 > > > > > > > --- > > > > > > > > > > > > > > Please let me know your thoughts? > > > > > > > > > > > > > > Thanks, Naveen > > > > > > > > > > > > > > > > > > > > > > > > > > > >