Re: [VOTE] Change Scala namespace from dmlc to org.apache

[Suneel Marthi]

The namespace change is the first thing that's done for most projects that
come to apache incubation

How many production deployments of MXNet Scala API are out there --- 3 ?  2
?  1.7643 ?
I would think its barely a handful of them.

Agree with Christopher Barber that MXNEt jumped the gun with 1.0 and its
best now to suck up a breaking change.

+1 binding

On Tue, Mar 13, 2018 at 12:26 PM, Chris Olivier 
wrote:

> I'm not taking a side here, but just please consider that if you have two
> separate implementations for awhile, the newer one will start to diverge
> and over time, it will become harder and harder for the user to port his
> code.  You may find yourself supporting the old code for much longer than
> you anticipated (especially if changed go into the old implementation).
>
> On Tue, Mar 13, 2018 at 9:11 AM, Barber, Christopher <
> christopher.bar...@analog.com> wrote:
>
> > Personally, I believe that MXNet jumped the gun on 1.0. It is pretty
> clear
> > that the API is still not entirely stable.
> >
> > Given that, I would just go with the incompatible change rather than suck
> > up a lot of your development time building and supporting bridges and
> > facades and potentially introducing new bugs as a result. As an
> > alternative, you could just support two independent implementations using
> > the two namespaces for some period of time until people can switch to the
> > new one. It's not like it will be that difficult for customer's to port
> > their code.
> >
> > But really this is up to the Scala maintainers to decide what they want
> to
> > do.
> >
> > On 3/13/18, 12:01 PM, "kellen sunderland" 
> > wrote:
> >
> > Maintaining backwards compatibility never results in the prettiest
> > code,
> > but it seems pretty desirable here.  There are relatively few files
> > here,
> > so I agree there's some risk but I don't think it would take too much
> > time.  Feel free to suggest alternatives Christopher.
> >
> > On Tue, Mar 13, 2018 at 4:56 PM, Barber, Christopher <
> > christopher.bar...@analog.com> wrote:
> >
> > > That sounds like a lot of work and it would be easy to get wrong if
> > it is
> > > even feasible.
> > >
> > > On 3/13/18, 11:51 AM, "kellen sunderland" <
> > kellen.sunderl...@gmail.com>
> > > wrote:
> > >
> > > I don't know about aliasing a namespace in Scala, but I wonder
> > how
> > > hard it
> > > would be to either (1) provide a fascade from the new package
> to
> > the
> > > old
> > > package or (2) keep two copies of the scala code temporarily
> > along
> > > with two
> > > copies of the JNI entry points.  In both of these cases we
> could
> > setup
> > > @deprecated on all public calls to the old package.
> > >
> > > On Tue, Mar 13, 2018 at 4:47 PM, Nan Zhu <
> zhunanmcg...@gmail.com
> > >
> > > wrote:
> > >
> > > > re Chris: I do not have any good idea about this.
> > > >
> > > > On Tue, Mar 13, 2018 at 8:13 AM, Chris Olivier <
> > > cjolivie...@gmail.com>
> > > > wrote:
> > > >
> > > > > is it possible to somehow alias a namespace in scala
> > > > > in order to maintain backwards compatibility?
> > > > >
> > > > > On Tue, Mar 13, 2018 at 7:21 AM Nan Zhu <
> > zhunanmcg...@gmail.com>
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > and additional suggestion is do it ASAP
> > > > > >
> > > > > > On Mon, Mar 12, 2018 at 11:21 PM, Chris Olivier <
> > > cjolivie...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > not sure I understand. How could changing a java
> > namespace
> > > > (effectively
> > > > > > > moving the files to a different location as well as
> > changing
> > > the
> > > > > package
> > > > > > > names) be backward-compatible?
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Mar 12, 2018 at 11:02 PM Steffen Rochel <
> > > > > steffenroc...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I suggest the vote should call out if the change is
> > breaking
> > > > backward
> > > > > > > > compatibility or not.
> > > > > > > > I looked through the scala name changing thread and
> > don't see
> > > > > > > justification
> > > > > > > > for a backward incompatible change.
> > > > > > > > I do agree it would be good to change the name space,
> > but
> > > have not
> > > > > > seen a
> > > > > > > > reason why the change has to be made now in backward
> > > incompatible
> > > > > way.
> > > > > > > > Non-binding vote:
> > > > > > > > +1 for backward compatible namespace change
> > >  

Re: [VOTE] tracking code changes with JIRA by associating pull requests

[Suneel Marthi]

On Tue, Feb 27, 2018 at 10:50 PM, Nan Zhu <zhunanmcg...@gmail.com> wrote:

> Thanks, Suneel!
>
> the vote still remains sense on its major points
>
> "
> 1. most of PRs should be titled as [MXNET-???][MODULE_NAME] PR short
> description, where MXNET-??? is the JIRA ID, MODULE_NAME can be python,
> scala, symbol, etc.
>

Any reason u need the [MODULE_NAME] in there - I would -1 that

[MXNET-XYZ] is unique enuf to identify the specific module - not to mention
that the different modules can be setup to label each jira - so
[MODULE-blah] is unnecessary.


> 2. only the very tiny fix, e.g. fix a typo, remove some unused variables,
> or the hotfix which brings the broken build back to track, can be filed
> without JIRA ID in title,
>

Agreed - and in this case the convention has been to use [NO-JIRA] in title.

> "
>
> though we do not need additional efforts to make it happen,
>
> the only thing we need to get a consensus on is that, we need to use JIRA
> to track work items and title PRs with JIRA ids
>

What ??? elaborate please??

>
> Hi, all, a friendly reminder, the vote will be ended at 12:00 p.m. on this
> Friday
>
>
> Best,
>
> Nan
>
>
>
> On Tue, Feb 27, 2018 at 1:44 PM, Suneel Marthi <smar...@apache.org> wrote:
>
> > Suggest you see how other projects are doing it - Flink, Kafka or any
> other
> > project.
> >
> > Yes u r right.
> >
> > When u make a github PR with PR label in title like [Flink-3456] for eg:
> -
> > that way the corresponding JIRA - Flink-3456 here would be automatically
> > updated.
> >
> > On Tue, Feb 27, 2018 at 10:28 PM, Nan Zhu <zhunanmcg...@gmail.com>
> wrote:
> >
> > > Hi, Suneel,
> > >
> > > how can we enable it? when we titled JIRA id in pull request, it will
> > > synchronized automatically?
> > >
> > > Best,
> > >
> > > Nan
> > >
> > > On Tue, Feb 27, 2018 at 1:23 PM, Suneel Marthi <smar...@apache.org>
> > wrote:
> > >
> > > > All projects on Apache have Jira <---> Github integration in place.
> > > >
> > > > So its a solved problem - look at Flink, Kafka, Mahout, OpenNLP,
> > > > PredictionIO and every other Apache project - all of them have this
> > > > working.
> > > >
> > > >
> > > >
> > > > On Tue, Feb 27, 2018 at 8:35 PM, Steffen Rochel <
> > steffenroc...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Nan - have you looked at plugin's to make the integration and
> > > > > synchronization between Jira and github easier? E.g.
> > > > > https://www.atlassian.com/blog/jira-software/connecting-
> > > jira-6-2-github
> > > > f
> > > > > Ideally one has one button in github to create a Jira and
> afterwards
> > > > > changes on either github or Jira get synchronized.
> > > > > What tools is ASF infra recommending?
> > > > > Have you used
> > > > > https://github.com/apache/spark/blob/master/dev/github_jira_
> sync.py
> > > and
> > > > > what is the recommended use case? How do get github issues updated
> > from
> > > > > Jira?
> > > > >
> > > > > Steffen
> > > > >
> > > > > On Tue, Feb 27, 2018 at 10:31 AM Indhu <indhubhara...@gmail.com>
> > > wrote:
> > > > >
> > > > > > +1 to the proposal
> > > > > >
> > > > > >
> > > > > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zhunanmcg...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > ideally,
> > > > > > >
> > > > > > > users report something fishy in github issue
> > > > > > >
> > > > > > > when confirmed that it is a bug or something to be improved, we
> > > > should
> > > > > > > create JIRAs
> > > > > > >
> > > > > > > On Sun, Feb 25, 2018 at 9:31 AM, Chris Olivier <
> > > > cjolivie...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > i believe that JIRAs are “work items@, while github issues
> are
> > > > more
> > > > > > like
> > > > > > > > reporting. at least this is what Infra sort of claimed.
> > > > > > > >
> > > 

Re: [VOTE] tracking code changes with JIRA by associating pull requests

[Suneel Marthi]

Suggest you see how other projects are doing it - Flink, Kafka or any other
project.

Yes u r right.

When u make a github PR with PR label in title like [Flink-3456] for eg: -
that way the corresponding JIRA - Flink-3456 here would be automatically
updated.

On Tue, Feb 27, 2018 at 10:28 PM, Nan Zhu <zhunanmcg...@gmail.com> wrote:

> Hi, Suneel,
>
> how can we enable it? when we titled JIRA id in pull request, it will
> synchronized automatically?
>
> Best,
>
> Nan
>
> On Tue, Feb 27, 2018 at 1:23 PM, Suneel Marthi <smar...@apache.org> wrote:
>
> > All projects on Apache have Jira <---> Github integration in place.
> >
> > So its a solved problem - look at Flink, Kafka, Mahout, OpenNLP,
> > PredictionIO and every other Apache project - all of them have this
> > working.
> >
> >
> >
> > On Tue, Feb 27, 2018 at 8:35 PM, Steffen Rochel <steffenroc...@gmail.com
> >
> > wrote:
> >
> > > Nan - have you looked at plugin's to make the integration and
> > > synchronization between Jira and github easier? E.g.
> > > https://www.atlassian.com/blog/jira-software/connecting-
> jira-6-2-github
> > f
> > > Ideally one has one button in github to create a Jira and afterwards
> > > changes on either github or Jira get synchronized.
> > > What tools is ASF infra recommending?
> > > Have you used
> > > https://github.com/apache/spark/blob/master/dev/github_jira_sync.py
> and
> > > what is the recommended use case? How do get github issues updated from
> > > Jira?
> > >
> > > Steffen
> > >
> > > On Tue, Feb 27, 2018 at 10:31 AM Indhu <indhubhara...@gmail.com>
> wrote:
> > >
> > > > +1 to the proposal
> > > >
> > > >
> > > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zhunanmcg...@gmail.com>
> wrote:
> > > >
> > > > > ideally,
> > > > >
> > > > > users report something fishy in github issue
> > > > >
> > > > > when confirmed that it is a bug or something to be improved, we
> > should
> > > > > create JIRAs
> > > > >
> > > > > On Sun, Feb 25, 2018 at 9:31 AM, Chris Olivier <
> > cjolivie...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > i believe that JIRAs are “work items@, while github issues are
> > more
> > > > like
> > > > > > reporting. at least this is what Infra sort of claimed.
> > > > > >
> > > > > > On Sun, Feb 25, 2018 at 9:30 AM Chris Olivier <
> > cjolivie...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Feb 23, 2018 at 9:56 AM Marco de Abreu <
> > > > > > > marco.g.ab...@googlemail.com> wrote:
> > > > > > >
> > > > > > >> Hello Nan,
> > > > > > >>
> > > > > > >> Good suggestion!
> > > > > > >>
> > > > > > >> "hotfix which brings the broken build back to track"
> nitpicking,
> > > > but I
> > > > > > >> wouldn't consider this a tiny fix. There should also be a jira
> > > that
> > > > > > >> reported the build being broken, so that shouldn't be a
> problem
> > to
> > > > > link.
> > > > > > >>
> > > > > > >> Very good idea with the automated script!
> > > > > > >>
> > > > > > >> How would we handle permissions? Which actions are
> > non-committers
> > > > able
> > > > > > to
> > > > > > >> execute and in which cases would a committer be required?
> > > > > > >>
> > > > > > >> How would we treat GitHub issues in future? As a board for
> users
> > > to
> > > > > ask
> > > > > > >> usage questions?
> > > > > > >>
> > > > > > >> In order to improve user experience for new developers, I'd
> like
> > > to
> > > > > > >> suggest
> > > > > > >> that more experienced people might create jira tickets on
> behalf
> > > of
> > > > > > others
> > > > > 

Re: [VOTE] tracking code changes with JIRA by associating pull requests

[Suneel Marthi]

All projects on Apache have Jira <---> Github integration in place.

So its a solved problem - look at Flink, Kafka, Mahout, OpenNLP,
PredictionIO and every other Apache project - all of them have this working.



On Tue, Feb 27, 2018 at 8:35 PM, Steffen Rochel 
wrote:

> Nan - have you looked at plugin's to make the integration and
> synchronization between Jira and github easier? E.g.
> https://www.atlassian.com/blog/jira-software/connecting-jira-6-2-github f
> Ideally one has one button in github to create a Jira and afterwards
> changes on either github or Jira get synchronized.
> What tools is ASF infra recommending?
> Have you used
> https://github.com/apache/spark/blob/master/dev/github_jira_sync.py and
> what is the recommended use case? How do get github issues updated from
> Jira?
>
> Steffen
>
> On Tue, Feb 27, 2018 at 10:31 AM Indhu  wrote:
>
> > +1 to the proposal
> >
> >
> > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu  wrote:
> >
> > > ideally,
> > >
> > > users report something fishy in github issue
> > >
> > > when confirmed that it is a bug or something to be improved, we should
> > > create JIRAs
> > >
> > > On Sun, Feb 25, 2018 at 9:31 AM, Chris Olivier 
> > > wrote:
> > >
> > > > i believe that JIRAs are “work items@, while github issues are more
> > like
> > > > reporting. at least this is what Infra sort of claimed.
> > > >
> > > > On Sun, Feb 25, 2018 at 9:30 AM Chris Olivier  >
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > >
> > > > > On Fri, Feb 23, 2018 at 9:56 AM Marco de Abreu <
> > > > > marco.g.ab...@googlemail.com> wrote:
> > > > >
> > > > >> Hello Nan,
> > > > >>
> > > > >> Good suggestion!
> > > > >>
> > > > >> "hotfix which brings the broken build back to track" nitpicking,
> > but I
> > > > >> wouldn't consider this a tiny fix. There should also be a jira
> that
> > > > >> reported the build being broken, so that shouldn't be a problem to
> > > link.
> > > > >>
> > > > >> Very good idea with the automated script!
> > > > >>
> > > > >> How would we handle permissions? Which actions are non-committers
> > able
> > > > to
> > > > >> execute and in which cases would a committer be required?
> > > > >>
> > > > >> How would we treat GitHub issues in future? As a board for users
> to
> > > ask
> > > > >> usage questions?
> > > > >>
> > > > >> In order to improve user experience for new developers, I'd like
> to
> > > > >> suggest
> > > > >> that more experienced people might create jira tickets on behalf
> of
> > > > others
> > > > >> instead of telling them "please create a ticket". I think we all
> > made
> > > > the
> > > > >> experience with people from it department who blocked every
> request
> > > > until
> > > > >> a
> > > > >> ticket was created and assigned :P
> > > > >>
> > > > >> Best regards,
> > > > >> Marco
> > > > >>
> > > > >> Am 23.02.2018 6:07 nachm. schrieb "CodingCat" <
> coding...@apache.org
> > >:
> > > > >>
> > > > >> Hi, all
> > > > >>
> > > > >> To make the changes in code base more trackable,
> > > > >>
> > > > >> I would propose to link each PR with the a JIRA from now on:
> > > > >>
> > > > >> 1. most of PRs should be titled as [MXNET-???][MODULE_NAME] PR
> short
> > > > >> description, where MXNET-??? is the JIRA ID, MODULE_NAME can be
> > > python,
> > > > >> scala, symbol, etc.
> > > > >>
> > > > >> 2. only the very tiny fix, e.g. fix a typo, remove some unused
> > > > variables,
> > > > >> or the hotfix which brings the broken build back to track, can be
> > > filed
> > > > >> without JIRA ID in title,
> > > > >>
> > > > >> In JIRA side, to link the issue with an arrived PR, we can run a
> > > script
> > > > >> like https://github.com/apache/spark/blob/master/dev/github_
> > > > jira_sync.py
> > > > >> to
> > > > >> update JIRA status (can be run in Jenkins)
> > > > >>
> > > > >>
> > > > >> The benefits of applying such a flow include (but not limited to)
> > > > >>
> > > > >> 1. facilitate the release process:
> > > > >>
> > > > >> e.g., as long as tagging each JIRA with the correct affected
> version
> > > and
> > > > >> fixed version, the release manager can quickly identify what are
> the
> > > > >> changes applied in this version; or we can quickly identify
> whether
> > > > there
> > > > >> is any blocker issue in the JIRA
> > > > >>
> > > > >> 2. trackable changes
> > > > >>
> > > > >> any changes in MXNET can be quickly searched through JIRA or even
> > > > through
> > > > >> Google (JIRA looks like did something makes it more indexable by
> > > > Google),
> > > > >>
> > > > >>
> > > > >> If the vote gets pass,  the plan in the near horizon includes
> > > > >>
> > > > >> 1. update JIRA with the modules names
> > > > >>
> > > > >> 2. write runbook for release manager/committer for releasing new
> > > > >> version/merging patches, as well as contributors about the usage
> of
> > > JIRA
> > > > >>
> > > > >> 3. push the 

Re: Design Proposal: Logging MXNet Data for Visualization in TensorBoard

[Suneel Marthi]

Good doc Jun!! Mind sharing a Google Doc with that content - easier to
comment on or make changes that way -  and the finalized doc can be posted
back to the Wiki.

thanks again

On Fri, Feb 9, 2018 at 5:57 PM, Jun Wu  wrote:

> Hi All,
>
> We have drafted a design proposal of making a data logger in MXNet Python
> package for visualizing MXNet data in TensorFlow's TensorBoard. Please feel
> free to let us know your comments, suggestions, and corrections on the
> proposal. Thank you very much for your time and consideration.
>
> https://cwiki.apache.org/confluence/display/MXNET/Logging+MXNet+Data+for+
> Visualization+in+TensorBoard
>
> Note: I'll be traveling during the next three weeks. Response to the
> feedbacks/questions might be delayed. I appreciate your understanding.
>
> Best regards,
> Jun
>

Re: JIRA notifications on dev@

[Suneel Marthi]

Most projects have their Jira setup to go to commits@.
apache.org

file an infra ticket to make that change for MxNet

On Wed, Feb 7, 2018 at 12:17 PM, Hen  wrote:

> The typical approach is to have them sent to a notifications list (along
> with CI etc).
>
> Normally that still redirects to dev iirc.
>
> On Wed, Feb 7, 2018 at 03:24 kellen sunderland <
> kellen.sunderl...@gmail.com>
> wrote:
>
> > +1
> >
> > On Feb 7, 2018 2:49 AM, "Marco de Abreu" 
> > wrote:
> >
> > > Lol, at least Link this thread please to show that the community
> actually
> > > wants this.
> > >
> > > -Marco
> > >
> > > Am 06.02.2018 5:29 nachm. schrieb "Chris Olivier" <
> cjolivie...@gmail.com
> > >:
> > >
> > > > I opened a ticket anyway.  Meh.
> > > >
> > > > On Tue, Feb 6, 2018 at 5:05 PM, Marco de Abreu <
> > > > marco.g.ab...@googlemail.com
> > > > > wrote:
> > > >
> > > > > Haha, we need to have a discussion here first before we can make
> the
> > > > > change. I'd like the opinion of the community on this one.
> > > > >
> > > > > -Marco
> > > > >
> > > > > On Tue, Feb 6, 2018 at 5:04 PM, Chris Olivier <
> cjolivie...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Please feel free to submit a ticket to Infra to get the emails
> > > > disabled.
> > > > > >
> > > > > > Oh yeah...  If we do that, they send us nasty emails...
> > > > > >
> > > > > > Waiting for Sebastian to file a ticket (I pinged on Slack).
> > > > > >
> > > > > >
> > > > > > On Tue, Feb 6, 2018 at 5:00 PM, Marco de Abreu <
> > > > > > marco.g.ab...@googlemail.com
> > > > > > > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > while I highly appreciate the usage of JIRA within MXNet, I
> guess
> > > > that
> > > > > > I'm
> > > > > > > not the only one bothered by the high number of JIRA
> > notifications
> > > on
> > > > > > dev@
> > > > > > > .
> > > > > > > While everybody has the chance to create a filter for these
> > > message,
> > > > > I'm
> > > > > > > afraid that new developers and people viewing the archive are
> > > getting
> > > > > > > pretty frustrated as actual conversations are pushed to the
> side
> > by
> > > > all
> > > > > > the
> > > > > > > communication happening on the JIRA tickets (see [1]).
> Therefor,
> > > I'd
> > > > > > > propose one of the following solutions:
> > > > > > >
> > > > > > > 1. Disable JIRA notifications to dev@ entirely, leading to
> only
> > > the
> > > > > > people
> > > > > > > subscribed to a ticket being notified directly.
> > > > > > > 2. Create a separate email list for JIRA in the same way as
> [2].
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Marco
> > > > > > >
> > > > > > > [1]: https://lists.apache.org/list.html?d...@mxnet.apache.org
> > > > > > > [2]: https://lists.apache.org/list.
> html?comm...@mxnet.apache.org
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Refactoring MXNet scala code to use "org.apache.mxnet"

[Suneel Marthi]

Jira has been around for a while -
https://issues.apache.org/jira/projects/MXNET/

switch to using jira

On Thu, Jan 4, 2018 at 7:31 PM, Roshani Nagmote <roshaninagmo...@gmail.com>
wrote:

>  Hi,
>
> As currently, MXNet does not have Jira project, I have created github issue
> for now.
> https://github.com/apache/incubator-mxnet/issues/9315
>
> Will create the PR and link the issue there.
>
> Thanks,
> Roshani
>
> On Thu, Jan 4, 2018 at 3:08 PM, Naveen Swamy <mnnav...@gmail.com> wrote:
>
> > Hi Suneel,
> >
> > Did we decide that we will using Jira going forward? If not, can someone
> > summarize on the improvement email on the consensus and lets make it
> > universal and how to use it, what is expected, etc.,
> >
> > For the record, I like the idea of using Jira for more openness.
> >
> > Also, MXNet does not have Jira project, can you help creating one?
> >
> > Thanks, Naveen
> >
> >
> > On Thu, Jan 4, 2018 at 2:35 PM, Suneel Marthi <smar...@apache.org>
> wrote:
> >
> > > Is there a Jira for this? Please create a Jira and reference that in
> the
> > PR
> > > for this.
> > >
> > > On Thu, Jan 4, 2018 at 5:16 PM, Roshani Nagmote <
> > roshaninagmo...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > I am working on publishing mxnet-scala release to maven repository
> and
> > > as a
> > > > part of that, I will also be refactoring mxnet-scala
> code/tests/example
> > > and
> > > > docs to use "org.apache.mxnet" instead of "ml.dmlc.mxnet".
> > > >
> > > > Currently, MXNet-Scala
> > > > <http://mxnet.incubator.apache.org/api/scala/index.html> library
> uses
> > > > "ml.dmlc.mxnet" packages. This work will change the way to import
> > modules
> > > > when using mxnet-scala package.
> > > >
> > > > *Old way:*
> > > >
> > > > scala> import ml.dmlc.mxnet._
> > > >import ml.dmlc.mxnet._scala> val arr = NDArray.ones(2, 3)
> > > >arr: ml.dmlc.mxnet.NDArray = ml.dmlc.mxnet.NDArray@f5e74790
> > > >
> > > > *New way:*
> > > >
> > > > scala> import org.apache.mxnet._
> > > >import org.apache.mxnet._
> > > > scala> val arr = NDArray.ones(2, 3)
> > > >arr: org.apache.mxnet.NDArray = org.apache.mxnet.NDArray@f5e74790
> > > >
> > > >
> > > > Please let me know if anyone has any thoughts or issues with this
> > change.
> > > >
> > > > Thanks,
> > > > Roshani
> > > >
> > >
> >
>

Re: Refactoring MXNet scala code to use "org.apache.mxnet"

[Suneel Marthi]

Is there a Jira for this? Please create a Jira and reference that in the PR
for this.

On Thu, Jan 4, 2018 at 5:16 PM, Roshani Nagmote 
wrote:

> Hello all,
>
> I am working on publishing mxnet-scala release to maven repository and as a
> part of that, I will also be refactoring mxnet-scala code/tests/example and
> docs to use "org.apache.mxnet" instead of "ml.dmlc.mxnet".
>
> Currently, MXNet-Scala
>  library uses
> "ml.dmlc.mxnet" packages. This work will change the way to import modules
> when using mxnet-scala package.
>
> *Old way:*
>
> scala> import ml.dmlc.mxnet._
>import ml.dmlc.mxnet._scala> val arr = NDArray.ones(2, 3)
>arr: ml.dmlc.mxnet.NDArray = ml.dmlc.mxnet.NDArray@f5e74790
>
> *New way:*
>
> scala> import org.apache.mxnet._
>import org.apache.mxnet._
> scala> val arr = NDArray.ones(2, 3)
>arr: org.apache.mxnet.NDArray = org.apache.mxnet.NDArray@f5e74790
>
>
> Please let me know if anyone has any thoughts or issues with this change.
>
> Thanks,
> Roshani
>

Re: Podling Report Reminder - January 2018

[Suneel Marthi]

We also need to address the recent Security fix in this report - was a CVE
filed for the issue ?

On Sun, Dec 31, 2017 at 12:39 AM, Suk Won Kim  wrote:

> Hi all,
> Bhavin Thaker and I propose the attached podling report draft and would
> like your review comments and contributions to the report by 02-Jan, 2018,
> since the report is due on 03-Jan, 2018. Mentors, please signoff this draft
> via email by 1/2/2018 since we plan to submit the report by 1/3.
>
> Please find the draft below.
> https://docs.google.com/document/d/1PGhs96klZB6DXhpK9_
> biPh4-aCm8-bWwFzexnOW_GMA/edit
>
>
>
>
> On Sat, Dec 30, 2017 at 6:30 AM,  wrote:
>
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 17 January 2018, 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, January 03).
> >
> > 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.
> >
> > 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://wiki.apache.org/incubator/January2018
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > 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
> >
>
>
>
> --
> *Sukwon Kim*
>

Re: Podling Report Reminder - January 2018

[Suneel Marthi]

Report's been filed - mentors please comment and sign-off

On Sun, Dec 31, 2017 at 12:42 PM, Suneel Marthi <smar...@apache.org> wrote:

> I'll post the report to Incubator Wiki sometime today - mentors can then
> sign off.
>
> On Sun, Dec 31, 2017 at 12:38 PM, Markus Weimer <mar...@weimo.de> wrote:
>
>> Thanks for putting this together! I made a pass and left one comment.
>> Besides that, it looks good to me and documents immense progress. Great
>> job
>> :)
>>
>> Regarding the timeline for mentor sign-off, this is challenging.
>>
>> I believe the way that I sign off on the report is to log into the
>> incubator wiki and adding an `x` at the right spot. It isn't enough for
>> you
>> to copy & paste that from the Google doc.
>>
>> The timeline set here gives exactly 1 day for us to do that, which
>> $DAY_JOB
>> might make challenging. I should be able to make it this time, but can't
>> really promise that in the future. Any chance we can get this into the
>> wiki
>> earlier in the future?
>>
>> Thanks!
>>
>> Markus
>>
>> On Sat, Dec 30, 2017 at 9:39 PM, Suk Won Kim <kim.suk...@gmail.com>
>> wrote:
>>
>> > Hi all,
>> > Bhavin Thaker and I propose the attached podling report draft and would
>> > like your review comments and contributions to the report by 02-Jan,
>> 2018,
>> > since the report is due on 03-Jan, 2018. Mentors, please signoff this
>> draft
>> > via email by 1/2/2018 since we plan to submit the report by 1/3.
>> >
>> > Please find the draft below.
>> > https://docs.google.com/document/d/1PGhs96klZB6DXhpK9_
>> > biPh4-aCm8-bWwFzexnOW_GMA/edit
>> >
>> >
>> >
>> >
>> > On Sat, Dec 30, 2017 at 6:30 AM, <johndam...@apache.org> wrote:
>> >
>> > > Dear podling,
>> > >
>> > > This email was sent by an automated system on behalf of the Apache
>> > > Incubator PMC. It is an initial reminder to give you plenty of time to
>> > > prepare your quarterly board report.
>> > >
>> > > The board meeting is scheduled for Wed, 17 January 2018, 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, January 03).
>> > >
>> > > 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.
>> > >
>> > > 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://wiki.apache.org/incubator/January2018
>> > >
>> > > Note: This is manually populated. You may need to wait a little before
>> > > this page is created from a template.
>> > >
>> > > 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
>> > >
>> >
>> >
>> >
>> > --
>> > *Sukwon Kim*
>> >
>>
>
>

Re: Podling Report Reminder - January 2018

[Suneel Marthi]

I'll post the report to Incubator Wiki sometime today - mentors can then
sign off.

On Sun, Dec 31, 2017 at 12:38 PM, Markus Weimer  wrote:

> Thanks for putting this together! I made a pass and left one comment.
> Besides that, it looks good to me and documents immense progress. Great job
> :)
>
> Regarding the timeline for mentor sign-off, this is challenging.
>
> I believe the way that I sign off on the report is to log into the
> incubator wiki and adding an `x` at the right spot. It isn't enough for you
> to copy & paste that from the Google doc.
>
> The timeline set here gives exactly 1 day for us to do that, which $DAY_JOB
> might make challenging. I should be able to make it this time, but can't
> really promise that in the future. Any chance we can get this into the wiki
> earlier in the future?
>
> Thanks!
>
> Markus
>
> On Sat, Dec 30, 2017 at 9:39 PM, Suk Won Kim  wrote:
>
> > Hi all,
> > Bhavin Thaker and I propose the attached podling report draft and would
> > like your review comments and contributions to the report by 02-Jan,
> 2018,
> > since the report is due on 03-Jan, 2018. Mentors, please signoff this
> draft
> > via email by 1/2/2018 since we plan to submit the report by 1/3.
> >
> > Please find the draft below.
> > https://docs.google.com/document/d/1PGhs96klZB6DXhpK9_
> > biPh4-aCm8-bWwFzexnOW_GMA/edit
> >
> >
> >
> >
> > On Sat, Dec 30, 2017 at 6:30 AM,  wrote:
> >
> > > Dear podling,
> > >
> > > This email was sent by an automated system on behalf of the Apache
> > > Incubator PMC. It is an initial reminder to give you plenty of time to
> > > prepare your quarterly board report.
> > >
> > > The board meeting is scheduled for Wed, 17 January 2018, 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, January 03).
> > >
> > > 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.
> > >
> > > 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://wiki.apache.org/incubator/January2018
> > >
> > > Note: This is manually populated. You may need to wait a little before
> > > this page is created from a template.
> > >
> > > 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
> > >
> >
> >
> >
> > --
> > *Sukwon Kim*
> >
>

Re: [DISCUSSION] Adding labels to PRs

[Suneel Marthi]

When u create a Jira - the jira carries a label of 'New Feature', 'Bug',
'Task' etc..., there's no need to again label each PR individually as long
as the Jira### is referenced in the PR.



On Fri, Nov 10, 2017 at 4:13 AM, Meghna Baijal 
wrote:

> Hello All,
>
> Currently, there is no process in place to identify the new features that
> go into every release.  All the commits since the previous release are
> manually parsed to find the important changes that go into the release
> notes.
>
>
> In order to improve this process, I want to start a discussion on the
> following options -
>
> 1. *Better PR titles* - if possible, these should be good enough to be
> picked as is into the release notes.
>
> 2. *JIRA Issues* - each commit should be tagged with an associated JIRA
> issue. This issue should describe the problem. JIRA tickets can be used to
> automate the generation of release notes.
>
> 3. *Adding Labels to the PRs/Commits* - There can be a set of 3-5 labels
> such as ‘Bug-Fix’, ‘New Feature’, ‘Docs’, ‘Minor Change’ etc. Atleast those
> PRs which are important and should be included in the release notes should
> be labeled.
> However, labels can only be added by those with write access to the repo.
> So the committers will have to triage this label addition as they
> review/merge the PRs.
>
>
> Do you think these changes are feasible? Will they help? What other options
> should be considered?
>
> Thanks,
> Meghna Baijal
>

[jira] [Updated] (MXNET-1) EPIC: Create independent Jenkins Server for MXNet CI

[Suneel Marthi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MXNET-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suneel Marthi updated MXNET-1:
--
Component/s: CI Build 

> EPIC: Create independent Jenkins Server for MXNet CI
> 
>
> Key: MXNET-1
> URL: https://issues.apache.org/jira/browse/MXNET-1
> Project: Apache MXNet
>  Issue Type: New Feature
>  Components: CI Build 
>Reporter: Chris Olivier
>
> Contains subtasks for creating non-Apache CI Jenkins system



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Grant access to slack

[Suneel Marthi]

Invite sent

Sent from my iPhone

> On Nov 1, 2017, at 6:17 PM, Matthias Seeger  wrote:
> 
> Hello,
> 
> I got a few PRs merged into MXNet already (github mseeger). Could you grant
> me access to slack, and give me details on the channel?
> 
> 
> -- 
> Matthias Seeger

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Suneel Marthi]

+1

On Sat, Oct 28, 2017 at 5:29 AM, Chris Olivier 
wrote:

> IMHO, it would be nice to have Apache JIRA for mxnet where these sort of
> feature requests could be entered and publicly tracked and possibly taken
> up by whoever has cycles with the JIRA helping to avoid overlapping work.
> After the core system works, of course. WDYT?
>
> On Fri, Oct 27, 2017 at 5:30 AM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> wrote:
>
> > Just to provide a high level overview of the ideas and proposals
> > coming from different sources for the requirements for testing and
> > validation of builds:
> >
> > * Have terraform files for the testing infrastructure. Infrastructure
> > as code (IaC). Minus not emulated / nor cloud based, embedded
> > hardware. ("single command" replication of the testing infrastructure,
> > no manual steps).
> >
> > * CI software based on Jenkins, unless someone thinks there's a better
> > alternative.
> >
> > * Use autoscaling groups and improve staggered build + test steps to
> > achieve higher parallelism and shorter feedback times.
> >
> > * Switch to a branching model based on stable master + integration
> > branch. PRs are merged into dev/integration which runs extended
> > nightly tests, which are
> > then merged into master, preferably in an automated way after
> > successful extended testing.
> > Master is always tested, and always buildable. Release branches or
> > tags in master as usual for releases.
> >
> > * Build + test feedback time targeting less than 15 minutes.
> > (Currently a build in a 16x core takes 7m). This involves lot of
> > refactoring of tests, move expensive tests / big smoke tests to
> > nightlies on the integration branch, also tests on IoT devices / power
> > and performance regressions...
> >
> > * Add code coverage and other quality metrics.
> >
> > * Eliminate warnings and treat warnings as errors. We have spent time
> > tracking down "undefined behaviour" bugs that could have been caught
> > by compiler warnings.
> >
> > Is there something I'm missing or additional things that come to your
> > mind that you would wish to add?
> >
> > Pedro.
> >
>

Re: Request for suggestions- Supporting onnx in mxnet

[Suneel Marthi]

I guess the whole discussion here is about - Who is 'We' in your email ?

 'We thought there is a better way of doing this'

It may just be misinterpretation or misunderstanding amongst folks here due
to language barrier.


On Thu, Oct 19, 2017 at 3:48 PM, Tianqi Chen 
wrote:

> We thought there is a better way of doing this, by proposing nnvm as part
> of apache deep learning stack along with Mxnet. This is the reason why we
> did not simply move the repo over now
>
> Tianqi
> On Thu, Oct 19, 2017 at 12:43 PM Chris Olivier 
> wrote:
>
> > Why don't we just move all of these dmlc modules into the Apache
> repository
> > right now and have the correct discussions on dev?  What's the argument
> > against this?  IMHO, I thought that's what was going to be done
> originally.
> >
> > On Thu, Oct 19, 2017 at 12:14 PM, Tianqi Chen 
> > wrote:
> >
> > > Hi Hen:
> > >
> > > It is sad to think DMLC adversarially in this matter.  DMLC projects
> > adopt
> > > apache way of doing things and we are planning moving more modules into
> > > Apache.
> > >
> > > All the discussion so far happens under the Apache manner and I do
> think
> > > that healthy discussion on critical design issues is important. It is
> > > unfair to say something is rotten just when there is a debate going on
> in
> > > terms of technical issues.
> > >
> > > They are merely based on our technical assessment of what is better for
> > the
> > > project in general, instead of being political or chanting the detailed
> > > credits or ownership of the code.
> > >
> > >
> > > Tianqi
> > >
> > > On Thu, Oct 19, 2017 at 12:03 PM, Hen  wrote:
> > >
> > > > What I think I'm seeing here is that:
> > > >
> > > > * MXNet moved to Apache.
> > > > * Some of the code it relied on (50% per the last release thread, but
> > > that
> > > > may have been bombastic) remained at DMLC.
> > > > * The MXNet community thinks one thing.
> > > > * The DMLC community (which is a subset of the MXNet community that
> > runs
> > > > under different community rules) thinks another.
> > > >
> > > > Something is rotten.
> > > >
> > > > One solution: The MXNet community forks the DMLC code it relies on
> into
> > > the
> > > > MXNet codebase and moves on without being tied down by the decisions
> > of a
> > > > non-compatible community.
> > > >
> > > > Hen
> > > >
> > > >
> > > >
> > > > On Thu, Oct 19, 2017 at 11:59 AM, Tianqi Chen <
> > tqc...@cs.washington.edu>
> > > > wrote:
> > > >
> > > > > Here are the detailed points(sorry for resenting it over again)
> > > > >
> > > > > Technical Reasoning:
> > > > >
> > > > >  - Model exchange format like CoreML and ONNX are not lossless and
> > > > > complete. They are designed to an contain a core set of the
> > > > > minimum operators to support necessary inference tasks like ResNet,
> > > etc.
> > > > > So you cannot rely on a bi-directional serialization with this
> format
> > > for
> > > > > all MXNet models.  As a simple example, broadcast add/mul is simply
> > not
> > > > > supported in onnx.
> > > > >
> > > > > - Same problem goes for compilation and in-memory IR, a core set of
> > > most
> > > > > interesting primitives are effectively supported.
> > > > >
> > > > > - Either in the case of supporting exchange format, or in-memory
> IR,
> > we
> > > > > need to make the decision on what core set of operators are we
> > > interested
> > > > > in support.  We cannot simply say let us support everything from
> the
> > > > > beginning due to the limitations of the exchange format.
> > > > >
> > > > > - It is crucial for us articulate what is the core set of operators
> > we
> > > > care
> > > > > about in MXNet. Either in terms of providing guidelines to the
> > > community,
> > > > > or influence the design of model exchange format them-selfs to move
> > in
> > > > > favor of MXNet.
> > > > >
> > > > > - nnvm/top is that initial core set of operators for both compiler
> > > > support
> > > > > and exchange purposes. It is modeled under numpy and gluon, under
> the
> > > > > supervision of Eric, Me and Mu.  It can be bi-directionally
> exchanged
> > > > with
> > > > > a current mxnet operator without loss of information.
> > > > >
> > > > > The Effort of Engineering:
> > > > >
> > > > > - Because nnvm/top is modeled with numpy and gluon, mxnet<->
> nnvm/top
> > > is
> > > > > quite easy, and we already have one direction done. I would be very
> > > happy
> > > > > to answer any questions on another. No information loss will happen
> > > with
> > > > > this path.
> > > > >
> > > > > - mxnet/symbol or nnvm/symbol(they are essentially the same thing
> > with
> > > a
> > > > > bit different op defs) <- onnx is harder. There has been already
> > enough
> > > > > effort to support onnx 0.1 as Roshani mentioned. Which is
> contributed
> > > by
> > > > > Zhi Zhang, another Apache MXNet committer. Zhi already provided
> code
> > to
> > > > > alleviate 

Re: Jira and/or feature collision

[Suneel Marthi]

I am not following, wouldn't a jira be assigned to the guy working on it -
so where is the question of multiple folks working on one feature

On Mon, Sep 11, 2017 at 5:30 PM, Bhavin Thaker 
wrote:

> +1 : Chris has an important question.
>
> How do we ensure that a feature/task for a particular Apache project is not
> worked on by multiple folks at the same time?
>
> Is there a recommendation for a tool/process from the Apache group?
>
> This also provides a central, consolidated place to know who is working on
> what.
>
> Bhavin Thaker.
>
> On Mon, Sep 11, 2017 at 5:06 AM Joern Kottmann  wrote:
>
> > A good way to coordinate is to use the dev list and/or state on the
> > issues that you are interested in it and are working on it.
> >
> > We use Jira for years at Apache OpenNLP for all the issues we deal
> > with. At GitHub we use the Pull Request feature and synchronize all
> > comments with the corresponding Jira issue.
> >
> > My opinion is that Jira does much more then we actually use/need, and
> > is sometimes slightly unresponsive (e.g. takes 1 or 2 seconds to load
> > a new page) on the other hand, the GitHub issue tracker ist too simple
> > and is missing a few useful features.
> >
> > Jörn
> >
> > On Mon, Sep 11, 2017 at 10:18 AM, Henri Yandell 
> wrote:
> > > Yes, Apache JIRA is free to use.
> > >
> > > My observations of GitHub are that roadmaps/wishlist features need
> better
> > > separation from bug reports. Ideally you want a nice big list of ideas
> > for
> > > future work, and a list of bug reports and smaller contributions that
> > > you're always driving down to zero. One way to do that could be to put
> > the
> > > new features in JIRA, while keeping GitHub for bug reports, not sure if
> > > that's what you were getting to Chris with the question.
> > >
> > > Hen
> > >
> > >
> > > On Sun, Sep 10, 2017 at 9:23 PM, sandeep krishnamurthy <
> > > sandeep.krishn...@gmail.com> wrote:
> > >
> > >> +1
> > >> Thanks Chris for bringing up this important topic.
> > >>
> > >> I would really like to prioritize this topic and request users and
> > mentors
> > >> to come up a process or suggestions on how to:
> > >> 1. Request for contributions from the community.
> > >> 2. A community member raising feature requests.
> > >> 3. A community member ready to contribute a feature or bug fix.
> > >> 4. A community member actively proposing and driving a big new feature
> > for
> > >> the project.
> > >>
> > >> Projects in Github, Tagging Github issues with Call for Contributions
> > may
> > >> seem very straight forward approach. But, is there any other
> > suggestions or
> > >> standard practice to drive such efforts?
> > >>
> > >> This will go a long way in keeping community members informed about
> what
> > >> next in the project, how can they be part and how they can set future
> > >> directions in the project. Also, saving the time and effort in
> > duplication
> > >> of efforts.
> > >>
> > >> Regards,
> > >> Sandeep
> > >>
> > >> On Sat, Sep 9, 2017 at 4:48 AM, Chris Olivier 
> > >> wrote:
> > >>
> > >> > Is Apache JIRA free to use? What do most projects use? While it's
> > natural
> > >> > that some companies have internal priorities which drive their
> > >> development
> > >> > plans, how do other Apache projects avoid having the same feature
> > >> developed
> > >> > independently by more than one party, because they isn't know the
> > other
> > >> was
> > >> > working on it already?  Or coordinate forces (so to speak) on a
> large
> > >> > feature or initiative?
> > >> >
> > >> > -Chris
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Sandeep Krishnamurthy
> > >>
> >
>

Re: [VOTE] Release MXNet version 0.11.0.rc2

[Suneel Marthi]

I would also address the issue with multi-license files that Joern's
pointed out in the next RC.

You don't have to wait for 3 days to pass the next RC and the VOTE can be
closed once we have atleast 3 binding +1s.

On Mon, Aug 21, 2017 at 8:59 PM, Naveen Swamy <mnnav...@gmail.com> wrote:

> Joern and Chris, Thanks for the taking the time to test and providing your
> input, appreciate it.
>
> The bug Chris found is in examples, this should not impact the product as
> such. However, we will include the fix that Chris has, add automated tests
> and create a new RC. We will also append to the license and notice files
> the other licenses used in this repo.
>
> Question to Suneel/Mentors.
> Since the changes are very specific that will be included in the new RC, Do
> we need to run another VOTE for 3 days? I am wondering if we can run the
> VOTE on the new RC for 24 hours instead. Please let us know.
>
> this RC(0.11.RC2) will be rolled back and a new RC will be published
> tomorrow.
>
> Thanks, Naveen
>
>
> On Mon, Aug 21, 2017 at 5:21 PM, Chris Olivier <cjolivie...@gmail.com>
> wrote:
>
> > We can also discuss the option of adding to "known bugs" in release?
> >
> > On Mon, Aug 21, 2017 at 3:07 PM Suneel Marthi <smar...@apache.org>
> wrote:
> >
> > > In light of the previous -1, suggest that we cancel this vote and
> > rollback
> > > this Release Candidate.
> > >
> > > On Mon, Aug 21, 2017 at 6:03 PM, Chris Olivier <cjolivie...@gmail.com>
> > > wrote:
> > >
> > > > Added fix in this PR:
> > > https://github.com/apache/incubator-mxnet/pull/7545
> > > >
> > > > On Mon, Aug 21, 2017 at 2:29 PM, Chris Olivier <
> cjolivie...@gmail.com>
> > > > wrote:
> > > >
> > > > > If we delay to fix this before the release, I also recommend
> changing
> > > the
> > > > > '=' to ':=' in the Makefile line below so that the script isn't run
> > for
> > > > > every make spawn (or a large number of times, for that matter). I
> > > imagine
> > > > > this is slowing down the compile quite a bit:
> > > > >
> > > > > RETURN_STRING = $(shell ./prepare_mkl.sh $(MKLML_ROOT))
> > > > >
> > > > >
> > > > > On Mon, Aug 21, 2017 at 2:19 PM, Chris Olivier <
> > cjolivie...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> -1
> > > > >>
> > > > >> Simple mnist script fails if adagrad optimizer selected
> :(unexpected
> > > > >> keyword 'multi_precision'). I expect other optimizers may be
> > > similarly?
> > > > >>
> > > > >> python example/image-classification/train_mnist.py --gpu -1
> > > > >> --optimizer=adagrad
> > > > >>
> > > > >> Connected to pydev debugger (build 172.3544.40)
> > > > >> INFO:root:start with arguments Namespace(add_stn=False,
> > batch_size=64,
> > > > >> disp_batches=100, dtype='float32', gpus='-1', kv_store='device',
> > > > >> load_epoch=None, lr=0.05, lr_factor=0.1, lr_step_epochs='10',
> > > > >> model_prefix=None, mom=0.9, monitor=0, network='mlp',
> > num_classes=10,
> > > > >> num_epochs=20, num_examples=6, num_layers=None,
> > > optimizer='adagrad',
> > > > >> test_io=0, top_k=0, wd=0.0001)
> > > > >> Traceback (most recent call last):
> > > > >>   File "/mnt/Terrace/Apps/clion-2017.1.2/plugins/python/helpers/
> > > > pydev/pydevd.py",
> > > > >> line 1599, in 
> > > > >> globals = debugger.run(setup['file'], None, None, is_module)
> > > > >>   File "/mnt/Terrace/Apps/clion-2017.1.2/plugins/python/helpers/
> > > > pydev/pydevd.py",
> > > > >> line 1026, in run
> > > > >> pydev_imports.execfile(file, globals, locals)  # execute the
> > > script
> > > > >>   File "example/image-classification/train_mnist.py", line 96, in
> > > > >> 
> > > > >> fit.fit(args, sym, get_mnist_iter)
> > > > >>   File "example/image-classification/common/fit.py", line 207, in
> > fit
> > > > >> monitor= monitor)
> > > > >>   File "/home/local/ANT/coolivie/src/DeepLearning/mxnet/python/
> > > > mxnet/module/base_module

Re: Draft MXNet Podling report for Aug-2017

[Suneel Marthi]

MxNet is not due to report for Aug 17, so we can disregard this.



On Mon, Jul 31, 2017 at 4:40 PM, Bhavin Thaker <bhavintha...@gmail.com>
wrote:

> Hi All,
>
>
>
> Please review the Podling Report for August 2017 so that we can file on
> time. Feel free to make updates to this shared Google doc directly.
>
>
>
> https://docs.google.com/document/d/1PGhs96klZB6DXhpK9_
> biPh4-aCm8-bWwFzexnOW_GMA/edit
>
>
>
> Given below is the current snapshot of the report – it may change as
> updates are made directly to the above shared Google doc.
>
>
>
> --snip—
>
> *MXNet*
>
>
>
> MXNet is an open-source deep learning framework that allows you to define,
>
> train, and deploy deep neural networks on a wide array of devices, from
>
> cloud infrastructure to mobile devices. It is highly scalable, allowing for
>
> fast model training, and supports a flexible programming model and multiple
>
> languages. MXNet allows you to mix symbolic and imperative programming
>
> flavors to maximize both efficiency and productivity. MXNet is built on a
>
> dynamic dependency scheduler that automatically parallelizes both symbolic
>
> and imperative operations on the fly. A graph optimization layer on top of
>
> that makes symbolic execution fast and memory efficient. The MXNet library
>
> is portable and lightweight, and it scales to multiple GPUs and multiple
>
> machines.
>
>
>
> MXNet has been incubating since 2017-01-23.
>
>
>
> *Three most important issues to address in the move towards graduation:*
>
>
>
>  1. Migrate code (GitHub) and website to Apache Infra.
>
>  2. Establish a predictable release process consistent with Apache Way.
>
>  3. Grow the community.
>
>
>
> *Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be*
>
> *aware of?*
>
>
>
>   None
>
>
>
> *How has the community developed since the last report?*
>
>
>
>1. Various Slack channels and dev@ mailing lists are being used
> actively.
>2. A new blog published on OReilly web-site on 27-July having
>step-by-step instructions to implement a convolutional neural network to
>classify traffic signs with Apache MXNet:
>
> https://www.oreilly.com/ideas/classifying-traffic-signs-
> with-mxnet-an-introduction-to-computer-vision-with-neural-networks
>
>1. A new blog post published on 28-July showing users how to exploit the
>unique features of Apache MXNet with a cheat sheet:
>
> https://aws.amazon.com/blogs/ai/exploiting-the-unique-
> features-of-the-apache-mxnet-deep-learning-framework-with-a-cheat-sheet/
>
>
>
> *How has the project developed since the last report?*
>
>
>
>1. The code base was migrated from http://github.com/dmlc/mxnet to
>https://github.com/apache/incubator-mxnet on 28-July, 2017.
>2. From a statistics perspective, 54 authors have pushed 140 commits to
>master, with updates to 358 files including 22K additions and 3K
> deletions.
>3. Documentation- Architecture guides, How To’s, Tutorials, and APIs
>continue to be improved.
>4. More features (e.g. operators, algorithms) and bug-fixes requested by
>the user community continue to be added.
>
>
>
> *How would you assess the podling's maturity?*
>
>
>
>   Podling's still getting established in Apache - so maturity == Low.
>
>
>
> Please feel free to add your own commentary.
>
>  [X] Initial setup
>
>  [  ] Working towards first release
>
>  [  ] Community building
>
>  [  ] Nearing graduation
>
>  [X] Other: A maintenance release is being planned for August 2017
>
>
>
> *Date of last release:*
>
>
>
>  A maintenance release MXNet 0.10.0 Post 2 with few bug-fixes was released
> on 17-July, 2017.
>
>  https://github.com/apache/incubator-mxnet/releases/tag/0.10.0.post2
>
>
>
> *When were the last committers or PPMC members elected?*
>
>
>
>  Ly Nguyen added as a committer and PPMC member in June 2017.
>
>
>
> *Signed-off-by:*
>
>  [ ](mxnet) Sebastian Schelter
>
> Comments:
>
>  [ ](mxnet) Suneel Marthi
>
> Comments:
>
>  [ ](mxnet) Markus Weimer
>
> Comments:
>
>  [ ](mxnet) Henri Yandell
>
> Comments:
>
>
>
> --snip—
>
>
>
> Thanks,
>
> Bhavin Thaker.
>

Re: Licensing update per code move

[Suneel Marthi]

I am not aware of a shorter version. Below is the standard header that
needs to go into all the files.

/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License. You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */






On Thu, Jul 6, 2017 at 12:56 PM, Tianqi Chen <tqc...@cs.washington.edu>
wrote:

>  I did notice that there is a shorter version of the header. I think we
> could use that ?
>
> Tianqi
> On Thu, Jul 6, 2017 at 8:58 AM Suneel Marthi <smar...@apache.org> wrote:
>
> > Yes its absolutely necessary that every file have a Apache license
> header -
> > and every project that comes into Apache does that.
> > No, its got to be at file level and not folder.
> >
> > Lookup RAT plugin - what all projects use to ensure that files have
> license
> > headers.
> >
> > On Thu, Jul 6, 2017 at 11:52 AM, Naveen Swamy <mnnav...@gmail.com>
> wrote:
> >
> > > that is a lot of edits to the source files just to include the
> > > license terms, this will also change the history of the files. Can we
> > add a
> > > license file at a folder level and do this next time we touch the file?
> > > Also Is this absolutely necessary?
> > >
> > > On Wed, Jul 5, 2017 at 11:28 PM, Henri Yandell <bay...@apache.org>
> > wrote:
> > >
> > > > Thought I'd describe one of the first sets of changes we should make
> > when
> > > > the code moves to an Apache git repo.
> > > >
> > > > We should update the licensing.
> > > >
> > > > 1) We should update the NOTICE file, once on Apache's source control,
> > to
> > > > say:
> > > >
> > > >  Apache MXNet
> > > > Copyright 2017 The Apache Software Foundation
> > > > This product includes software developed at
> > > >  The Apache Software Foundation (http://www.apache.org/).
> > > >
> > > > 2) Every source file (basically all files bar images, binaries and
> test
> > > > data) should have a commented source header:
> > > >
> > > > Licensed to the Apache Software Foundation (ASF) under one
> > > > or more contributor license agreements.  See the NOTICE file
> > > > distributed with this work for additional information
> > > > regarding copyright ownership.  The ASF licenses this file
> > > > to you under the Apache License, Version 2.0 (the
> > > > "License"); you may not use this file except in compliance
> > > > with the License.  You may obtain a copy of the License at
> > > >
> > > >   http://www.apache.org/licenses/LICENSE-2.0
> > > >
> > > > Unless required by applicable law or agreed to in writing,
> > > > software distributed under the License is distributed on an
> > > > "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> > > > KIND, either express or implied.  See the License for the
> > > > specific language governing permissions and limitations
> > > > under the License.
> > > >
> > > >
> > > > Described on this page: https://www.apache.org/legal/
> src-headers.html
> > > >
> > > > ---
> > > >
> > > > Hope that's useful :)
> > > >
> > > > Hen
> > > >
> > >
> >
>

Re: Licensing update per code move

[Suneel Marthi]

Yes its absolutely necessary that every file have a Apache license header -
and every project that comes into Apache does that.
No, its got to be at file level and not folder.

Lookup RAT plugin - what all projects use to ensure that files have license
headers.

On Thu, Jul 6, 2017 at 11:52 AM, Naveen Swamy  wrote:

> that is a lot of edits to the source files just to include the
> license terms, this will also change the history of the files. Can we add a
> license file at a folder level and do this next time we touch the file?
> Also Is this absolutely necessary?
>
> On Wed, Jul 5, 2017 at 11:28 PM, Henri Yandell  wrote:
>
> > Thought I'd describe one of the first sets of changes we should make when
> > the code moves to an Apache git repo.
> >
> > We should update the licensing.
> >
> > 1) We should update the NOTICE file, once on Apache's source control, to
> > say:
> >
> >  Apache MXNet
> > Copyright 2017 The Apache Software Foundation
> > This product includes software developed at
> >  The Apache Software Foundation (http://www.apache.org/).
> >
> > 2) Every source file (basically all files bar images, binaries and test
> > data) should have a commented source header:
> >
> > Licensed to the Apache Software Foundation (ASF) under one
> > or more contributor license agreements.  See the NOTICE file
> > distributed with this work for additional information
> > regarding copyright ownership.  The ASF licenses this file
> > to you under the Apache License, Version 2.0 (the
> > "License"); you may not use this file except in compliance
> > with the License.  You may obtain a copy of the License at
> >
> >   http://www.apache.org/licenses/LICENSE-2.0
> >
> > Unless required by applicable law or agreed to in writing,
> > software distributed under the License is distributed on an
> > "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> > KIND, either express or implied.  See the License for the
> > specific language governing permissions and limitations
> > under the License.
> >
> >
> > Described on this page: https://www.apache.org/legal/src-headers.html
> >
> > ---
> >
> > Hope that's useful :)
> >
> > Hen
> >
>

Re: Podling Report Reminder - July 2017

[Suneel Marthi]

Thanks Dom, the report has been filed.

Mentors, please sign-off on the report.

On Wed, Jul 5, 2017 at 6:10 PM, Dominic Divakaruni <
dominic.divakar...@gmail.com> wrote:

> Please see below. Can one of our mentor's help upload this report to
> https://wiki.apache.org/incubator/July2017
>
> 1. Your project name: Apache MXNet
>
>
>
> 2. A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
>
> MXNet is an open-source deep learning framework that allows you to define,
> train, and deploy deep neural networks on a wide array of devices, from
> cloud infrastructure to mobile devices. It is highly scalable, allowing for
> fast model training, and supports a flexible programming model and multiple
> languages. MXNet allows you to mix symbolic and imperative programming
> flavors to maximize both efficiency and productivity. MXNet is built on a
> dynamic dependency scheduler that automatically parallelizes both symbolic
> and imperative operations on the fly. A graph optimization layer on top of
> that makes symbolic execution fast and memory efficient. The MXNet library
> is portable and lightweight, and it scales to multiple GPUs and multiple
> machines.
>
>
>
> 3. A list of the three most important issues to address in the move
> towards graduation.
>
> 3.1.  Migrate code (GitHub) and website to Apache.
>
> 3.2.  Grow the community:
>
> 3.2.1. Expand reference material including – new machine learning
> research published based on MXNet, tutorials, documented use cases and
> architecture documentation.
>
> 3.2.2. Improving user-experience –for example improved error messages
>
> 3.2.3. Improved support for various programming languages
>
> 3.2.4. Establish a dependable, Apache-way consistent release process.
>
> 3.3.  Features:
>
> 3.3.1. Capability (such as low precision support and quantization) that
> allows models to run efficiently on mobile and edge devices. Integrations
> with mobile and edge device acceleration drivers.
>
> 3.3.2. Accelerate performance on CPUs and GPUs.
>
>
>
> 4. Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of: None.
>
>
>
> 5. How has the community developed since the last report.
>
> 5.1.  On 5/27 MXNet published a comprehensive edit and makeover of the
> documentation including tutorials, how-to’s, APIs and architecture guides.
> This was a broad effort that involved over 40 contributors.
>
> 5.2.  The PMC voted in a new contributor who has been helping with the code
> migration and setup of the test infrastructure. We are making slow but
> steady progress towards getting the GitHub code migrated. The target date
> for migration is 7/17. Website migration will happen next.
>
> 5.3.  Slack and dev@ are being used more actively.
>
> 5.4.  Two presentations/workshops on Apache MXNet at the O’Reilly AI Conf
> on 6/27 and 6/28
>
> 5.5.  A new blog post published on 6/23 showing users how to Build a
> Real-time Object Classification System with ApacheMXNet on Raspberry Pi.
> https://aws.amazon.com/blogs/ai/build-a-real-time-object-
> classification-system-with-apache-mxnet-on-raspberry-pi/
>
> 6. How has the project developed since the last report.
>
> 6.1.  Since the last report 42 authors have pushed 326 commits to master.
>
> 6.2.  Documentation- Architecture guides, How To’s, Tutorials, and APIs
> have been improved.
>
> 6.3.  More features (e.g. operators) requested by the user community has
> been added.
>
> 6.4.   A new Perl language binding for MXNet was added.
>
>
>
> 7. How does the podling rate their own maturity. Maturity = Low.
>
>
>
>
>
> On Mon, Jul 3, 2017 at 3:49 AM,  wrote:
>
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 19 July 2017, 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, July 05).
> >
> > 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.
> >
> > 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 

Re: Board report due

[Suneel Marthi]

Dom,

Its much easier to comment/modify if u created a google doc and send a
editable link out. Please do that.

On Tue, Jul 4, 2017 at 6:06 PM, Dominic Divakaruni <
dominic.divakar...@gmail.com> wrote:

> Hello all,
> Hope those of us in the US are having a great 4th of July! I've taken a
> stab at a draft of the report. Section 6 needs to be updated. Please pitch
> in with your updates
>
> 1. Your project name: Apache MXNet
>
>
>
> 2. A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field: MXNet is an open-source deep
> learning framework that allows you to define, train, and deploy deep neural
> networks on a wide array of devices, from cloud infrastructure to mobile
> devices. It is highly scalable, allowing for fast model training, and
> supports a flexible programming model and multiple languages. MXNet allows
> you to mix symbolic and imperative programming flavors to maximize both
> efficiency and productivity. MXNet is built on a dynamic dependency
> scheduler that automatically parallelizes both symbolic and imperative
> operations on the fly. A graph optimization layer on top of that makes
> symbolic execution fast and memory efficient. The MXNet library is portable
> and lightweight, and it scales to multiple GPUs and multiple machines.
>
> 3. A list of the three most important issues to address in the move
> towards graduation.
>
> 3.1.  Migrate code (GitHub) and website to Apache.
>
> 3.2.  Grow the community:
>
> 3.2.1. Expand reference material including – new machine learning
> research published based on MXNet, tutorials, documented use cases and
> architecture documentation.
>
> 3.2.2. Improving user-experience –for example improved error messages
>
> 3.2.3. Improved support for various programming languages
>
> 3.2.4. Establish a dependable, Apache-way consistent release process.
>
> 3.3.  Features:
>
> 3.3.1. Capability (such as low precision support and quantization) that
> allows models to run efficiently on mobile and edge devices. Integrations
> with mobile and edge device acceleration drivers.
>
> 3.3.2. Accelerate performance on CPUs and GPUs.
>
>
>
> 4. Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of:
>
> None.
>
>
>
> 5. How has the community developed since the last report.
>
> 5.1.  On 5/27 MXNet published a comprehensive edit and makeover of the
> documentation including tutorials, how-to’s, APIs and architecture guides.
> This was a broad effort that involved over 40 contributors.
>
> 5.2.  The PMC voted in a new contributor who has been helping with the code
> migration and setup of the test infrastructure. We are making slow but
> steady progress towards getting the GitHub code migrated. The target date
> for migration is 7/17. Website migration will happen next.
>
> 5.3.  Slack and dev@ are being used more actively.
>
> 6. How has the project developed since the last report.
>
> 6.1.  Since the last report 42 authors have pushed 326 commits to master.
>
> 6.2.  (Previous Update)  On master, 502 files have changed and there have
> been 26,246 additions and 12,188 deletions. Count of Closed Issues = 62,
> Count of new Issues = 146, Count of Merged Pull Requests = 161, Count of
> Proposed Pull Requests = 27.
>
> 6.3.  (Previous Update) The API Documentation has improved.
>
> 6.4.  (Previous Update) More features (e.g. operators) requested by the
> user community has been added.
>
> 6.5.  (Previous update) Hardware acceleration like cuDDN6 integration and
> MKL ML package integration was completed.
>
> 6.6.  (Previous Update) A new Perl language binding for MXNet was added.
>
>
>
> 7. How does the podling rate their own maturity: Maturity = Low.
>
>
> On Mon, Jul 3, 2017 at 11:39 PM, Henri Yandell  wrote:
>
> > In case the relentless automated pinging hasn't given it away, we've a
> > board report due.
> >
> > Hen
> >
>
>
>
> --
>
>
> Dominic Divakaruni
> 206.475.9200 Cell
>

Re: Podling Report - May 2017

[Suneel Marthi]

IMO, the top 3 items to be addressed for graduation are:-

1.  Migrate code(GitHub) and website to Apache. 2.  Establish a
formal release schedule and process, allowing for dependable release
cycles in a manner consistent with the Apache way.3.  Grow the
community to establish diversity of background.


On Thu, May 4, 2017 at 3:29 AM, Henri Yandell  wrote:

> Thank you Mu.
>
> I added it to https://wiki.apache.org/incubator/May2017 (with some
> additions) and signed off as Mentor. Everyone let me know if any of the
> additions I made were objectionable. The main change was to insert
> Migrating code+website as the top priority.
>
> Other Mentors - your review is much appreciated :)
>
> On Wed, May 3, 2017 at 1:22 PM, Mu Li  wrote:
>
> > *   Your project name:
> >
> > Apache MXNet
> >
> > *   A brief description of your project, which assumes no knowledge of
> the
> > project or necessarily of its field
> >
> > MXNet is an open-source deep learning framework that allows you to
> define,
> > train, and deploy deep neural networks on a wide array of devices, from
> > cloud infrastructure to mobile devices. It is highly scalable, allowing
> for
> > fast model training, and supports a flexible programming model and
> multiple
> > languages. MXNet allows you to mix symbolic and imperative programming
> > flavors to maximize both efficiency and productivity. MXNet is built on a
> > dynamic dependency scheduler that automatically parallelizes both
> symbolic
> > and imperative operations on the fly. A graph optimization layer on top
> of
> > that makes symbolic execution fast and memory efficient. The MXNet
> library
> > is portable and lightweight, and it scales to multiple GPUs and multiple
> > machines.
> >
> > *   A list of the three most important issues to address in the move
> > towards graduation.
> >
> > 1.   Improved documentation including APIs, Tutorials, etc. and
> > user-experience like improved error messages, etc.
> > 2.   Support additional features (new operators) requested by user
> > community.
> > 3.   Accelerate performance on CPUs and GPUs.
> >
> > *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of:
> >
> > None.
> >
> > *   How has the community developed since the last report.
> >
> > 1. The community was engaged for contributions to API documentation and
> > tutorials.
> > 2. Slack channels have been created for the community to contribute
> > discussions to.
> > 3. In the last month, excluding merges, 51 authors have pushed 165
> commits
> > to master and 180 commits to all branches. On master, 502 files have
> > changed and there have been 26,246 additions and 12,188 deletions. Count
> of
> > Closed Issues = 62, Count of New Issues = 146, Count of Merged Pull
> > Requests = 161, Count of Proposed Pull Requests = 27.
> >
> > *   How has the project developed since the last report.
> >
> > 1. The API Documentation has improved.
> > 2. More features (e.g. operators) requested by the user community has
> been
> > added.
> > 3. Hardware acceleration like cuDDN6 integration and MKL ML package
> > integration was completed.
> > 4. A new Perl language binding for MXNet was added.
> >
> > *   How does the podling rate their own maturity.
> >
> > Maturity = Low
> >
> > Thanks,
> > Mu
> >
>

Re: Draft of March 2016 Podling Report

[Suneel Marthi]

Thanks Henry. Done, other mentors please go ahead and sign the report.

On Thu, Mar 2, 2017 at 12:49 AM, Henri Yandell <bay...@apache.org> wrote:

> Thanks Suneel :) Couple of bits inline.
>
> On Wed, Mar 1, 2017 at 2:57 PM, Suneel Marthi <smar...@apache.org> wrote:
>
> > Here's an initial draft of podling report for March 2016, please feel
> free
> > to add/edit as you deem fit.
> >
> > --
> >
> > MXNet
> >
> > A Flexible and Efficient Library for Deep Learning
> >
> > MXNet has been incubating since 2017-01-23.
> >
> > Three most important issues to address in the move towards graduation:
> >
> >   1.Establish a formal release process and schedule, allowing for
> > dependable release cycles in line with Apache development process.
> >
> >   2. Move the code and website to Apache Infra.
> >
> >   3.
>
>
> Perhaps:
>
> PPMC to discuss adding in some community members who asked to join
> while the Incubator vote was ongoing (learning how to vote new committers
> in).  ?
>
>
> > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> >
> > aware of?
> >
> >   None
> >
> > How has the community developed since the last report?
> >
> >   Project is still being established in Incubator
> >
> > How has the project developed since the last report?
> >
> >   This would be the first podling report
> >
>
> Second report :)
>
>
> >
> > How would you assess the podling's maturity?
> >
> > Please feel free to add your own commentary.
> >
> >   [X] Initial setup
> >
> >   [ ] Working towards first release
> >
> >   [ ] Community building
> >
> >   [ ] Nearing graduation
> >
> >   [ ] Other:
> >
> > Date of last release:
> >
> >   No release yet
> >
> > When were the last committers or PPMC members elected?
> >
> > Project is being established with initial set of committers.
> >
> > Signed-off-by:
> >
> >   [ ](mxnet) Sebastian Schelter
> >
> >  Comments:
> >
> >   [ ](mxnet) Suneel Marthi
> >
> >  Comments:
> >
> >   [ ](mxnet) Markus Weimer
> >
> >  Comments:
> >
> >   [ ](mxnet) Henri Yandell
> >
> >  Comments:
> >
>