Re: Questions about MXNet Incubation

2019-01-16 Thread Isabel Drost-Fromm



Am 17. Januar 2019 00:26:04 MEZ schrieb Bob Paulin :
>> *What are the benefits of graduation for the project and our end
>users?*
>This is one of those: "It's more about the Journey than the end
>destination."  Projects that complete incubation have demonstrated that
>they meet a certain bar.  And while that by no means guarantee eternal
>success it does mean that you have met the ASF standard for exit which
>is not easy.  It means that going forward a report will be submitted to
>the board describing how your project is doing that end users will be
>able to read.  This is beyond "How many stars or downloads per month"
>type of stats that let your user community know you're not going away
>anytime soon.  One of the criticisms I often hear of the ASF is that
>projects just don't die (usually around some project that they believe
>is old or should be deprecated).   To me this is a feature since as
>long
>as people care about the project it can live as long as it wants.

That's a nice summary of what the goal of having an incubator is. Something I 
personally would love to know is what other projects having gone through the 
process think of it's benefits and drawbacks, what really was it that changed 
on their journey through the incubator and into being a tlp.

Carin (or anyone else really), with the 20th anniversary of the ASF coming up - 
would you mind starting a thread on the topic over at dev@community and reach 
out to other projects (both recently graduated and well established and 
popular) and look for some answers to the question? Would be great if others on 
this list could help with gathering that information...

Isabel


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.


RE: Design proposal - MXNet end to end models - Models with data transformations

2019-01-16 Thread Zhao, Patric
+1 for this great proposal. 

MXNet will be more flexible and portable with this new feature :)

Thanks,

--Patric


> -Original Message-
> From: sandeep krishnamurthy [mailto:sandeep.krishn...@gmail.com]
> Sent: Thursday, January 17, 2019 8:47 AM
> To: dev@mxnet.incubator.apache.org
> Subject: Design proposal - MXNet end to end models - Models with data
> transformations
> 
> Hello Community,
> 
> Me along with fellow MXNet contributors (Jake
> , Karan ) are
> working on the following problem:
> 1. Some of the data transformations used in training is applicable during
> inference. Most commonly transformations on validation data is same as
> transformations required during inference.
> 2. MXNet models do not contain data transformations as part of the graph.
> Making it harder, time consuming and duplicated effort to re create data
> transformation during inference. This problem is more evident in cross
> language use cases. Training in Gluon (Python) and inference in Java/C++.
> 
> After few initial discussions with some of MXNet contributors (Zhi
> , Naveen ,
> Sina ), design proposal, development plan,
> tasks, milestones and more details are captured in this document.
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+end+to+end+
> models
> 
> Please do provide your feedback via comments in the document or on this e-
> mail. All contributions are welcome. I will be creating JIRA stories and 
> issues
> for initial tasks identified.
> 
> --
> Sandeep Krishnamurthy


Re: Design proposal - MXNet end to end models - Models with data transformations

2019-01-16 Thread Sheng Zha
Hi Sandeep,

Thanks for taking the initiative and sharing the proposal. It's great to
see the image operators being extended.

To summarize, the design for the first phase provides two alternatives:
  - D1: Use the existing approach of expressing data transformation
pipeline as hybrid block, and use operators for transformations to achieve
portability. Extend operators for performance and usability.
  - D2 (called alternative approach 1 in the proposal): Extend the model
export API to express the concept of auxiliary graphs in the same json
symbol file.

First on D2, the proposed addition of auxiliary graph seems neither
sufficient on itself, nor necessary. This is because this additional field
relies on operators and symbolic interface of mxnet. If one can use
HybridBlock to express the data preprocessing logic, this HybridBlock can
already, without the addition of the field, be easily exported and then
imported as a separate symbol from the model symbol, and used in other
language bindings for data preprocessing. On the other hand, if the logic
cannot be expressed as HybridBlock, then you still wouldn't be able to put
that in the auxiliary graph field anyway.

For D1, extending the image operators and rely on them for portability is
definitely the right direction and the shortest path. Since this approach
comes from GluonCV and is already available as part of the export helper
[1], there's nothing new to review on the approach.

On the specific PRs listed as part of D1:
- It is great to see that stu1130@ is implementing resize, center_crop, and
crop operators from scratch [2][3][4]. These features have long been
desired, kudos!
- It is very nice to see the GPU and batch support being added in to_tensor
and normalize operator PRs [5][6] that sandeep-krishnamurthy@ is working
on. Some minor issues:
  - These PRs seem to assume that these are not yet operators. But they
certainly are.
  - As a result of this assumption, they move the existing code to new
files. Generally we should minimize such no-op change as it causes trouble
in viewing the edit history, and do so only when absolutely necessary.
(and call for review to the community: if you love CV, help on these PRs is
much appreciated)

Finally, I have a suggestion on the review request. This proposal lists a
plan of four phases while only providing designs for the first one. In this
case, unless you have solutions to address them for the community to
review, the wishful future phases may be better suited for a separate
roadmap discussion. As I spent quite some time going through the proposal
but found little new approach to review, I'd suggest not mixing them in a
design proposal or review request next time.

Hope it helps.

-sz

[1]
https://github.com/dmlc/gluon-cv/blob/master/gluoncv/utils/export_helper.py
[2] https://github.com/apache/incubator-mxnet/pull/13611/files
[3] https://github.com/apache/incubator-mxnet/pull/13694/files
[4] https://github.com/apache/incubator-mxnet/pull/13679/files
[5] https://github.com/apache/incubator-mxnet/pull/13837/files
[6] https://github.com/apache/incubator-mxnet/pull/13802/files


On Wed, Jan 16, 2019 at 4:47 PM sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> Hello Community,
>
> Me along with fellow MXNet contributors (Jake  >,
> Karan ) are working on the following
> problem:
> 1. Some of the data transformations used in training is applicable during
> inference. Most commonly transformations on validation data is same as
> transformations required during inference.
> 2. MXNet models do not contain data transformations as part of the graph.
> Making it harder, time consuming and duplicated effort to re create data
> transformation during inference. This problem is more evident in cross
> language use cases. Training in Gluon (Python) and inference in Java/C++.
>
> After few initial discussions with some of MXNet contributors (Zhi
> , Naveen , Sina
> ), design proposal, development plan, tasks,
> milestones and more details are captured in this document.
> https://cwiki.apache.org/confluence/display/MXNET/MXNet+end+to+end+models
>
> Please do provide your feedback via comments in the document or on this
> e-mail. All contributions are welcome. I will be creating JIRA stories and
> issues for initial tasks identified.
>
> --
> Sandeep Krishnamurthy
>


Design proposal - MXNet end to end models - Models with data transformations

2019-01-16 Thread sandeep krishnamurthy
Hello Community,

Me along with fellow MXNet contributors (Jake ,
Karan ) are working on the following problem:
1. Some of the data transformations used in training is applicable during
inference. Most commonly transformations on validation data is same as
transformations required during inference.
2. MXNet models do not contain data transformations as part of the graph.
Making it harder, time consuming and duplicated effort to re create data
transformation during inference. This problem is more evident in cross
language use cases. Training in Gluon (Python) and inference in Java/C++.

After few initial discussions with some of MXNet contributors (Zhi
, Naveen , Sina
), design proposal, development plan, tasks,
milestones and more details are captured in this document.
https://cwiki.apache.org/confluence/display/MXNET/MXNet+end+to+end+models

Please do provide your feedback via comments in the document or on this
e-mail. All contributions are welcome. I will be creating JIRA stories and
issues for initial tasks identified.

-- 
Sandeep Krishnamurthy


Re: Questions about MXNet Incubation

2019-01-16 Thread Bob Paulin
Hi Carin,

These are really good answers.  Comments inline.

- Bob

On 1/16/2019 5:01 PM, Carin Meier wrote:
> I was a guest on a podcast the other day talking about MXNet and I got
> asked some questions about what it meant for MXNet to be in the incubator.
> I tried to answer them the best I could, but I wasn't too sure if my
> responses were right.
>
> I thought I would ask them here so that I can be more informed the next
> time someone asks.
>
> *What does it mean that MXNet is incubating?*
> (I said that it is the process by which all new projects come through the
> Apache project. It gives the project time to have a Apache deploy process,
> all the licenses compatible, and the community time to form in the ASF way)
Correct
>
> *What will happen when it graduates?*
> I said it will be a top-level project. Is this true?
Correct, sometimes projects fall under other Top-Level Projects but that
is an exception rather than the rule.
>
> *Where is it in the incubator process?*
> I said it is in the community building phase.

Couple of ways to answer this.

There's the formal process: https://incubator.apache.org/policy/process.html

But I think the Graduation Guide provides more details:
https://incubator.apache.org/guides/graduation.html

>
> This questions wasn't asked but I would like to know the answer so I can
> speak to it.
>
> *What are the benefits of graduation for the project and our end users?*
This is one of those: "It's more about the Journey than the end
destination."  Projects that complete incubation have demonstrated that
they meet a certain bar.  And while that by no means guarantee eternal
success it does mean that you have met the ASF standard for exit which
is not easy.  It means that going forward a report will be submitted to
the board describing how your project is doing that end users will be
able to read.  This is beyond "How many stars or downloads per month"
type of stats that let your user community know you're not going away
anytime soon.  One of the criticisms I often hear of the ASF is that
projects just don't die (usually around some project that they believe
is old or should be deprecated).   To me this is a feature since as long
as people care about the project it can live as long as it wants.
>
> Thanks for any feedback,
> Carin
>


signature.asc
Description: OpenPGP digital signature


Questions about MXNet Incubation

2019-01-16 Thread Carin Meier
I was a guest on a podcast the other day talking about MXNet and I got
asked some questions about what it meant for MXNet to be in the incubator.
I tried to answer them the best I could, but I wasn't too sure if my
responses were right.

I thought I would ask them here so that I can be more informed the next
time someone asks.

*What does it mean that MXNet is incubating?*
(I said that it is the process by which all new projects come through the
Apache project. It gives the project time to have a Apache deploy process,
all the licenses compatible, and the community time to form in the ASF way)

*What will happen when it graduates?*
I said it will be a top-level project. Is this true?

*Where is it in the incubator process?*
I said it is in the community building phase.

This questions wasn't asked but I would like to know the answer so I can
speak to it.

*What are the benefits of graduation for the project and our end users?*

Thanks for any feedback,
Carin


Re: Question about notification on nightly test failures

2019-01-16 Thread Carin Meier
The Clojure package now has turned the examples into integration tests that
we would like to have CI run. It takes about 15 min for them to complete.

We have a PR in progress
https://github.com/apache/incubator-mxnet/pull/13624

I would like to propose that we run these as part of the regular CI until
the notifications for nightly builds get implemented. We will run on a
whitelist or have an exclude list so that any problematic tests can be
disabled if needed.

Please let me know any feedback on this or concerns.

Thanks,
Carin


On Tue, Jan 15, 2019 at 12:24 PM Pedro Larroy 
wrote:

> Why don't we enable a slack notifier?  I think it would be useful to
> interact with notifications from slack directly, including the label
> bot for example.
>
> Pedro.
>
> On Sun, Jan 13, 2019 at 1:55 AM Carin Meier  wrote:
> >
> > Thanks for the explanation Marco :)
> >
> > - Carin
> >
> > On Sat, Jan 12, 2019 at 7:43 PM Marco de Abreu 
> > wrote:
> >
> > > Hi Carin,
> > >
> > > thanks for thinking about adding nightly tests to clojure, I'm sure
> this
> > > will be of big benefit!
> > >
> > > You're right, the email system is in place but we basically disabled
> the
> > > service December 2017 because it was flooding the inboxes of everybody.
> > >
> > > We've been thinking about various notification methods, but were always
> > > afraid making the notifications meaningless if they come too frequently
> > > (which is WAY better now, thanks to everybody's efforts around
> stabilizing
> > > the tests!) because people would filter them.
> > >
> > > I like the idea of a specific slack channel for the notifications. Are
> > > there any alternatives the community could think of?
> > >
> > > Best regards,
> > > Marco
> > >
> > >
> > > Am Sa., 12. Jan. 2019, 10:11 hat Carin Meier 
> > > geschrieben:
> > >
> > > > The Clojure package is thinking of adding some nightly tests and I'd
> like
> > > > to understand how the notification works in case of failure.
> > > >
> > > > The code in the nightly Jenkins file
> > > >
> > > >
> > >
> https://github.com/apache/incubator-mxnet/blob/master/tests/nightly/Jenkinsfile#L135
> > > > seems to indicate that the failure is emailed. But where does this
> email
> > > > go?
> > > > If you are a contributor, do you get notified of this?
> > > >
> > > > I don't remember seeing any notification of nightly failures, so I'm
> > > > wondering how this works and if there are any improvements to
> > > accessibility
> > > > that we can make, (like maybe posting it to a slack room)?
> > > >
> > > > Thanks,
> > > > Carin
> > > >
> > >
>


Re: Apache MXNet v1.4.0 release status

2019-01-16 Thread kellen sunderland
Sounds good Steffen.  I believe most of these PRs only fix functional
problems (they don't add features) and should be fairly low risk.

Update from my side:
13695: https://github.com/apache/incubator-mxnet/pull/13899 <- Already
merged, thanks Haibin!

Ready for review / merge with all tests passed:
https://github.com/apache/incubator-mxnet/pull/13898
https://github.com/apache/incubator-mxnet/pull/13900
https://github.com/apache/incubator-mxnet/pull/13897

-Kellen

On Tue, Jan 15, 2019 at 10:06 PM Steffen Rochel 
wrote:

> Kellen - thanks, please go ahead. I'm ok as long we avoid risky PR and can
> get to a stable and tested build by Friday.
>
> Best,
> Steffen
>
> On Tue, Jan 15, 2019 at 9:48 PM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > Many thanks for the license fixes and allowing some other PRs to come
> into
> > the release.
> >
> > For #13697 I've contacted the author Zhennan and let him know he can cut
> a
> > branch to v1.4.x to update any APIs that are required.
> >
> > For the other PRs listed here's some new PRs for the v1.4.x branch.
> > 13188: https://github.com/apache/incubator-mxnet/pull/13898
> > 13727: https://github.com/apache/incubator-mxnet/pull/13900
> > 13695: https://github.com/apache/incubator-mxnet/pull/13899 <- Already
> > merged, thanks Haibin!
> >
> > I'd also propose that we include this TensorRT PR which fixes inference
> > bugs and updates to a more stable commit of onnx-trt:
> > https://github.com/apache/incubator-mxnet/pull/13897
> >
> > -Kellen
> >
> > On Tue, Jan 15, 2019 at 5:57 PM Steffen Rochel 
> > wrote:
> >
> > > Hi Lin - please go ahead to integrate into 1.4.x.
> > > Steffen
> > >
> > > On Tue, Jan 15, 2019 at 4:17 PM Lin Yuan  wrote:
> > >
> > > > Hi Steffen,
> > > >
> > > > I would like to ask to include one more PR for 1.4.0.rc1:
> > > > https://github.com/apache/incubator-mxnet/pull/13845
> > > >
> > > > This PR exports exception handling API of MXNet. It is needed by
> > Horovod
> > > > with MXNet integration to elegantly throw exception at Python level
> > > rather
> > > > than a C++ abort.
> > > >
> > > > Thanks,
> > > >
> > > > Lin
> > > >
> > > >
> > > > On Tue, Jan 15, 2019 at 2:24 PM Steffen Rochel <
> > steffenroc...@gmail.com>
> > > > wrote:
> > > >
> > > > > Dear MXNet community -
> > > > > Zach & friends made good progress resolving the licensing issues.
> One
> > > > more
> > > > > PR on 1.4.x branch is expected today.
> > > > > The code freeze for 1.4.0.rc1 is Thursday Jan 17th 6pm PST.
> > > > > I'm asking the requester to add following PR to 1.4.x branch:
> > > > > Tao:
> > > > > https://github.com/apache/incubator-mxnet/pull/13882
> > > > > Kellen:
> > > > > https://github.com/apache/incubator-mxnet/pull/13697
> > > > > https://github.com/apache/incubator-mxnet/pull/13188
> > > > > https://github.com/apache/incubator-mxnet/pull/13727
> > > > > https://github.com/apache/incubator-mxnet/pull/13695
> > > > > Pedro:
> > > > > https://github.com/apache/incubator-mxnet/pull/13535
> > > > >
> > > > > If there are additional PR to be considered for 1.4.0.rc1 please
> send
> > > > > request to dev@.
> > > > >
> > > > > Regards,
> > > > > Steffen
> > > > >
> > > > > On Tue, Jan 8, 2019 at 11:28 AM Qing Lan 
> > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I added a section F in the document that explained the current
> > > > > > static-linked dependencies we used for official release. As there
> > > are a
> > > > > few
> > > > > > licenses are under BSD3 and GPL, we need to handle them in our
> next
> > > > > > release. Please take a look and leave any concerns you may have.
> > > > > >
> > > > > > Thanks,
> > > > > > Qing
> > > > > >
> > > > > > On 1/7/19, 8:33 PM, "kellen sunderland" <
> > > kellen.sunderl...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > So I see two quick options that should cut down on the
> > dependency
> > > > > > licenses
> > > > > > required for TRT in the source release.
> > > > > >
> > > > > > 1: We can simply remove in the release package the submodules
> > for
> > > > > onnx
> > > > > > in
> > > > > > folder
> > > > > >
> > incubator-mxnet/3rdparty/onnx-tensorrt/third_party/onnx/third_party.
> > > > > > None of those dependencies are used in the build (I've just
> > > > verified
> > > > > > locally on my machine).
> > > > > > 2: We can make a cmake based checkout system and ensure we
> only
> > > > > > checkout
> > > > > > the required files when TRT builds are enabled (similar to
> the
> > > > > current
> > > > > > mkl-ml setup).
> > > > > >
> > > > > > I'd suggest option 1 for this release, and that we support
> > > option 2
> > > > > > for the
> > > > > > 1.5 release.
> > > > > >
> > > > > > On Mon, Jan 7, 2019 at 8:19 PM Lv, Tao A  >
> > > > wrote:
> > > > > >
> > > > > > > What should I do for the double headers in
> > > > > > 3rdparty/mkldnn/src/cpu/xbyak/?
> > > > > > >
> > > > > > > -tao
> > > > > > >
> > > >