Re: Podling Mxnet Report Reminder - April 2020

[Hen]

Same.

Post report, I'd like to see a more detailed "what is left for graduation"
list from the 2 Ongoing items listed.

Hen

On Tue, Mar 31, 2020 at 4:50 AM Michael Wall  wrote:

> LGTM, thanks
>
> On Mon, Mar 30, 2020 at 12:10 AM Sheng Zha  wrote:
>
> > I posted the draft at
> > https://cwiki.apache.org/confluence/display/INCUBATOR/April2020#MXNet.
> > Suggestions and updates are welcome. Thanks.
> >
> > -sz
> >
> > On 2020/03/25 18:18:04, Sheng Zha  wrote:
> > > I'm working on a draft now and will report back with link once ready.
> > >
> > > -sz
> > >
> > > On 2020/03/20 03:18:09, jmcl...@apache.org wrote:
> > > > Dear podling,
> > > >
> > > > This email was sent by an automated system on behalf of the Apache
> > > > Incubator PMC. It is an initial reminder to give you plenty of time
> to
> > > > prepare your quarterly board report.
> > > >
> > > > The board meeting is scheduled for Wed, 15 April 2020, 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, April 01).
> > > >
> > > > Please submit your report with sufficient time to allow the Incubator
> > > > PMC, and subsequently board members to review and digest. Again, the
> > > > very latest you should submit your report is 2 weeks prior to the
> board
> > > > meeting.
> > > >
> > > > Candidate names should not be made public before people are actually
> > > > elected, so please do not include the names of potential committers
> or
> > > > PPMC members in your report.
> > > >
> > > > Thanks,
> > > >
> > > > The Apache Incubator PMC
> > > >
> > > > Submitting your Report
> > > >
> > > > --
> > > >
> > > > Your report should contain the following:
> > > >
> > > > *   Your project name
> > > > *   A brief description of your project, which assumes no knowledge
> of
> > > > the project or necessarily of its field
> > > > *   A list of the three most important issues to address in the move
> > > > towards graduation.
> > > > *   Any issues that the Incubator PMC or ASF Board might wish/need to
> > be
> > > > aware of
> > > > *   How has the community developed since the last report
> > > > *   How has the project developed since the last report.
> > > > *   How does the podling rate their own maturity.
> > > >
> > > > This should be appended to the Incubator Wiki page at:
> > > >
> > > > https://cwiki.apache.org/confluence/display/INCUBATOR/April2020
> > > >
> > > > Note: This is manually populated. You may need to wait a little
> before
> > > > this page is created from a template.
> > > >
> > > > Note: The format of the report has changed to use markdown.
> > > >
> > > > Mentors
> > > > ---
> > > >
> > > > Mentors should review reports for their project(s) and sign them off
> on
> > > > the Incubator wiki page. Signing off reports shows that you are
> > > > following the project - projects that are not signed may raise alarms
> > > > for the Incubator PMC.
> > > >
> > > > Incubator PMC
> > > >
> > >
> >
>

Re: ONNX Support

[Hen]

On Mon, Oct 7, 2019 at 6:32 PM Chaitanya Bapat  wrote:

> Thanks a lot everyone for chiming in.
>
> Update: The issue in my PR was a bug (unrelated to ONNX) I introduced while
> switching from GPU to non-GPU 2D transpose support. Thanks to Xingjian Shi
> <https://github.com/sxjscience> for pointing that out. Apologies from my
> side.
>
> As it stands now, the PR passes. I added a unit test to track that bug. So
> we don't need any disabling.
>
> Since this wasn't related to ONNX per se, I guess the premise behind this
> discussion is now null and void.
> Also as it turns out, there are customers who use MXNet with ONNX so we
> might have to continue testing and supporting (even if in maintenance mode)
>
>
Note that 'we' there is a bit vague. Apache does not have customers, so
there's no "we have to continue".

If the community no longer has belief/trust/energy/interest in the code,
then one approach is to remove it from the primary build and put it into a
separate directory or repository. You can add a readme on how to
re-integrate it and a note that if someone is interested in contributing to
it then the community will do their best to respond.

Or you can delete it. Amazon can always fork the code in a separate repo
for their customers.

Hen

Re: [DISCUSS] Apache MXNet: Path to graduation

[Hen]

On Fri, Aug 30, 2019 at 3:01 AM Leonard Lausen  wrote:

> Anton Chernov  writes:
> > As a physicist I would like to point out that "Gluon" means: An
> elementary
> > particle that acts as the exchange particle for the strong force between
> > quarks [1].
> > As a general scientific term it can barely be seen as a candidate for
> > trademark registration.
>
> This doesn't seem to pose a barrier for trademark registration though.
>
>
Agreed. Part of the reason for that (in my layman opinion) is that it's not
"Apache MXNet" or "Gluon", it's "Apache MXNet deep learning library". Which
is something that should be improved on our website by the way.

It's weird for how folk typically think about it in software, but
trademarks are adjectives and not nouns. Heinz Tomato Soup tells you that
this is Tomato Soup (yawn) of Heinz quality (yay!). "Ford Focus [quality]
automobile", not "Ford Focus".

If you think of it like a programming language's type system; science uses
Gluon as a noun, which does not clash with it being used as an adjective
elsewhere.

If any of that makes sense :)

Hen

Re: [DISCUSS] Apache MXNet: Path to graduation

[Hen]

The former is a trademark question to ask when deciding to use a brand.
Something Amazon would have considered but as Gluon isn't an Apache brand
it's not something Apache have considered. If the brand was 'transferring'
to Apache then it is something we should do.

Are you saying that trademarks for MXNet has been registered by other
companies?

Hen

On Fri, Aug 30, 2019 at 1:27 AM Leonard Lausen  wrote:

> Carin recently noted that gluonhq.com already uses the Gluon brand for
> end-to-end enterprise mobile solution and Marco found that they do so
> apparently since at least 2015. Do you see any impact on the Gluon brand
> for deep learning models?
>
> The MXNet brand is currently also unregistered by Apache (but registered
> by various other companies), whereas for example Tensorflow is
> registered by Google LLC in a variety of jurisdictions. Trademarks
> registered under the Madrid System can be found at
> https://www3.wipo.int/branddb/en/
>
> Best regards
> Leonard
>
> Hen  writes:
>
> > Amazon. Amazon created the brand. They own the first repository to use
> the
> > term in this conext ( https://github.com/gluon-api ). There was some
> > involvement from Microsoft, so Microsoft's opinion may also be relevant.
> > Gluon is not an Apache Software Foundation nor Apache MXNet brand.
> >
> > Unless it was very recent, I don't believe there have been any trademark
> > registrations. If Amazon would prefer Apache control the Gluon naming, I
> > think the simplest 'act' to make that so would be to move the gluon-api
> > repository over to ASF control.
> >
> > Hen
> >
> > On Thu, Aug 29, 2019 at 8:27 AM Chris Olivier 
> wrote:
> >
> >> Who is the gluon “Brand Owner”?
> >>
> >> On Tue, Aug 27, 2019 at 10:43 AM Chris Olivier 
> >> wrote:
> >>
> >> > Who is the gluon "brand owner"?
> >> >
> >> > On Tue, Aug 27, 2019 at 10:13 AM Qing Lan 
> wrote:
> >> >
> >> >> Hi Lieven,
> >> >>
> >> >> Thanks for your comments. After the discussion with several
> committers
> >> >> and contributors offline, we agreed that there are space for
> >> improvement.
> >> >>
> >> >>
> >> >>   1.  About the Gluon naming
> >> >>
> >> >> As we know, Gluon is born with the unique API design pattern. It
> >> >> gradually became the dominant Python front end for MXNet. I would
> >> suggest
> >> >> to discuss more with the Brand owner and see if there could be a
> further
> >> >> integration with MXNet. To MXNet itself, it becomes more popular with
> >> this
> >> >> frontend. We lean on the strong community and improve our product
> >> better by
> >> >> consuming the feedback from it.
> >> >>
> >> >>  2. Diversity of the PMC
> >> >> Currently, we have 40 PMC numbers from different companies, like
> Amazon,
> >> >> Uber, NVIDIA, ByteDance and a lot more. We are trying to grow the
> number
> >> >> and invite indivials from different companies as well as research
> >> institute.
> >> >>
> >> >> 3. Release rotation
> >> >> In the history, most of the releases were done by the Amazon side.
> >> >> Currently, we are moving on to rotate this responsibility with
> >> >> contributors/committers not from Amazon to start working on them.
> >> >>
> >> >> 4. Committers from different firm/institution should have real
> work
> >> >> on MXNet
> >> >> I can tell from the issues/PRs/rfcs they submitted and indeed and
> indeed
> >> >> we should encourage the committers who is less active to be involved
> >> into
> >> >> MXNet contribution.
> >> >>
> >> >> Thanks,
> >> >> Qing
> >> >>
> >> >> 
> >> >> From: Lieven Govaerts 
> >> >> Sent: Saturday, August 10, 2019 5:59
> >> >> To: dev@mxnet.incubator.apache.org 
> >> >> Cc: d...@mxnet.apache.org 
> >> >> Subject: Re: [DISCUSS] Apache MXNet: Path to graduation
> >> >>
> >> >> Hi Qing,
> >> >>
> >> >> as a user and ASF member observing this project:
> >> >>
> >> >> On Sat, 10 Aug 2019 at 01:44, Qing Lan  wrote:
> >> >

Re: [DISCUSS] Apache MXNet: Path to graduation

[Hen]

Amazon. Amazon created the brand. They own the first repository to use the
term in this conext ( https://github.com/gluon-api ). There was some
involvement from Microsoft, so Microsoft's opinion may also be relevant.
Gluon is not an Apache Software Foundation nor Apache MXNet brand.

Unless it was very recent, I don't believe there have been any trademark
registrations. If Amazon would prefer Apache control the Gluon naming, I
think the simplest 'act' to make that so would be to move the gluon-api
repository over to ASF control.

Hen

On Thu, Aug 29, 2019 at 8:27 AM Chris Olivier  wrote:

> Who is the gluon “Brand Owner”?
>
> On Tue, Aug 27, 2019 at 10:43 AM Chris Olivier 
> wrote:
>
> > Who is the gluon "brand owner"?
> >
> > On Tue, Aug 27, 2019 at 10:13 AM Qing Lan  wrote:
> >
> >> Hi Lieven,
> >>
> >> Thanks for your comments. After the discussion with several committers
> >> and contributors offline, we agreed that there are space for
> improvement.
> >>
> >>
> >>   1.  About the Gluon naming
> >>
> >> As we know, Gluon is born with the unique API design pattern. It
> >> gradually became the dominant Python front end for MXNet. I would
> suggest
> >> to discuss more with the Brand owner and see if there could be a further
> >> integration with MXNet. To MXNet itself, it becomes more popular with
> this
> >> frontend. We lean on the strong community and improve our product
> better by
> >> consuming the feedback from it.
> >>
> >>  2. Diversity of the PMC
> >> Currently, we have 40 PMC numbers from different companies, like Amazon,
> >> Uber, NVIDIA, ByteDance and a lot more. We are trying to grow the number
> >> and invite indivials from different companies as well as research
> institute.
> >>
> >> 3. Release rotation
> >> In the history, most of the releases were done by the Amazon side.
> >> Currently, we are moving on to rotate this responsibility with
> >> contributors/committers not from Amazon to start working on them.
> >>
> >> 4. Committers from different firm/institution should have real work
> >> on MXNet
> >> I can tell from the issues/PRs/rfcs they submitted and indeed and indeed
> >> we should encourage the committers who is less active to be involved
> into
> >> MXNet contribution.
> >>
> >> Thanks,
> >> Qing
> >>
> >> 
> >> From: Lieven Govaerts 
> >> Sent: Saturday, August 10, 2019 5:59
> >> To: dev@mxnet.incubator.apache.org 
> >> Cc: d...@mxnet.apache.org 
> >> Subject: Re: [DISCUSS] Apache MXNet: Path to graduation
> >>
> >> Hi Qing,
> >>
> >> as a user and ASF member observing this project:
> >>
> >> On Sat, 10 Aug 2019 at 01:44, Qing Lan  wrote:
> >>
> >> > Hi All,
> >> >
> >> > I would like to start a thread to discuss about the graduation for
> >> Apache
> >> > MXNet. From my time working in the community, I saw a great
> improvement
> >> in
> >> > most of the area that we do to make MXNet a better place. We keep
> >> tracking
> >> > on all of the issues user raised and reviewing PRs. We follow the
> Apache
> >> > Way to release the package in official repository.
> >> >
> >> >
> >> in terms of code, documentation, visibility this project is certainly
> in a
> >> healthy state, I see a lot of interest of companies and people, the
> >> community is growing... As a user that gives me confidence my time
> >> invested
> >> in this product is well spent.
> >>
> >>
> >> > In 2017, Apache MXNet joined the Apache incubation project. I think
> now
> >> is
> >> > a good time to review the path to graduate MXNet and move forward to
> it.
> >> > Please feel free to share your thoughts on graduation and space for
> >> > improvement.
> >> >
> >> >
> >> If I may share one observation: I don't see the community working a lot
> on
> >> non-code topics. One example that I personally find important is the
> >> discussion of the Gluon brand. People have expressed confusion about how
> >> the name is used by multiple non-ASF projects, the MXNet team finds the
> >> Gluon name very valuable yet the discussion on how to protect the name
> and
> >> decide on acceptable use by other projects has stalled [1]. I suggest
> you
> >> make a decision on this topic before you go for graduation.
> >>
> >> regards,
> >>
> >> Lieven
> >>
> >> [1]
> >>
> >>
> https://mail-archives.apache.org/mod_mbox/mxnet-dev/201903.mbox/%3ccac_cu1gi+3s6ob48kt0x5wta4oxdum8uq9tmnyku2ujyaya...@mail.gmail.com%3e
> >>
> >>
> >>
> >>
> >> > You can find more about graduation policy in here:
> >> > https://incubator.apache.org/guides/graduation.html
> >> >
> >> > Thanks,
> >> > Qing
> >> >
> >>
> >
>

Re: demise of dmlc.ml domain & new Julia docs hosting

[Hen]

Nice work :)

What other links does the project have that are outside Apache Infra
control and have this risk?

Outside of github.com/dmlc which is well known and iiuc in process for
resolving.

Hen


On Tue, Jul 9, 2019 at 4:46 PM Aaron Markham 
wrote:

> The PR has passed CI. Please take a look.
> https://github.com/apache/incubator-mxnet/pull/15454
> We really need to get rid of those malware links, and this does that,
> restores the Julia docs with a local build, has CI coverage, and a new
> Ubuntu guide (since I had to figure out how to use Julia and found our
> docs for that were kind of broken).
> Cheers,
> Aaron
>
> On Thu, Jul 4, 2019 at 8:09 PM Iblis Lin  wrote:
> >
> > Hi,
> >
> > I will add +1 to the micro-site approach.
> > Since I have tried to take the generated MD outputs from
> > Julia's doc system, but the syntax is incompatible with
> > the MD plugin of Sphinx.
> >
> > Iblis Lin
> > 林峻頤
> >
> > On 7/4/19 12:12 PM, Aaron Markham wrote:
> > > Hi dev@,
> > > In case you missed the issues with the dmlc.ml domain, it was let go
> > > or sniped and now goes to a malware site. [1] Several assets like
> > > models and the Julia documentation were hosted there.
> > >
> > > I made some progress getting the Julia docs generated as part of the
> > > regular website build flow. [2] It'll work as long as you have Julia
> > > installed and configured with MXNet. I don't imagine you can use it to
> > > build the website natively on your mac or windows box at this point
> > > because all of the CI and related instructions appear to be only for
> > > Ubuntu. That being said, I added an option to dev_menu.py so you can
> > > build the Julia docs with docker on whatever host you're on.
> > >
> > > I tried to bring in the markdown files and have the website theme
> > > applied to them. Many things were then broken - in large part due to
> > > some bugs in the website code related to post processing and injection
> > > of dom elements. This would require a rewrite of the Julia docs to
> > > workaround the existing website bugs. Rather than do this, I just took
> > > the Julia site output, which has its own look and feel and nested in
> > > Julia's API directory. This is much like how the scala docs and the
> > > java docs are - using their own look and feel as a micro-site. I feel
> > > that this is the better approach for now.
> > >
> > > The PR for the Julia docs is here:
> > > https://github.com/apache/incubator-mxnet/pull/15454
> > >
> > > Ivy and I created several new issues to cover the broken links that
> > > will need fixing. Models that need to be recovered or recreated and
> > > uploaded to a new location. I have an s3 bucket that I've been using
> > > for some public assets like this, but I can't make progress on fixing
> > > those links when the models just don't exist. And I don't have the
> > > bandwidth to regenerate the model zoo and validate the models.
> > >
> > > Any thoughts or suggestions are appreciated.
> > > Happy 4th of July!
> > >
> > > [1] https://github.com/apache/incubator-mxnet/issues/15410
> > > [2] https://github.com/apache/incubator-mxnet/pull/15454
> > >
>

Re: [RESULTS] [VOTE] Release Apache MXNet (incubating) version 1.4.1.rc0

[Hen]

Noting that I am a belated +1 on the release.

I had one item regarding dataset licensing that I’d like to see improved
for the next release, but I don’t believe it would have been a blocker.

Hen

On Sat, May 4, 2019 at 00:00 Junru Shao  wrote:

> Dear MXNet community,
>
> I'm happy to announce the results of the vote.
>
> This vote passes with 12 +1 votes (3 binding), no 0 votes, and 1 -1 vote.
> +1 votes
> * Sheng Zha / binding
> * Qing Lan / binding
> * Carin Meier / binding
> * Aaron Markham
> * Pedro Larroy
> * Lai Wei
> * Damien Stanton
> * Kellen Sunderland
> * Yuxi Hu
> * Joshua Z. Zhang
> * Philip Hyunsu Cho
> * Aston Zhang
>
> 0 votes
> * No votes
>
> -1 votes
> * Anirudh Subramanian
>
> Vote thread can be found here [1]. The list of members can be found here
> [2].
>
> I'll continue with the release process and the release announcement will
> follow in the next few days.
>
> Best regards,
> Junru Shao
>
> [1]
>
> https://lists.apache.org/thread.html/6c140f4c180c259dd1b7f4ecf36f2d083ed810cd68b37d7f635f5614@%3Cdev.mxnet.apache.org%3E
> [2] http://incubator.apache.org/projects/mxnet.html
>

Re: [QUESTION] Release Apache MXNet (incubating) version 1.4.1.rc0

[Hen]

Thanks Sheng. I assume MNIST covers all 5 data files.

Given that's a license with stronger conditions than the Apache license, I
think the example should give a canonical URL for the data (i.e. a homepage
of some kind) and mention the CC-BY-SA-3.0 licensing.

Hen

On Wed, May 8, 2019 at 1:03 PM Sheng Zha  wrote:

> MNIST dataset is under CC BY-SA 3.0 and is widely redistributed.
>
>
> -sz
>
> On Wed, May 8, 2019 at 12:57 PM Hen  wrote:
>
> > Looking at
> > apache-mxnet-src-1.4.1.rc0-incubating/cpp-package/example/get_data.sh -
> > what's the license on the data that is being pulled in?
> >
> > Namely:
> >
> > "
> >
> >
> https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/mnist/train-images-idx3-ubyte.gz
> > "
> > "
> >
> >
> https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/mnist/train-labels-idx1-ubyte.gz
> > "
> > "
> >
> >
> https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/mnist/t10k-images-idx3-ubyte.gz
> > "
> > "
> >
> >
> https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/mnist/t10k-labels-idx1-ubyte.gz
> > "
> > "http://data.mxnet.io/data/mnist_train.csv.gz";
> >
> > Thanks,
> >
> > Hen
> >
> > On Mon, Apr 29, 2019 at 11:52 PM Junru Shao 
> > wrote:
> >
> > > Dear MXNet community,
> > >
> > > This is the 3-day vote to release Apache MXNet (incubating) version
> > v1.4.1.
> > > The voting on dev@ list will start Apr 29 23:59:59 (PST) and close on
> > May
> > > 02 23:59:59.
> > >
> > > Below are links to
> > > 1) Release notes:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.1+Release+Notes
> > > .
> > > 2) Release Candidate:
> > > https://github.com/apache/incubator-mxnet/releases/tag/1.4.1.rc0.
> > > 3) Source and signatures on Apache dist server:
> > > https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.1.rc0/.
> > >
> > > Please remember to TEST first before voting accordingly:
> > > +1 = approve
> > > +0 = no opinion
> > > -1 = disapprove (provide reason)
> > >
> > > Best regards,
> > > Junru Shao
> > >
> >
>

[QUESTION] Release Apache MXNet (incubating) version 1.4.1.rc0

[Hen]

Looking at
apache-mxnet-src-1.4.1.rc0-incubating/cpp-package/example/get_data.sh -
what's the license on the data that is being pulled in?

Namely:

"
https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/mnist/train-images-idx3-ubyte.gz
"
"
https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/mnist/train-labels-idx1-ubyte.gz
"
"
https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/mnist/t10k-images-idx3-ubyte.gz
"
"
https://apache-mxnet.s3-accelerate.dualstack.amazonaws.com/gluon/dataset/mnist/t10k-labels-idx1-ubyte.gz
"
"http://data.mxnet.io/data/mnist_train.csv.gz";

Thanks,

Hen

On Mon, Apr 29, 2019 at 11:52 PM Junru Shao  wrote:

> Dear MXNet community,
>
> This is the 3-day vote to release Apache MXNet (incubating) version v1.4.1.
> The voting on dev@ list will start Apr 29 23:59:59 (PST) and close on May
> 02 23:59:59.
>
> Below are links to
> 1) Release notes:
>
> https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28incubating%29+1.4.1+Release+Notes
> .
> 2) Release Candidate:
> https://github.com/apache/incubator-mxnet/releases/tag/1.4.1.rc0.
> 3) Source and signatures on Apache dist server:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.4.1.rc0/.
>
> Please remember to TEST first before voting accordingly:
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
> Best regards,
> Junru Shao
>

Re: [DISCUSS] Rebrand Gluon to MXNet imperative or something MXNet.

[Hen]

(well, the Amazon ping.  For the Apache ping, please share on @apache.org
email;*multiple-hat-syndrome*)

On Fri, Mar 29, 2019 at 11:44 AM Hen  wrote:

> Can you share that ping with me on our @amazon.com emails please Mu. I'd
> like to understand the context better.
>
> On Thu, Mar 28, 2019 at 2:08 PM Mu Li  wrote:
>
>> The name Gluon is originally used for a collaboration project between
>> Amazon and Microsoft [1].
>> I pinged both Apache and Amazon legal teams later, they confirmed Gluon is
>> not considered as a trademark.
>>
>> [1]
>>
>> https://aws.amazon.com/blogs/aws/introducing-gluon-a-new-library-for-machine-learning-from-aws-and-microsoft/
>>
>> On Thu, Mar 28, 2019 at 2:04 PM Isabel Drost-Fromm 
>> wrote:
>>
>> >
>> >
>> > Am 28. März 2019 21:53:16 MEZ schrieb Mu Li :
>> > >
>> > >The reason why we call it GluonCV instead of MXNetCV is because MXNet
>> > >is a
>> > >trademark owned by Apache, while Gluon doesn't have this issue.
>> >
>> > Who's the "we" in that sentence?
>> >
>> > If it doesn't belong to Apache, who owns the Gluon trademark?
>> >
>> > Isabel
>> >
>> >
>> > --
>> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>> >
>>
>

Re: [DISCUSS] Rebrand Gluon to MXNet imperative or something MXNet.

[Hen]

Can you share that ping with me on our @amazon.com emails please Mu. I'd
like to understand the context better.

On Thu, Mar 28, 2019 at 2:08 PM Mu Li  wrote:

> The name Gluon is originally used for a collaboration project between
> Amazon and Microsoft [1].
> I pinged both Apache and Amazon legal teams later, they confirmed Gluon is
> not considered as a trademark.
>
> [1]
>
> https://aws.amazon.com/blogs/aws/introducing-gluon-a-new-library-for-machine-learning-from-aws-and-microsoft/
>
> On Thu, Mar 28, 2019 at 2:04 PM Isabel Drost-Fromm 
> wrote:
>
> >
> >
> > Am 28. März 2019 21:53:16 MEZ schrieb Mu Li :
> > >
> > >The reason why we call it GluonCV instead of MXNetCV is because MXNet
> > >is a
> > >trademark owned by Apache, while Gluon doesn't have this issue.
> >
> > Who's the "we" in that sentence?
> >
> > If it doesn't belong to Apache, who owns the Gluon trademark?
> >
> > Isabel
> >
> >
> > --
> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >
>

Re: [DISCUSS] About the usage of CUDA/CUDNN

[Hen]

Please raise on legal-discuss or in a legal jira.

On Mon, Dec 17, 2018 at 3:59 PM Naveen Swamy  wrote:

> Attempting to answer Qing's question
> --
> If you can digest the legal terms:
> https://docs.nvidia.com/cuda/eula/index.html#distribution-requirements.
> It sounds its OK("
>
>1. Your application must have material additional functionality,
>beyond the included portions of the SDK.")
>
>  but I not don't understand the legal lingo
>
> @Hen  : Could you provide input to this?
>
> Thanks, Naveen
>
> On Mon, Dec 17, 2018 at 3:29 PM Davydenko, Denis <
> dzianis.davydze...@gmail.com> wrote:
>
>> Kellen, please see conversation [1] on previously published proposal re:
>> maven publishing pipeline. I think your concerns are valid and we should
>> look into security aspect of running our CI on a broader scope, not bound
>> to just artifact publishing.
>>
>> I believe right now Qing's question is whether it is OK from legal
>> perspective to download CUDA by literally running wget during one of the
>> jobs in publishing pipeline. The fact it is not available by just simple
>> URL download raises concern: whether it is a protective measure from
>> downloads by unauthenticated users or just inconvenience that has not been
>> addressed by nVidia yet.
>>
>> [1]:
>> https://lists.apache.org/thread.html/464712f0136fb51916ca9f1b702b99847e108dbdbd0b6a2b73fc91f1@%3Cdev.mxnet.apache.org%3E
>>
>>
>> On 12/17/18, 2:48 PM, "kellen sunderland" 
>> wrote:
>>
>> Restricted nodes may provide enough security for some use cases, but
>> in my
>> opinion they don't provide enough for artifact publishing. An example
>> would
>> be if there were a exploit available that worked against a Jenkins
>> master.
>> In this case I think an attacker code still pivot to a secure node
>> (correct
>> me if I'm wrong).
>>
>> To your second point, it shouldn't be too hard for us to maintain all
>> the
>> deps for our packages in Dockerfiles which are checked into source and
>> built on a regular basis.  To publish these artifacts I'd recommend
>> doing
>> this from a separate, secure environment.  The flow I'd recommend
>> would be
>> something like: (1) Developers commit PRs with verification that the
>> artifacts build properly on a continual basis from the CI. (2) In a
>> separate, secure environment we do the same artifact build generation
>> again, but this time we publish to various repos as a convenience to
>> our
>> MXNet users.
>>
>> On Mon, Dec 17, 2018 at 2:34 PM Qing Lan  wrote:
>>
>> > Hi Kellen,
>> >
>> > Firstly the restricted node is completely isolated to the
>> PR-checking CI
>> > system (physically) which is explained in here:
>> >
>> https://cwiki.apache.org/confluence/display/MXNET/Restricted+jobs+and+nodes
>> > .
>> > What you are mentioning: the Public CIs are all having troubles if
>> they
>> > are public accessible. I am not sure how secure the restricted node
>> is.
>> > However, the only way I can think of from your end is to
>> downloading all
>> > deps in a single machine and run everything there (disconnected from
>> > internet). It would bring us the best security we have.
>> >
>> > Thanks,
>> > Qing
>> >
>> > On 12/17/18, 2:06 PM, "kellen sunderland" <
>> kellen.sunderl...@gmail.com>
>> > wrote:
>> >
>> > I'm not in favour of publishing artifacts from any Jenkins based
>> > systems.
>> > There are many ways to bundle artifacts and publish them from an
>> > automated
>> > system.  Why we would use a CI system like Jenkins for this
>> task?
>> > Jenkins
>> > frequently has security vulnerabilities and is designed to run
>> > arbitrary
>> > code from the internet.  It is a real possibility that an
>> attacker
>> > could
>> > pivot from any Jenkins based CI system to infect artifacts
>> which would
>> > then
>> > potentially be pushed to repositories our users would consume.
>> I would
>> > consider any system using Jenkins as insecure-by-design, and
>> encourage
>> > us
>> > to air-gapped any artifact gener

Re: Create a Jira board for C/C++ API project

[Hen]

Opened: https://issues.apache.org/jira/browse/INFRA-17128

On Fri, Oct 5, 2018 at 11:45 AM Naveen Swamy  wrote:

> Thanks for making the effort to bring tasks and feature improvements under
> a managed boards in JIRA.  This will help in users/contributors to quickly
> look through the stories/tasks and contribute to the project that they are
> interested in.
>
> We were able to create JIRA boards/filter and share it across the project
> earlier. since the last few months I am unable to share the boards that I
> create with the project( there was possibly an upgrade to JIRA that removed
> access).  Now it looks like it needs global permission to create shared
> boards and filter.[1]
>
> We will need to create ticket to Apache INFRA to grant access. Can one of
> the mentors help create INFRA ticket?
>
> [1]
>
> https://confluence.atlassian.com/adminjiracloud/managing-global-permissions-776636359.html
>
> Thanks, Naveen
>
> On Fri, Oct 5, 2018 at 11:14 AM Davydenko, Denis <
> dzianis.davydze...@gmail.com> wrote:
>
> > Hello, MXNet community,
> >
> >
> >
> > As part of mine and couple of my team mates day job we are working on
> > contributing towards C++ and C APIs that MXNet exposes. We would like to
> > propose to create a separate board in jira in order to make it easier to
> > track work around MXNet C/C++ APIs. Very similar to
> > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=211
> > (which we are using for managing development of Scala and Java APIs) but
> > bound to show C/C++ sprints and work items. This will also give a better
> > exposure to C/C++ API work for users to be aware of where these APIs
> moving
> > as well as will make it easier to manage work on those APIs between
> > multiple contributors.
> >
> >
> >
> > --
> >
> > Thanks,
> >
> > Denis
> >
> >
>

Mentor changes

[Hen]

I'd like to welcome four additional mentors (cc'd) for MXNet :)

 * Jason Dai;
 * Jim Jagielski;
 * Bob Paulin; and
 * Michael Wall.

Suneel Marthi has also stepped back from mentoring.

Thank you to each of our new mentors for joining in, and many thanks to
Suneel for the time he's given over the last 2 years.

Hen

Re: Request for feedback: proposal for MXNet SDK Office hours

[Hen]

Noting that, as far as I can tell, there is no such thing as 'MXNet SDK',
'AWS MXNet SDK' or 'Amazon MXNet SDK'.

On Wed, Jul 18, 2018 at 2:30 PM, Mu Li  wrote:

> A minor suggestion: rename MXNet SDK to AWS MXNet SDK or Amazon MXNet SDK.
>
> On Wed, Jul 18, 2018 at 2:22 PM, Davydenko, Denis <
> dzianis.davydze...@gmail.com> wrote:
>
> > Hello, MXNet community,
> >
> > Following up on recent announcement of office hours introduction from
> > MXNet Berlin team,  we are trying to see if we can introduce some
> > modifications to that to make process a bit more streamlined and easier
> to
> > track. Also, we are trying to see how to scale that process to allow
> other
> > MXNet teams to provide this channel of support to their customers. With
> > that in mind, I would like to ask for your feedback on the proposal [1].
> >
> > [1] https://cwiki.apache.org/confluence/display/MXNET/
> > PROPOSAL%3A+MXNet+SDK+Office+Hours
> >
> >
> >
>

Re: Request for feedback: proposal for MXNet SDK Office hours

[Hen]

My concerns on Office Hours are:

1) Voice and F2F are not very welcoming for a diverse community. There I
am, sitting in New Zealand, and you want me to get on the phone and wake up
the rest of the family to have a conversation. Or get on a plane.
2) Having to book time is also not very welcoming. I would expect the
booking time notion to happen because too many requests for help are
happening and it's not possible to handle them all; or because no one ever
shows up (in which case congrats, free time for the committers to chat
about ideas - provided it doesn't stop people asking for help).

Have you tried the more classic Open Source approach of a specific time on
an IM channel to discuss? Apache often uses IRC (irc.freenode.net).

Hen



On Mon, Jul 23, 2018 at 7:36 PM, Naveen Swamy  wrote:

> Hey All, just created a INFRA ticket(https://issues.apache.o
> rg/jira/browse/INFRA-16805)  requesting a new Issue Type "Office Hours" on
> JIRA to better manage and support Office hours request.
>
> One feedback I received was that  "Apache" was neither mentioned in the
> discussion nor in the PROPOSAL on the wiki. This is a valid feedback and I
> have fixed the PROPOSAL.
> I propose the office hours under discussion should be explicitly called
> "Apache MXNet Office hours".
>
> Also, Apache INFRA asked to create INFRA tickets only through mentors
>
> Can one of the mentors kindly help take this ticket forward.
>
> Thanks, Naveen
>
>
>
>
> On Thu, Jul 19, 2018 at 10:01 AM, Pedro Larroy <
> pedro.larroy.li...@gmail.com
> > wrote:
>
> > Yes Naveen, I think you are saying exactly the same as I hinted. Sheng
> also
> > agreed with this.
> >
> > Pedro.
> >
> > On Thu, Jul 19, 2018 at 6:54 PM Naveen Swamy  wrote:
> >
> > > I do not think there needs to be a distinction made for
> > > support/office-hours by committer or contributors(in this case Amazon
> > > employed contributors) -- correct me if I misunderstood your guess :).
> > > Like I said, I would rather call it MXNet Office hours and categorize
> the
> > > kind of support that is offered, we might be able to find contributors
> > > willing to do this in different parts of the world regardless of their
> > day
> > > job or not.
> > >
> > > On Thu, Jul 19, 2018 at 9:21 AM, Sheng Zha  wrote:
> > >
> > > > I'm guessing Mu's intention is to make it clear that such invitation
> is
> > > > extended by teams in Amazon/AWS instead of by committers, so as to
> > avoid
> > > > the confusion of the naming "MXNet SDK". Suggestions to achieve the
> > same
> > > > goal are welcome.
> > > >
> > > > Best regards,
> > > > -sz
> > > >
> > > > On Thu, Jul 19, 2018 at 9:09 AM, Isabel Drost-Fromm <
> isa...@apache.org
> > >
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > On 18/07/18 23:30, Mu Li wrote:
> > > > >
> > > > >> A minor suggestion: rename MXNet SDK to AWS MXNet SDK or Amazon
> > MXNet
> > > > SDK.
> > > > >>
> > > > >
> > > > > What exactly is the Amazon MXNet SDK? What is the AWS MXNet SDK?
> > > > >
> > > > > Your suggestion triggered my question because:
> > > > >
> > > > > https://www.apache.org/foundation/marks/#products
> > > > >
> > > > >
> > > > > Isabel
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: MXNet Berlin Office Hours

[Hen]

Noting that I find "MXNet Berlin team" a very confusing concept.

Does that mean "Apache MXNet committers who happen to live in Berlin?"

On Mon, Jul 16, 2018 at 2:27 AM, Anton Chernov  wrote:

> Dear MXNet community,
>
> As part of our customer support the MXNet Berlin team is offering office
> hours on Tuesdays 6pm-7pm (CEST) | 9:00am-10am (PST).
>
> They happen onsite in the Amazon Berlin office:
> Krausenstraße 38, 10117 Berlin in BER12 01.501
>
> Conference Bridge Information
>
> Chime meeting ID: 5461650798
> Join via browser screen share: https://chime.aws/5461650798
> Join via phone (US): +1-929-432-4463,,5461650798#
> Join via phone (US toll-free): +1-855-552-4463,,5461650798#
> International dial-in: https://chime.aws/dialinnumbers/
> In-room video system: Ext: 62000, Meeting PIN: 5461650798#
>
> How can we help you?
>
> The following are a few examples of the types of consultations we provide:
>
> * CI and infrastructure questions
> * Build system
> * Benchmarking
> * Edge devices (for example Raspberry Pi, Jetson)
> * C++
> * General questions
>
> Before attending
>
> Try finding answers on:
>
> * Our discussion forum (https://discuss.mxnet.io)
> * StackOverflow mxnet tag (https://stackoverflow.com/
> questions/tagged/mxnet)
> * MXNet website (https://mxnet.incubator.apache.org/faq/)
> * Github issues (https://github.com/apache/incubator-mxnet/issues)
>
> If this does not help:
>
> In advance fill out a github issue (
> https://github.com/apache/incubator-mxnet/issues/new) at least a few days
> before so that the team member who will help with the issue gets a chance
> to prepare.
>
> Main point of contact through email: mxnet-edge-oncall-primary[at]a
> mazon.com
>
> Best regards
> Anton Chernov
>
> [1]
> https://cwiki.apache.org/confluence/display/MXNET/
> MXNet+Berlin+Office+Hours
>

Re: [DISCUSSION] Initial draft for MXNet roadmap

[Hen]

Roadmaps are interesting in a project with a high level of commit-in-dayjob
employment.

Some opinions for my part:

* Roadmaps should be release and not time based. We might have an intent to
release every X months but the roadmap should still be focused on that
release rather than the X months.
** The exception is operational items. Fixing CI, updating website etc; for
these I would have an Operational section and indicate priority and/or
whether they affect release.
* Roadmaps should be wishlists. Items for the V.Next release would either
be Required or Nice to Have. Nice to Haves can (and should) be punted to
the next release by the RM if the Requireds are all resolved.
* Items can be identified as someone having an intent to work on. For
example, as Steffen manages various folk contributing to MXNet, I imagine
he has particular contributions he would like them to work on and is making
time available in the day for that to happen. Ideally the folk he manages
would note that they have the intent rather than it being a borglike
'Amazon' next to it.
** It's important to leave lots of open work, including small items.
** It's important not to continually punt Nice to Haves small items to the
next release. ie: At the start of the roadmap there are a bunch of newbie
items, and then as you get to release stage the existing committers take
care of a large chunk of newbie items.

My tuppence :)

Hen



On Wed, Jul 4, 2018 at 11:05 AM, Steffen Rochel 
wrote:

> As a project contributor, I published an initial draft for MXNet roadmap
> at  https://cwiki.apache.org/confluence/display/MXNET/MXNet+Roadmap
> The initial draft is based on offline discussion with various contributors
> and committers including Mu, Junyuan and AWS developer community.
>
> Please review and suggest changes and enhancements.
> Please also review https://spark.apache.org/improvement-proposals.html and
> share your thoughts if the project should adopt a similar process or
> suggest something you think is more appropriate.
>
> Regards,
> Steffen
>

Re: Abandoned MXNet readthedocs site

[Hen]

I’ve Twitter DM’d one of the core members of ReadTheDocs asking for help.

On Thu, Jul 5, 2018 at 8:43 AM Chris Mattmann  wrote:

> Hi Hen happy 4th looks like a brand mgmt. topic to me…
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> From: Hen 
> Reply-To: 
> Date: Tuesday, July 3, 2018 at 10:44 AM
> To: 
> Cc: "legal-disc...@apache.org" 
> Subject: Re: Abandoned MXNet readthedocs site
>
>
>
> Chris/Mark - is this a Legal (Chris) topic or a Brand Management (Mark)
>
> topic?
>
>
>
> I’m hesitant to use a Trademark C&D for what’s in effect a lost account,
>
> but that’s what readthedocs seem to be asking for.
>
>
>
> On Mon, Jun 25, 2018 at 3:15 PM Markham, Aaron  >
>
> wrote:
>
>
>
> Hi, just bumping this issue again. Can we get a trademark C&D sent to the
>
> readthedocs folks, so they'll go ahead and remove the derelict website?
>
> It's still the #4 result in Google for "mxnet install".
>
>
>
> What's Apache's process?
>
>
>
> Thanks,
>
> Aaron
>
>
>
> On 5/16/18, 8:20 AM, "Hen"  wrote:
>
>
>
>  It seems we (Apache MXNet) have an old documentation site posted at:
>
>
>
>  https://newdocs.readthedocs.io/en/latest/
>
>
>
>  and only the absent @Awyan has the permissions to the site. See
>
>  https://github.com/apache/incubator-mxnet/issues/10409 for more
>
> details.
>
>
>
>  Raising this with readthedocs.org, we've been asked to submit a DMCA
>
>  request to take down the account:
>
>
>
>  https://github.com/rtfd/readthedocs.org/issues/4042
>
>
>
>  Given our docs are Apache licensed I suspect it's really a trademark
>
>  takedown (confused users etc). Does anyone here have any guidance with
>
> this
>
>  situation? Has anyone had this issue with readthedocs before? Should
>
> we be
>
>  sending them a Trademark takedown request?
>
>
>
>  Thanks,
>
>
>
>  Hen
>
>
>
>
>
>
>
>
>
>

Re: Abandoned MXNet readthedocs site

[Hen]

Makes sense (sorry - got my memory switched on the trademark/dmca aide of
things).

I’ll see on members to see if anyone has a connection to readthedocs.

On Tue, Jul 3, 2018 at 1:00 PM Mark Thomas  wrote:

> On 03/07/18 18:44, Hen wrote:
> > Chris/Mark - is this a Legal (Chris) topic or a Brand Management (Mark)
> > topic?
>
> Personally, I would not be prepared to sign a DMCA for this without
> legal advice. Even then I may not.
>
> Section 2 of the ALv2 effectively authorises this particular use.
>
> DMCA take down notices require a statement that the use is unauthorised.
>
> Signatories are required to declare, under penalty of perjury, that the
> take down notice is true and correct.
>
>
> I would hope that a readthedocs core maintainer would be able to resolve
> this. The abandoned project process also looks like an option - and
> would allow the project to benefit from serving current docs at what
> appears to be a popular place to look for them.
>
> Mark
>
>
> >
> > I’m hesitant to use a Trademark C&D for what’s in effect a lost account,
> > but that’s what readthedocs seem to be asking for.
> >
> > On Mon, Jun 25, 2018 at 3:15 PM Markham, Aaron
> >  wrote:
> >
> > Hi, just bumping this issue again. Can we get a trademark C&D sent
> > to the readthedocs folks, so they'll go ahead and remove the
> > derelict website? It's still the #4 result in Google for "mxnet
> > install".
> >
> > What's Apache's process?
> >
> > Thanks,
> > Aaron
> >
> > On 5/16/18, 8:20 AM, "Hen"  > <mailto:bay...@apache.org>> wrote:
> >
> > It seems we (Apache MXNet) have an old documentation site posted
> at:
> >
> > https://newdocs.readthedocs.io/en/latest/
> >
> > and only the absent @Awyan has the permissions to the site. See
> > https://github.com/apache/incubator-mxnet/issues/10409 for more
> > details.
> >
> > Raising this with readthedocs.org <http://readthedocs.org>,
> > we've been asked to submit a DMCA
> > request to take down the account:
> >
> > https://github.com/rtfd/readthedocs.org/issues/4042
> >
> > Given our docs are Apache licensed I suspect it's really a
> trademark
> > takedown (confused users etc). Does anyone here have any
> > guidance with this
> > situation? Has anyone had this issue with readthedocs before?
> > Should we be
> > sending them a Trademark takedown request?
> >
> > Thanks,
> >
> > Hen
> >
> >
>
>

Re: Abandoned MXNet readthedocs site

[Hen]

Chris/Mark - is this a Legal (Chris) topic or a Brand Management (Mark)
topic?

I’m hesitant to use a Trademark C&D for what’s in effect a lost account,
but that’s what readthedocs seem to be asking for.

On Mon, Jun 25, 2018 at 3:15 PM Markham, Aaron 
wrote:

> Hi, just bumping this issue again. Can we get a trademark C&D sent to the
> readthedocs folks, so they'll go ahead and remove the derelict website?
> It's still the #4 result in Google for "mxnet install".
>
> What's Apache's process?
>
> Thanks,
> Aaron
>
> On 5/16/18, 8:20 AM, "Hen"  wrote:
>
> It seems we (Apache MXNet) have an old documentation site posted at:
>
> https://newdocs.readthedocs.io/en/latest/
>
> and only the absent @Awyan has the permissions to the site. See
> https://github.com/apache/incubator-mxnet/issues/10409 for more
> details.
>
> Raising this with readthedocs.org, we've been asked to submit a DMCA
> request to take down the account:
>
> https://github.com/rtfd/readthedocs.org/issues/4042
>
> Given our docs are Apache licensed I suspect it's really a trademark
> takedown (confused users etc). Does anyone here have any guidance with
> this
> situation? Has anyone had this issue with readthedocs before? Should
> we be
> sending them a Trademark takedown request?
>
> Thanks,
>
> Hen
>
>
>

Re: Reverting pull request

[Hen]

Please all go read: https://www.apache.org/foundation/policies/conduct.html

* Be open.
* Be empathetic, welcoming, friendly, and patient.
* Be collaborative.
* Be inquisitive.
* Be careful in the words that you choose.

I'm not seeing evidence of this right now.

Hen

Re: About Becoming a Committer

[Hen]

That wasn't what I was trying to say (I'll try again - tis late and I'm
sure I'm speaking poorly :) ).

It says:

"When it comes to code contributions, quality is more important than
quantity. While all contributions are welcome and highly appreciated,
certain guidelines will be applied when it comes to committer nominations,
e.g. clean, documented and maintainable code, including unit tests if
applicable. Updating license text or fixing indentation in hundreds of
source files for instance is case of quantity trumping quality. "

If someone is updating licensing text, or fixing indentation, then that is
great. That's as good as someone who wrote a lump of clean, documented and
maintainable code with unit tests. The important part isn't the patch, it's
how much back and forth there had to be to get the patch to the point where
it could be merged.

My concern, and I feel the language on the page reflects this, is that one
commit is rated higher than a different commit with regards to showing
commitment. That's wrong imo. All commits are equal (as are any other
actions for the project, such as answering a question, improving wiki,
maintaining CI, helping people on Slack). Becoming a committer is about the
trust built up by the committers not having to modify the action (PR,
proposed-answer, proposed-wiki-change etc).

Hen

On Fri, Jun 15, 2018 at 12:26 AM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> Hen,
>
> As you stated, it's of significance of how much a PR has to be changed as a
> result of a review. I think this is what this project defines as quality.
>
> If people submit a bunch of PRs and we reviewers spend a lot of time on
> every single one of them to give the contributors advice about how to do it
> the right way, then that's a great contribution but doesn't really show
> that the person is either up par with the standards of the project or
> understood the design principles. In both cases they added value to the
> project, but the bar would have been lowered if the reviewers didn't
> intercept. Of course, there is always something people will have to
> criticize as part of the review and that's natural. But what you are
> describing here is basically that we should make people committers because
> of the amount of value they added through the code.
>
> While that's a good way to look at it in general, it doesn't consider
> important aspects: how much of this value has been added by the reviewer?
> And what happens if that person starts merging  other PRs. If a person who
> is not up par with the standards of the project is granted permission to
> merge pull requests and they merge them prematurely because they don't know
> that things are wrong, then this is harming the project in the long term.
> If more and more people with lower standards are granted permissions, we
> will enter a downwards spiral.
>
> That's why I have to disagree that it's not about how often a PR has been
> merged but rather about how often it has to be altered as result of our
> reviews.
>
> -Marco
>
> Hen  schrieb am Fr., 15. Juni 2018, 00:00:
>
> > On the 'Becoming+a+Committer' guidelines, I dislike this phrase:
> >
> > "When it comes to code contributions, quality is more important than
> > quantity"
> >
> > There is only one 'quality' measurement, and that is "was the code
> merged".
> > If someone makes 10 different contributions and they were all horrible
> and
> > never merged (or the merger had to write a ton of fixes/tests/additions)
> > then yes, that's a pretty bad sign.
> >
> > If the code was merged; I don't care if it's stunning code or an inspired
> > design. It was merged. This isn't a technical promotion process, this is
> > about whether the individual has shown the commitment to be extended the
> > trust to manage commits.
> >
> > So; -1 to quality being more important than quantity. It's not.
> >
> > Hen
> >
> >
> >
> > On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha  wrote:
> >
> > > Hi,
> > >
> > > There have been a couple of offline inquiries from contributors about
> > > becoming a committer. From those inquiries, it seems that there’s
> > confusion
> > > in our community about how to become a committer, so I’d like to take
> > this
> > > opportunity to clarify.
> > >
> > > The guideline about becoming a committer can be found at
> > > https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
> .
> > > The
> > > gist of the guideline is that, like any o

Re: About Becoming a Committer

[Hen]

On the 'Becoming+a+Committer' guidelines, I dislike this phrase:

"When it comes to code contributions, quality is more important than
quantity"

There is only one 'quality' measurement, and that is "was the code merged".
If someone makes 10 different contributions and they were all horrible and
never merged (or the merger had to write a ton of fixes/tests/additions)
then yes, that's a pretty bad sign.

If the code was merged; I don't care if it's stunning code or an inspired
design. It was merged. This isn't a technical promotion process, this is
about whether the individual has shown the commitment to be extended the
trust to manage commits.

So; -1 to quality being more important than quantity. It's not.

Hen



On Fri, Jun 8, 2018 at 1:15 PM, Sheng Zha  wrote:

> Hi,
>
> There have been a couple of offline inquiries from contributors about
> becoming a committer. From those inquiries, it seems that there’s confusion
> in our community about how to become a committer, so I’d like to take this
> opportunity to clarify.
>
> The guideline about becoming a committer can be found at
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer.
> The
> gist of the guideline is that, like any other Apache project, MXNet
> committers are invited by existing committers based on merit. The existing
> committers look for sustained, high quality contribution and community
> involvement among project contributors. When a candidate is spotted, this
> contributor will be nominated and voted among PMC members, and if all goes
> well, this contributor will receive an invitation to join as a committer
> and PMC member.
>
> Note that such discussion and decision happens in private among existing
> PMC members and mentors through consensus, and information regarding what
> happened in this process will always remain private, so as to rid the
> influence of different interest groups. PMC members will not ask
> contributors for committer application, nor will they accept one. Except
> the aforementioned PMC members consensus process, any other process by any
> organization under any circumstances will not be recognized.
>
> I hope that you find the above clarification helpful. If you have further
> question on this topic feel free to ask.
>
> Sheng
>

Re: About Becoming a Committer

[Hen]

On Tue, Jun 12, 2018 at 10:54 PM, Pedro Larroy  wrote:

> * I personally don't like the idea that comittership status is decided in a
> closed mail list. This is not the transparency level that I would expect in
> an open source project. I'm happy to receive feedback from others that
> might be opposed to my application for committer to know what things could
> be improved to get there. I have been doing a plethora of contributions to
> the project over a year including ARM support, Android and CI, obviously
> some of this work together with my team at Amazon (@lebeg,
> @KellenSunderland, @marcoabreu). I don't have visibility on how much longer
> one has to wait, or what needs to be improved to get there.
>

I agree in principle (which means I'm going to disagree, right? :) ).

Ideally discussion about extending community trust would be made in public,
however for many of us having that discussion in public is an uncomfortable
act. A private channel for feedback is not about hiding information from
the subject, but about creating a safe place in which someone can provide
that feedback.

I think you have a very valid and, slightly to the side, point of it not
being clear what steps are needed/remaining to become a committer; which is
affected by the podling pmc still seeking consensus on how they view it.


>
> * My team is on-call for CI / CD which is also sponsored by us. To fix
> problems promptly we would need write permissions to the repository. This
> would normal in any other project, be open source or corporate. I think
> it's not effective to be on-call when you can't submit critical fixes and
> wait days for a CR. Basically I think everyone responsible or involved in
> CI should have access rights. As you know, testing our project is a
> challenging task for reasons discussed before.
>

Personally I don't care. If the committers aren't handling the CI/CD then
it's not important to the project. It's EXCELLENT that you and your team
are contributing your time to run CI/CD for the project, but the notion
that an open source project requires an on-call CI/CD is, in my opinion,
the project having its priorities skewed. However, that said, I agree that
if the project is unable to survive without the CI/CD, then it sounds far
more important than whatever code is being committed and shows more
commitment to the project than the creator of a piece of code.

I'm pretty sure my opinion that the CI/CD is not crucial is heretical for
this community. I suspect that if I said we should turn it off for a week
there would be a wailing and gnashing of teeth from every corner of the
mailing list. Given that, I think you earn more 'become committer points'
by maintaining that CI/CD than someone does by coding.


> Please committers and mentors, provide a solution that allows us to work
> more effectively and move the project forward faster, as is vital to make
> it easier to contribute so we can attract more users.
>

+1. The podling pmc needs to find consensus on the become-committer stage.

Hen

Re: GitHub Label Bot Design

[Hen]

Thanks Cathy.

As a high level concept, scripts the project depends on should be committed
to the project (I say this more as a note for everyone rather than calling
you out specifically :) ).

Hen

On Thu, Jun 14, 2018 at 9:31 PM, Yuelin Zhang 
wrote:

> Hi Hen,
>
> I am not using probot. Now my bot code is running in a AWS lambda function.
> I will ask my manager and my mentors about where will the bot code be
> committed.
>
>
> Thanks,
> Cathy
>
> On Wed, Jun 13, 2018 at 8:09 AM, Hen  wrote:
>
> > Where will the bot code be committed?
> >
> > Are you using probot?
> >
> > On Tue, Jun 12, 2018 at 2:21 PM Marco de Abreu <
> > marco.g.ab...@googlemail.com>
> > wrote:
> >
> > > Hello Cathy,
> > > that's a great proposal. Thank you!
> > >
> > > A few comments from my side:
> > > - Good idea with the alias. We should have a special email-list for
> > > automated reports to prevent spamming dev@.
> > > - "Create weekly email to internal team members:" -> email-list
> > > - "Part II - Label Bot - Amazon cloudwatch event (a) will trigger
> lambda
> > > function(a) 9am every Monday. " -> Why don't we try to classify them
> > ASAP?
> > > - "This bot should have restricted permissions to avoid unexpected
> > > operations." -> AFAIK, Apache does not allow bot accounts and we have
> to
> > > use a committers credentials instead. This is not a big issue since we
> > > already do this, but just to keep that in mind.
> > >
> > > Best regards,
> > > Marco
> > >
> > > On Tue, Jun 12, 2018 at 1:07 PM Yuelin Zhang <
> zhangyuelinch...@gmail.com
> > >
> > > wrote:
> > >
> > > > Sorry for the messed up url format.
> > > > Please forward to this link: https://tinyurl.com/mxnetbot
> > > >
> > > >
> > > > Thanks,
> > > > Cathy
> > > >
> > > >
> > > > On Tue, Jun 12, 2018 at 10:20 AM, Yuelin Zhang <
> > > zhangyuelinch...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Currently there are many issues on Incubator-MXNet
> > > > > <https://github.com/apache/incubator-mxnet> repo, labeling issues
> > can
> > > > > drive attention of  contributors to specific areas. Right now,
> issues
> > > are
> > > > > all manually labelled, which is time consuming.  And every time
> > > > maintainers
> > > > > need to @ a committer to add labels.
> > > > > I am working on this label bot to automate/simplify this labeling
> > issue
> > > > > process and send weekly report to maintainers. Design proposal is
> on
> > > > cwiki:
> > > > > https://cwiki.apache.org/confluence/display/MXNET/Deep+Learn
> > > > > ing+Based+GitHub+Label+Bot
> > > > >
> > > > > Please feel free to let me know if you have
> suggestions/requirements/
> > > > > expectations.
> > > > >
> > > > > Thanks,
> > > > > Cathy
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: GitHub Label Bot Design

[Hen]

Where will the bot code be committed?

Are you using probot?

On Tue, Jun 12, 2018 at 2:21 PM Marco de Abreu 
wrote:

> Hello Cathy,
> that's a great proposal. Thank you!
>
> A few comments from my side:
> - Good idea with the alias. We should have a special email-list for
> automated reports to prevent spamming dev@.
> - "Create weekly email to internal team members:" -> email-list
> - "Part II - Label Bot - Amazon cloudwatch event (a) will trigger lambda
> function(a) 9am every Monday. " -> Why don't we try to classify them ASAP?
> - "This bot should have restricted permissions to avoid unexpected
> operations." -> AFAIK, Apache does not allow bot accounts and we have to
> use a committers credentials instead. This is not a big issue since we
> already do this, but just to keep that in mind.
>
> Best regards,
> Marco
>
> On Tue, Jun 12, 2018 at 1:07 PM Yuelin Zhang 
> wrote:
>
> > Sorry for the messed up url format.
> > Please forward to this link: https://tinyurl.com/mxnetbot
> >
> >
> > Thanks,
> > Cathy
> >
> >
> > On Tue, Jun 12, 2018 at 10:20 AM, Yuelin Zhang <
> zhangyuelinch...@gmail.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > Currently there are many issues on Incubator-MXNet
> > >  repo, labeling issues can
> > > drive attention of  contributors to specific areas. Right now, issues
> are
> > > all manually labelled, which is time consuming.  And every time
> > maintainers
> > > need to @ a committer to add labels.
> > > I am working on this label bot to automate/simplify this labeling issue
> > > process and send weekly report to maintainers. Design proposal is on
> > cwiki:
> > > https://cwiki.apache.org/confluence/display/MXNET/Deep+Learn
> > > ing+Based+GitHub+Label+Bot
> > >
> > > Please feel free to let me know if you have suggestions/requirements/
> > > expectations.
> > >
> > > Thanks,
> > > Cathy
> > >
> > >
> > >
> >
>

Re: [GitHub] szha closed pull request #11154: Revert "[MXNET-503] Website landing page for MMS (#11037)"

[Hen]

It wasn't clear why this was commit was reverted. Things that stood out as
odd:

* I didn't see an email to dev@ on the topic of a revert.
* Rather than reverting, if there is a minor item requiring a fix it could
simply be fixed; if a major item then it should be raised on dev@.
* I didn't see a reason to revert in the revert PR (11154).
* The original PR has github:szha asking for github:piiswrong to review
with no context; I'm concerned that it was implied that the commit could
not go in without this review.
* I don't see anything in the original PR to earn a revert. At best
'github:john-andrilla' being asked if "a flexible, scalable,
multi-framework serving solution" was okay.
* I find it odd that github:lupesko is a reviewer.

Hen



On Tue, Jun 5, 2018 at 5:08 PM, GitBox  wrote:

> szha closed pull request #11154: Revert "[MXNET-503] Website landing page
> for MMS (#11037)"
> URL: https://github.com/apache/incubator-mxnet/pull/11154
>
>
>
>
> This is a PR merged from a forked repository.
> As GitHub hides the original diff on merge, it is displayed below for
> the sake of provenance:
>
> As this is a foreign pull request (from a fork), the diff is supplied
> below (as it won't show otherwise due to GitHub magic):
>
> diff --git a/docs/mms/index.md b/docs/mms/index.md
> deleted file mode 100644
> index ff6edae414b..000
> --- a/docs/mms/index.md
> +++ /dev/null
> @@ -1,114 +0,0 @@
> -# Model Server for Apache MXNet (incubating)
> -
> -[Model Server for Apache MXNet (incubating)](https://github.
> com/awslabs/mxnet-model-server), otherwise known as MXNet Model Server
> (MMS), is an open source project aimed at providing a simple yet scalable
> solution for model inference. It is a set of command line tools for
> packaging model archives and serving them. The tools are written in Python,
> and have been extended to support containers for easy deployment and
> scaling. MMS also supports basic logging and advanced metrics with Amazon
> CloudWatch integration.
> -
> -
> -## Multi-Framework Model Support with ONNX
> -
> -MMS supports both *symbolic* MXNet and *imperative* Gluon models. While
> the name implies that MMS is just for MXNet, it is in fact much more
> flexible, as it can support models in the [ONNX](https://onnx.ai) format.
> This means that models created and trained in PyTorch, Caffe2, or other
> ONNX-supporting frameworks can be served with MMS.
> -
> -To find out more about MXNet's support for ONNX models and using ONNX
> with MMS, refer to the following resources:
> -
> -* [MXNet-ONNX Docs](../api/python/contrib/onnx.md)
> -* [Export an ONNX Model to Serve with MMS](https://github.com/
> awslabs/mxnet-model-server/docs/export_from_onnx.md)
> -
> -## Getting Started
> -
> -To install MMS with ONNX support, make sure you have Python installed,
> then for Ubuntu run:
> -
> -```bash
> -sudo apt-get install protobuf-compiler libprotoc-dev
> -pip install mxnet-model-server
> -```
> -
> -Or for Mac run:
> -
> -```bash
> -conda install -c conda-forge protobuf
> -pip install mxnet-model-server
> -```
> -
> -
> -## Serving a Model
> -
> -To serve a model you must first create or download a model archive. Visit
> the [model zoo](https://github.com/awslabs/mxnet-model-server/
> docs/model_zoo.md) to browse the models. MMS options can be explored as
> follows:
> -
> -```bash
> -mxnet-model-server --help
> -```
> -
> -Here is an easy example for serving an object classification model. You
> can use any URI and the model will be downloaded first, then served from
> that location:
> -
> -```bash
> -mxnet-model-server \
> -  --models squeezenet=https://s3.amazonaws.com/model-server/
> models/squeezenet_v1.1/squeezenet_v1.1.model
> -```
> -
> -
> -### Test Inference on a Model
> -
> -Assuming you have run the previous `mxnet-model-server` command to start
> serving the object classification model, you can now upload an image to its
> `predict` REST API endpoint. The following will download a picture of a
> kitten, then upload it to the prediction endpoint.
> -
> -```bash
> -curl -O https://s3.amazonaws.com/model-server/inputs/kitten.jpg
> -curl -X POST http://127.0.0.1:8080/squeezenet/predict -F
> "data=@kitten.jpg"
> -```
> -
> -The predict endpoint will return a prediction response in JSON. It will
> look something like the following result:
> -
> -```
> -{
> -  "prediction": [
> -[
> -  {
> -"class": "n02124075 Egyptian cat",
> -"probability": 0.9408261179924011
> -  },
> -...
> -```
> -
> -For more examples of se

Re: Vote to stop using JIRA

[Hen]

Are you saying only committers can make JIRA accounts?

On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:

> + 0
> Can we keep this optional? Not totally abandon or support.
> Pros:
> I used JIRA to track most of my PRs and can place them together at one
> place. It also being helpful if we find some issues and group them together
> as one case.
> Cons:
> Currently JIRA does not allow someone who is not contributor to file an
> issue which makes first-time contributor hard to submit a PR.
>
> Thanks,
> Qing
>
>
> On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
>
> +0.5
> I'm an SDE working for MXNet Engine team at AWS and I've been using
> JIRA
> for nearly every single PR (28 out of 29 PR at this moment) I created
> since
> I joined the team 3 months ago. I wouldn't say it's a really bad
> experience, but definitely not good.
> I do agree that we need something like JIRA and extra effort other than
> writing code to manage the project, but the current user experience
> with
> JIRA really has room for improvement.
> The more important question for the community is that, is JIRA good for
> attracting and retaining open source contributors? Such a user
> experience
> of JIRA could drive contributors away if we're really enforcing it.
> In conclusion, I think the usage of JIRA should be of one's or team's
> own
> choice, if you do have the need to manage some development process
> (like
> our team), just continue to use it, but we should no longer enforce or
> persuade anyone to use it.
> I'm also attaching a typical workflow of mine using JIRA with sprint
> management and story point tracking for a single task, I think
> everyone who
> has used JIRA so far would share part of my experience.
> Thanks,
> Hao
>
> Appendix: what I need to do when I'm working on a task with JIRA:
> 1. Before I start working on something:
> 1) create a JIRA ticket for that, choose the correct type and
> define a
> proper name for it
> 2) go to backlog page to add it to a sprint if you want to use the
> sprint management.
> 3) go to sprint management page to assign story point value if you
> need
> the functionality (we recently started doing that)
> 2. When I start working on the task:
> 1) dig my ticket up (on the sprint page or backlog page or search
> for
> it)
> 2) click "open and start progress" to move it to "IN PROGRESS"
> phase.
> 3. When I finish the code, for every new PR I'll have to:
> 1) dig my ticket up
> 2) copy the ticket number so that I can add it to the PR title
> 3) an extra click to move the ticket to REVIEW phase
> 4) create a PR on github, paste the "MXNET-xxx" I just copied
> inside an
> extra pair of square brackets "[]"
> 5) still need to refer the related github issue in the PR if I'm
> solving one of them
> 4. For every code review or comment I receive on the new PR:
> 1) the JIRA bot logs 10 mins on the ticket no matter what kind of
> comment it is
> 2) JIRA sends me an email for every single one of such logs (so if
> you
> receive 10 code review comments in a single code review you get 10
> emails,
> my highest record was 17, while github would bundle all of them in
> only 1
> mail)
> 5. After the PR is merged I get an email from JIRA saying this is
> merged
> (for the bot, merge is like another comment on the PR) but I still
> have to:
> 1) dig my ticket up
> 2) manually move it to DONE phase (bot does not do that
> automatically).
> 6. The task is considered finished at this point, but any new comments
> on
> the PR will trigger the bot once again to log 10 mins on your ticket
> together with another email coming to your mailbox, while github is
> already
> sending an email for that.
>
> On Fri, Jun 8, 2018 at 2:23 PM, Naveen Swamy 
> wrote:
>
> > Eric/Mu/Tianqi,
> >
> > A couple of contributors  have used JIRA for the Scala project --
> this is
> > the first time, so there is some learning for us, We started off
> with a
> > design proposal, followed by a call for contribution. We kept our
> progress
> > open on the dev list and we found one contributor to help us during
> > debugging/testing/maven package creation and also one of them is
> working on
> > the Memory allocation issue in Scala not as a part of their day job;
> This
> > is where I find value in managing the project features on JIRA,
> designs on
> > the public wiki, etc.,. I am not claiming that this is perfect, this
> is a
> > WIP and as a community we should give it a chance and try it out.
> >
> > I don't think most of us here have even looked at JIRA.
> >
> > P.S: I am traveling, my response will be delayed.
> >
> > -Naveen
> >
> >
> > On Fri, Jun 8, 2018 at 12:34 PM, Anirudh 
> wrote:
> 

Re: ICLA?

[Hen]

Yup. It came up in early release votes.

This is software that was published already under Apache 2.0 by DMLC before
coming to the ASF. There are hundreds of contributors and no one copyright
owner who could sign a software (license) grant. All ASF committers signed
ICLAs. The request (going by memory) was to try and get folk to sign ICLAs
or software (license) grant.

It's one of those "you do a some diligence, and draw a line as to the right
place to stop doing diligence because otherwise you would be diligencing
forever" situations.

Hen


On Thu, Jun 7, 2018 at 3:15 PM, Justin Mclean 
wrote:

> Hi,
>
> Sorry if I'm mistaken (possible as I've not followed your project closely)
> but to me this sounds like more part of the initial IP Clearance process.
> Podlings can't make a release until that has been completed. [1]
>
> Thanks,
> Justin
>
> P.S please CC on any replies as I'm not subscribed to this list.
>
> 1. https://incubator.apache.org/guides/ip_clearance.html#
> establishing_provenance
>

Re: ICLA?

[Hen]

Yes. This was a back and forth last September or so. The Incubator PMC ask
was that we seek to get agreements from heavy contributors. It's a hard one
to say exactly what heavy is, thus I listed by number of contributions and
my list below is an eye ball for where the center of mass is committer-wise.

Hen

On Thu, Jun 7, 2018 at 11:02 AM, Tianqi Chen 
wrote:

> Interesting, but how about the current process, as far as I understand
> anybody can contributing to apache repo without signing CLA, only comitters
> are required to do so
>
> Tianqi
>
> On Thu, Jun 7, 2018 at 10:44 AM, Hen  wrote:
>
> > Authoring matters, not merging.
> >
> > If we're able to get license grants/ICLAs signed by the following GitHub
> > users, that would be great:
> >
> > sneakerkg
> > kevinthesun
> > hjk41
> > mavenlin
> > tornadomeet
> > winstywang
> > qiaohaijun
> > vchuravy
> > Roshrini
> > howard0su
> > sbodenstein
> > ptrendx
> >
> > And they may now be committers and signed ICLA, just hadn't back in
> > September 2017.
> >
> > Hen
> >
> >
> > On Wed, Jun 6, 2018 at 10:14 PM, Tianqi Chen 
> > wrote:
> >
> > > Maybe I was wrong, The existing code in the DMLC repo is merged by
> > original
> > > committers(who are now Apache MXNet comitters and signed CLA). So I
> > assume
> > > there is no such problem. Similar to the case that only comitter to the
> > > Apache MXNet repo has to sign CLA
> > >
> > > Tianqi
> > >
> > > On Wed, Jun 6, 2018 at 6:04 PM, Hen  wrote:
> > >
> > > > This list was former contributors to DMLC who did not become Apache
> > > > committers.
> > > >
> > > > Ideally some chunk of the larger contributors would sign ICLAs or
> > > software
> > > > (license) grants.
> > > >
> > > >
> > > > On Tue, Jun 5, 2018 at 9:23 PM Isabel Drost-Fromm  >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm not Hen, but:
> > > > >
> > > > >
> > > > > https://www.apache.org/dev/new-committers-guide.html#
> > > > icla-required-before-account-creation
> > > > >
> > > > > https://www.apache.org/dev/new-committers-guide.html#cla
> > > > >
> > > > > Everyone who has an Apache.org address, that is every committer,
> has
> > to
> > > > > sign this. The documents are tracked centrally in SVN.
> > > > >
> > > > >
> > > > > On how to become a committer see here:
> > > > >
> > > > > https://www.apache.org/foundation/getinvolved.html#
> > become-a-committer
> > > > >
> > > > >
> > > > > For contributers see also:
> > > > >
> > > > >
> > > > > http://mail-archives.apache.org/mod_mbox/www-
> > infrastructure-dev/201112
> > > .
> > > > mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E
> > > > >
> > > > >
> > > > > Isabel
> > > > >
> > > > > --
> > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail
> gesendet.
> > > >
> > >
> >
>

Re: ICLA?

[Hen]

Authoring matters, not merging.

If we're able to get license grants/ICLAs signed by the following GitHub
users, that would be great:

sneakerkg
kevinthesun
hjk41
mavenlin
tornadomeet
winstywang
qiaohaijun
vchuravy
Roshrini
howard0su
sbodenstein
ptrendx

And they may now be committers and signed ICLA, just hadn't back in
September 2017.

Hen


On Wed, Jun 6, 2018 at 10:14 PM, Tianqi Chen 
wrote:

> Maybe I was wrong, The existing code in the DMLC repo is merged by original
> committers(who are now Apache MXNet comitters and signed CLA). So I assume
> there is no such problem. Similar to the case that only comitter to the
> Apache MXNet repo has to sign CLA
>
> Tianqi
>
> On Wed, Jun 6, 2018 at 6:04 PM, Hen  wrote:
>
> > This list was former contributors to DMLC who did not become Apache
> > committers.
> >
> > Ideally some chunk of the larger contributors would sign ICLAs or
> software
> > (license) grants.
> >
> >
> > On Tue, Jun 5, 2018 at 9:23 PM Isabel Drost-Fromm 
> > wrote:
> >
> > > Hi,
> > >
> > > I'm not Hen, but:
> > >
> > >
> > > https://www.apache.org/dev/new-committers-guide.html#
> > icla-required-before-account-creation
> > >
> > > https://www.apache.org/dev/new-committers-guide.html#cla
> > >
> > > Everyone who has an Apache.org address, that is every committer, has to
> > > sign this. The documents are tracked centrally in SVN.
> > >
> > >
> > > On how to become a committer see here:
> > >
> > > https://www.apache.org/foundation/getinvolved.html#become-a-committer
> > >
> > >
> > > For contributers see also:
> > >
> > >
> > > http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112
> .
> > mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E
> > >
> > >
> > > Isabel
> > >
> > > --
> > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >
>

Re: ICLA?

[Hen]

This list was former contributors to DMLC who did not become Apache
committers.

Ideally some chunk of the larger contributors would sign ICLAs or software
(license) grants.


On Tue, Jun 5, 2018 at 9:23 PM Isabel Drost-Fromm  wrote:

> Hi,
>
> I'm not Hen, but:
>
>
> https://www.apache.org/dev/new-committers-guide.html#icla-required-before-account-creation
>
> https://www.apache.org/dev/new-committers-guide.html#cla
>
> Everyone who has an Apache.org address, that is every committer, has to
> sign this. The documents are tracked centrally in SVN.
>
>
> On how to become a committer see here:
>
> https://www.apache.org/foundation/getinvolved.html#become-a-committer
>
>
> For contributers see also:
>
>
> http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/201112.mbox/%3ca603ffce-623b-43e9-87f8-39baa51c7...@gbiv.com%3E
>
>
> Isabel
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: MXNet Protobuf dependency

[Hen]

Have they opened a PR with the ps-lite project?

On Wed, May 23, 2018 at 1:38 PM Singh, Rajan  wrote:

> Awesome 
>
> Thanks Rahul for the info. Will align
>
> Thanks
> Rajan
>
> On 5/23/18, 12:04 PM, "Rahul Huilgol"  wrote:
>
> Hi Rajan,
>
> This PR from the Intel folks is adding support for MPI based
> distributed
> training. They also needed proto3 and have updated the current ps-lite
> proto file to work with protobuf3.5. You might want to take a look at
> that
> and align efforts with that approach.
>
> https://github.com/apache/incubator-mxnet/pull/10696
>
> The ps-lite change:
>
> https://github.com/threeleafzerg/ps-lite/compare/a6dda54604a07d1fb21b016ed1e3f4246b08222a...a470d2270d4af4badf4c94eab9559811697332e3#diff-ba121c714260f51ca98d51a080880b6d
>
> Regards,
> Rahul
>
> On Wed, 23 May 2018 at 11:06 Singh, Rajan  wrote:
>
> > Hi,
> >
> > Currently, MXNet has Protobuf ( version 2.5) as one of its
> dependency. The
> > dependency comes from PS-lite<
> >
> https://github.com/dmlc/ps-lite/blob/a6dda54604a07d1fb21b016ed1e3f4246b08222a/make/deps.mk#L11
> >
> > used for distributed training.
> > Recently, we have added ONNX support in MXNet(1.2.0) contrib package(
> > import ONNX support). This module has a runtime dependency on
> > Protobuf(version 3) , needed for ONNX.
> > So, if a user tries to do “import onnx”, will get a message:
> >
> > “To use this module developers need to install ONNX, which requires
> the
> > protobuf compiler to be installed separately. Please follow the
> > instructions to install ONNX and its dependencies<
> > https://github.com/onnx/onnx#installation>. MXNet currently
> supports ONNX
> > v1.1.1. Once installed, you can go through the tutorials on how to
> use this
> > module.”
> >
> > User will end up installing protobuf version 3.5.2. Since Protobuf
> > backward compatibility is flaky, anything dependent on version <
> 2.6, will
> > probably break. In this case, distributed training might break for
> the user.
> >
> > IMO, To resolve this dependency conflict in MXNet, would require an
> update
> > to PS-lite dependency to  Protobuf version 3. Is there a POA to
> update this
> > dependency for PS-lite?
> > FYI: We are also working on adding an export module support, will
> export
> > MXNet models to ONNX format, which will also have Protobuf version 3
> and
> > ONNX as its runtime dependency.
> >
> > Please let me know, what should be best path moving forward.
> >
> > Thanks
> > Rajan
> >
> >
>
>
>

Re: Using parts of code from library under PyTorch organization

[Hen]

It's 2-clause BSD: https://github.com/pytorch/cpuinfo/blob/master/LICENSE

Which files are you looking to incorporate? I want to see what the source
headers look like.

Hen

On Fri, May 18, 2018 at 5:47 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> By the way. In general, I'd prefer to have a solution in C++ as part of our
> Backend, as this would allow us to share this information with all frontend
> APIs. Tobias is currently working on a PR which does exactly the same, but
> for GPUs.
>
> Marco de Abreu  schrieb am Sa., 19. Mai
> 2018,
> 02:45:
>
> > I would have to check the license, but I assume it's under Apache. In
> that
> > case, it should be enough to copy the file and keep the original license
> > header. Additionally, you have to document any changes you made and where
> > you got it from. You can do this in the header, below the license.
> >
> > In any case, check the NOTICE of the project and see if they contain any
> > special instructions.
> >
> > -Marco
> >
> > Anirudh  schrieb am Sa., 19. Mai 2018, 00:27:
> >
> >> Hi Alex,
> >>
> >> I am no expert but adding the license and the copyright to the header of
> >> the file should be enough.
> >> Can someone who has experience with this confirm ?
> >>
> >> Anirudh
> >>
> >> On Fri, May 18, 2018 at 10:55 AM, Alex Zai  wrote:
> >>
> >> > For this issue (https://github.com/apache/
> incubator-mxnet/issues/10836
> >> ),
> >> > we
> >> > need to determine the number of physical cores for each platform.
> >> Currently
> >> > we assume each platform supports HyperThreading and just fetch the
> >> number
> >> > of logical cores and divide by 2. However, in cases where the machine
> >> does
> >> > not support HTT, we underutilize the CPUs. Per the issue’s thread, the
> >> > PyTorch organization has a library that does just this (
> >> > https://github.com/pytorch/cpuinfo). The library is a bit heavy and
> we
> >> > only
> >> > need a small portion of the code. Does anyone know if there is an
> issue
> >> > with just using a subset of the code?
> >> >
> >> >
> >> >
> >> > Alex
> >> >
> >>
> >
>

Abandoned MXNet readthedocs site

[Hen]

It seems we (Apache MXNet) have an old documentation site posted at:

https://newdocs.readthedocs.io/en/latest/

and only the absent @Awyan has the permissions to the site. See
https://github.com/apache/incubator-mxnet/issues/10409 for more details.

Raising this with readthedocs.org, we've been asked to submit a DMCA
request to take down the account:

https://github.com/rtfd/readthedocs.org/issues/4042

Given our docs are Apache licensed I suspect it's really a trademark
takedown (confused users etc). Does anyone here have any guidance with this
situation? Has anyone had this issue with readthedocs before? Should we be
sending them a Trademark takedown request?

Thanks,

Hen

Re: MXNet 1.2 release question ?

[Hen]

I don’t understand what “late with the release” means. Did the project
publish a timeline of releases that it guaranteed or something?

On Mon, May 14, 2018 at 10:11 AM Anirudh  wrote:

> Hi all,
>
> Our vote got blocked on general@ list. The main reason was the inclusion
> of
> a file with category b license in non binary form:
> "3rdparty/googletest/googlemock/docs/DevGuide.md".
> This file needs to be removed from source.
>
> There are two options we have right now:
>
> 1. Remove the DevGuide.md from source and call for a new vote.
> 2. Remove the DevGuide.md, fix some other license issues and also fix some
> other issues: compilation issues on older versions of mac 10.10 or older,
> push other fixes etc.
>
> The first option would happen much quicker, since there is no change in
> source apart from removal of DevGuide.md file and we can close the vote
> quicker when the quorum is reached.
>
> The second option will have to go through the full vote cycle again but
> will fix some issues with previous RC.
>
> I am inclined to do 1 currently since I don't see the compilation issue on
> older version of Mac as a critical one and we are already considerably late
> with the release.
>
> I would like to know what you guys think.
>
> Anirudh
>

newdocs.readthedocs site

[Hen]

Does anyone have contact info for github.com/Awyan?

It seems we have an old documentation site posted at:

https://newdocs.readthedocs.io/en/latest/

and only the absent @Awyan has the permissions to the site. See
https://github.com/apache/incubator-mxnet/issues/10409 for more details.

If no one has the ability to contact the individual, it sounds like we'll
have to reach out to Apache Legal and discuss a DMCA request (readthedocs'
surprisingly heavy process for such):

https://github.com/rtfd/readthedocs.org/issues/4042

Thanks,

Hen

Re: Pre-release versions on website

[Hen]

Where are said mocks/Krishnan discussions?

On Mon, May 7, 2018 at 5:09 PM Aaron Markham 
wrote:

> The release candidate was removed as an option on the site.
>
> With regard to the default version, I posted about the predominance of
> users on master, and all of the feedback I received agreed that master
> should be the default view of the website.
> If a change of heart occurs regarding the default view of the site, I made
> the build_version_doc scripts, and Jenkins job that uses them, easily
> configurable, so from the Jenkins job, one may simply change the "site
> default" parameter on the nightly site build job. Viola, whatever version
> you want as default will appear upon the next run. For now, however, I
> think we should stick to what the users on the site seem to want, and
> that's master.
>
> That being said, the default installation instructions should reflect the
> current release: pip install mxnet. They currently reflect how to install
> master, using: --pre. I plan to remedy this soon. Anyone coming to the site
> and wanting to get started should see something similar to how pytorch does
> it. Their instructions are very clean and simple. Complex installation
> information can be posted on a detail pages, but basic install info should
> be like one line: pip install mxnet or pip install mxnet-{some-variant}.
>
> Krishnan and I are working on a refactor of the install page to make it
> easier to maintain and easier for visitors to the site to get started.
> Also, the API docs should have the option to be easily switched and
> searching should work within the version you have selected. Again, this is
> something Krishnan and I are discussing and attempting to fix. I believe
> that between these two updates, we'll have resolved the primary UX problems
> with the versions selector, as well as allayed the concerns about clarity
> around the API docs. You should know what version of content you're reading
> at any point in time. I'm happy to hear any suggestions or requests on this
> area as we're in the middle of mocking up some solutions.
>
> Cheers,
> Aaron
>
>
> On Mon, May 7, 2018 at 8:03 AM, Hen  wrote:
>
> > Agreed.
> >
> > RCs are for the project contributors to review. They are not for users as
> > they have not passed the release process. The website shouldn’t reflect
> > RCs.
> >
> > Hen
> >
> > On Sat, May 5, 2018 at 10:42 PM Afrooze, Sina 
> wrote:
> >
> > > I have mentioned this before and I still think that the default MXNet
> > > webpage must match the default version that is installed when someone
> > > issues "pip install mxnet". - Sina
> > >
> > >
> > >
> > > On 5/1/18, 6:43 PM, "Marco de Abreu" 
> > > wrote:
> > >
> > > Hi Aaron,
> > > I think it'd be a good idea to create pip packages for the release
> > > candidates. Sheng, would it be possible to incorporate this into
> your
> > > build
> > > pipeline? In my opinion, we shouldn't advertise the RCs not too
> much
> > > on our
> > > website, so I'd say we could skip #2. #3 in combination with #1
> > sounds
> > > like
> > > a good idea.
> > >
> > > In the meantime, we could just patch the install page for 1.2.0
> and a
> > > big
> > > red warning message that states that this a release candidate and
> > that
> > > the
> > > publish process is ongoing. This way, we can let the 1.2.0 website
> > > stay up
> > > and also avoid confusion. WDYT?
> > >
> > > -Marco
> > >
> > > On Wed, May 2, 2018 at 1:22 AM, Aaron Markham <
> > > aaron.s.mark...@gmail.com>
> > > wrote:
> > >
> > > > Hi Marco,
> > > > Putting 1.2.0 was meant to allow a preview and for testing, but I
> > > see how
> > > > this can cause confusion.
> > > >
> > > > Change the names and/or hiding the RC is possible with some
> > > refactoring of
> > > > the site build scripts. I'd be happy to take a look at this.
> > > >
> > > > I think another solution could be:
> > > > 1. create pip installs for each release candidate
> > > > 2. offer each release candidate on the install page (with
> > > instructions for
> > > > source and pip installs)
> > > > 3. when there's a dropdown for version, in either the install or
> > API

Re: Pre-release versions on website

[Hen]

Agreed.

RCs are for the project contributors to review. They are not for users as
they have not passed the release process. The website shouldn’t reflect RCs.

Hen

On Sat, May 5, 2018 at 10:42 PM Afrooze, Sina  wrote:

> I have mentioned this before and I still think that the default MXNet
> webpage must match the default version that is installed when someone
> issues "pip install mxnet". - Sina
>
>
>
> On 5/1/18, 6:43 PM, "Marco de Abreu" 
> wrote:
>
> Hi Aaron,
> I think it'd be a good idea to create pip packages for the release
> candidates. Sheng, would it be possible to incorporate this into your
> build
> pipeline? In my opinion, we shouldn't advertise the RCs not too much
> on our
> website, so I'd say we could skip #2. #3 in combination with #1 sounds
> like
> a good idea.
>
> In the meantime, we could just patch the install page for 1.2.0 and a
> big
> red warning message that states that this a release candidate and that
> the
> publish process is ongoing. This way, we can let the 1.2.0 website
> stay up
> and also avoid confusion. WDYT?
>
> -Marco
>
> On Wed, May 2, 2018 at 1:22 AM, Aaron Markham <
> aaron.s.mark...@gmail.com>
> wrote:
>
> > Hi Marco,
> > Putting 1.2.0 was meant to allow a preview and for testing, but I
> see how
> > this can cause confusion.
> >
> > Change the names and/or hiding the RC is possible with some
> refactoring of
> > the site build scripts. I'd be happy to take a look at this.
> >
> > I think another solution could be:
> > 1. create pip installs for each release candidate
> > 2. offer each release candidate on the install page (with
> instructions for
> > source and pip installs)
> > 3. when there's a dropdown for version, in either the install or API
> docs
> > area it maps precisely to the release or release candidate
> >
> > In the meantime, to prevent confusion, I'll remove 1.2.0 from the
> site.
> > Once we cut the release, or solved the points above, whichever is
> sooner,
> > the version(s) can be reintroduced to the site.
> >
> > Cheers,
> > Aaron
> >
> > On Tue, May 1, 2018 at 3:26 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com
> > > wrote:
> >
> > > Hello,
> > >
> > > we have been approached by a few users about the release status of
> MXNet
> > > 1.2. One thing that seems to be confusing in particular is the
> fact that
> > we
> > > already show version 1.2.0 on our website. Would it be possible to
> > > blacklist (and remove) pre-release versions from website until
> they have
> > > been approved and published?
> > >
> > > Best regards,
> > > Marco
> > >
> >
>
>
>
>

Re: GitHub releases section used for non-releases

[Hen]

Wincing at a binary of 7z being there. Seems like something to delete.

On Tue, May 1, 2018 at 3:32 PM Marco de Abreu 
wrote:

> Hello,
>
> I have just had a look at
> https://github.com/apache/incubator-mxnet/releases
> and it seems like the releases section is being used for other purposes
> than MXNet releases (e.g.
> https://github.com/apache/incubator-mxnet/releases/tag/utils). This causes
> MXNet 1.1.0 to not be shown as "Latest release" and results in confusion.
>
> In general, I don't really understand the purpose of utility releases and
> why they are being done under the main repository. Could somebody elaborate
> and provide some insight? I haven't found any communication on dev@ about
> this.
>
> Best regards,
> Marco
>

Re: [VOTE] Release Apache MXNet(incubating) version 1.2.0.RC1

[Hen]

Naive question - How often does this happen? It should be rare that a
project needs to send a PR to a dependency, and much rarer that it blocks a
release.

It sounds like it’s too coupled a dependency. I suspect the DMLC code
situation is going to be a major blocker to any chance of graduating.

Hen

On Mon, Apr 30, 2018 at 1:23 PM Gautam  wrote:

> +1 on merging this "https://github.com/dmlc/mshadow/pull/319 "
>
> I am curious how are we tracking the sub-modules's PRs which are really
> important for MXNet?
> This PR has been waiting to merge for almost 4 months.
>
>
>
> On Mon, Apr 30, 2018 at 1:51 AM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> wrote:
>
> > -1
> >
> > We should merge this and update mshadow before the next release:
> > https://github.com/dmlc/mshadow/pull/319  so we compile cuda for Volta.
> >
> > On Sat, Apr 28, 2018 at 12:53 AM, Steffen Rochel <
> steffenroc...@gmail.com>
> > wrote:
> >
> > > Hi Chris - acknowledge that building the docs is not as good as it
> should
> > > be and needs to be improved. Is it worse compared to 1.1.0 release to
> > > consider as release blocker?
> > >
> > >
> > > On Fri, Apr 27, 2018 at 9:53 AM Chris Olivier 
> > > wrote:
> > >
> > > > -1
> > > >
> > > > Building the docs locally is an absolute nightmare.  I haven;t been
> > able
> > > to
> > > > get it to work yet.
> > > >
> > > > On Thu, Apr 26, 2018 at 3:36 PM, Marco de Abreu <
> > > > marco.g.ab...@googlemail.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'd like to request to pause this vote since I have identified an
> > issue
> > > > > with our CMakeLists, breaking all UNIX builds with the latest
> version
> > > > > (3.11) of cmake. This issue is tracked at [1]. The PR to fix this
> is
> > > > > available at [2].
> > > > >
> > > > > Best regards,
> > > > > Marco
> > > > >
> > > > >
> > > > > [1]: https://github.com/apache/incubator-mxnet/issues/10708
> > > > > [2]: https://github.com/apache/incubator-mxnet/pull/10712
> > > > >
> > > > >
> > > > > On Thu, Apr 26, 2018 at 3:05 PM, Sheng Zha 
> > wrote:
> > > > >
> > > > > > -1 for the following reasons:
> > > > > >
> > > > > > 1. due to addition of support for fp16, the build breaks for
> > windows
> > > > and
> > > > > > older version of osx (clang 8 for example). fix is in
> > > > > > https://github.com/dmlc/mshadow/pull/333
> > > > > >
> > > > > > 2. due to addition of quantized fully connected op, cuda 7.5
> build
> > is
> > > > > > broken. Jun Wu is tracking the issue.
> > > > > >
> > > > > > -sz
> > > > > >
> > > > > > On Thu, Apr 26, 2018 at 3:01 PM, Anirudh 
> > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > As part of RC1 release, We have addressed the issue with
> respect
> > to
> > > > > > > asymmetric padding in ONNX Import module (
> > > > > > > https://github.com/apache/incubator-mxnet/pull/10676).
> > > > > > > We have also added existing silent failures for MXNet Conv and
> > the
> > > > > > > incompatibility in behavior for certain use cases between MXNet
> > > > without
> > > > > > > MKLDNN and MXNet with MKLDNN support to the release notes. We
> > have
> > > > > marked
> > > > > > > both ONNX and MKLDNN support as "Experimental" in the release
> > > notes.
> > > > > The
> > > > > > > tutorial
> > > > > > > <https://github.com/apache/incubator-mxnet/blob/master/
> > > > > > > docs/tutorials/onnx/fine_tuning_gluon.md>
> > > > > > > which was called out still seems to be failing with cpu context
> > and
> > > > we
> > > > > > have
> > > > > > > mentioned this as a known issue in the release notes. Since,
> both
> > > > > MKLDNN
> > > > > > > support and ONNX import module have been marked experimental

Re: MXNet meetup in Seattle April 24th

[Hen]

Will there be a write up/presentation upload for those unable to attend?

On Sun, Apr 15, 2018 at 4:47 PM Steffen Rochel 
wrote:

> All - updated agenda published at:
> https://www.meetup.com/Apache-MXNet-Seattle-meetup/events/249178668/
>
> If you are interested and available, please RSVP if you haven't already.
>
> Steffen
>

Re: blog for MXNet

[Hen]

Pretty sad that “intel mkdnn mxnet” doesn’t find that in a google search;
but perhaps that says more about the fragmentation of the internet and my
out of date expectations :)

Is that being translated over to English (recognizing the assumption that
western developers speak English)?

On Wed, Apr 11, 2018 at 8:02 PM Yida Wang  wrote:

> We have a WeChat official account ApacheMXNet and this is the latest post:
>
> https://mp.weixin.qq.com/s?__biz=MzU3NjUyOTU0OA==&mid=2247483669&idx=1&sn=f6217700a69c3d70a91593560b94fd42&chksm=fd1334f6ca64bde07e4d9271fb549b897996c8638f061bea545b7ab19fb10d0c31973f3544e8#rd
>
> Yida
>
> On Wed, Apr 11, 2018 at 7:55 PM, Aaron Markham 
> wrote:
>
> > I think for China we need to cross-post to WeChat. Apparently, there
> > is already blog post activity for MXNet there, and it would make sense
> > to be on that platform directly.
> >
> > Can a China user access the Apache blog site that Hen mentioned? Also,
> > I'm not familiar with the Apache blog and how you contribute. I don't
> > see info about it on Confluence or elsewhere. Certainly sounds like
> > something that needs some attention and to be part of regular
> > communications.
> >
> >
> > On Wed, Apr 11, 2018 at 6:21 PM, Zhao, Patric 
> > wrote:
> > > FYI, China user can't access medium.com :(
> > >
> > >> -Original Message-
> > >> From: Anirudh Acharya [mailto:anirudhk...@gmail.com]
> > >> Sent: Thursday, April 12, 2018 6:31 AM
> > >> To: dev@mxnet.incubator.apache.org
> > >> Subject: Re: blog for MXNet
> > >>
> > >> There is already an AWS Evangelist, Julien Simon, who has quite a few
> > posts
> > >> about mxnet/gluon on medium - https://medium.com/@julsimon
> > >>
> > >>
> > >> Regards
> > >> Anirudh
> > >>
> > >> On Wed, Apr 11, 2018 at 3:27 PM, Sebastian Gutierrez <
> > >> sebast...@aiworkbox.com> wrote:
> > >>
> > >> > Aaron and Thomas
> > >> >
> > >> > Great ideas!
> > >> >
> > >> > One thing worth also considering is something like
> > >> >
> > >> > https://www.r-bloggers.com/
> > >> >
> > >> > What it does is serve as a blog aggregation service for all of the
> > >> > people who have blogged about r topics. Because of the central
> > >> > repository nature, it serves as a natural gathering point and allows
> > >> > people not using RSS (or similar technologies) to keep up to date
> > with what is
> > >> happening.
> > >> >
> > >> > Another thing worth considering is a job board / site for MXNet full
> > >> > time / part time / remote jobs.  The data vis community has this
> free
> > >> > email list service
> > >> > https://groups.google.com/forum/m/#!forum/data-vis-jobs that's very
> > >> > community friendly and is a good place for people to gather to see
> job
> > >> > needs.
> > >> >
> > >> > All the best
> > >> > Sebastian Gutierrez
> > >> >
> > >> >
> > >> > On Wed, Apr 11, 2018 at 6:10 PM Thomas DELTEIL
> > >> > 
> > >> > wrote:
> > >> >
> > >> > > Thanks Aaron, I like medium, a lot of projects seems to be posting
> > >> > > their articles there, as you mentioned.
> > >> > >
> > >> > > Note that there is a newly created Chinese MXNet blog here:
> > >> > > https://zh.mxnet.io/blog/
> > >> > >
> > >> > > I would be happy to contribute to the blogs, if you want to add me
> > >> > > to the writer/editor list.
> > >> > >
> > >> > >
> > >> > >
> > >> > > Also, there is a mxnet subreddit r/mxnet which was created by
> > >> > > Sebastian
> > >> > > (thanks!) and I am now a moderator as well. Feel free to
> cross-post
> > >> > > any interesting content there! https://www.reddit.com/r/mxnet/
> > >> > > Please subscribe!
> > >> > >
> > >> > >
> > >> > > I will try to post one link a day at least, until I run out of
> links
> > >> > > ☺ We will also improve the look of it this week and add links to
> > >> > > relevant resources on the side bar, etc.
> > >> > >
> > >> > >
> > >> > >
> > >> > > All the best,
> > >> > >
> > >> > >
> > >> > > Thomas
> > >> > >
> > >> > >
> > >> > > 2018-04-11 14:45 GMT-07:00 Aaron Markham
> > >> :
> > >> > >
> > >> > > > Having a blog for MXNet would be very useful for conveying news,
> > >> > > > talking about features, demoing applications, and building
> > awareness.
> > >> > > >
> > >> > > > Does anyone have particular preferences or recommendations on
> blog
> > >> > > > hosting or platform?
> > >> > > >
> > >> > > > I currently have editor access for an MXNet branded account on
> > Medium.
> > >> > > > https://medium.com/mxnet
> > >> > > >
> > >> > > > There's nothing there at the moment, but at least with Medium we
> > >> > > > all could get started right away, and have a built-in
> syndication
> > >> > > > platform. Also, note that this is where the TensorFlow blog
> > resides:
> > >> > > > https://medium.com/tensorflow
> > >> > > >
> > >> > > > Please make it known if you'd like to contribute, so you can get
> > >> > > > writer/editor access (to whichever platform we settle on.)
> > >> > > >
> > >> > > > Cheers,
> > >> > > > Aaron
> > >> > > >
> > >> > >
> > >> >
> >
>

Re: Quick question about a submodule file’s license

[Hen]

There’s nothing special process-wise; subscribe to the list and email the
question. The more detail and links the better to avoid any
misunderstandings.

Hen

On Fri, Apr 6, 2018 at 11:43 AM Meghna Baijal 
wrote:

> Thank you Henri, Pedro.
> Yes, we are only referring to the one documentation file within google
> test.
>
> Henri,
> Could you please guide me on the best approach to take an issue to the
> legal-discuss@.
>
> Thanks,
> Meghna Baijal
>
> On Fri, Apr 6, 2018 at 7:42 AM, Pedro Larroy  >
> wrote:
>
> > Good point, I thought text is media, but I'm not a lawyer. Just to be
> > clear, that this refers to that particular documentation file, the
> software
> > is BSD licensed.
> >
> > Pedro.
> >
> > On Fri, Apr 6, 2018 at 9:41 AM, Hen  wrote:
> >
> > > Noting that the linked FAQ is for CC-BY-SA and unmodified media (ie:
> > > images, sound, video); so it's not relevant.
> > >
> > > I think this is worth raising on legal-discuss@. CC-BY software is an
> > > issue, but resolved.html hasn't stated anything regarding CC-BY for a
> > > documentation file.
> > >
> > > Hen
> > >
> > > On Thu, Apr 5, 2018 at 10:43 AM, Meghna Baijal <
> > meghnabaijal2...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Thank you Pedro for looking into this. The suggestion came from PMC
> > > during
> > > > 1.1 voting cycle.
> > > > However, the link does seem to indicate that including it should be
> > ok. I
> > > > also found other Apache projects that have included this file.
> > > >
> > > > I will review the LICENSE and NOTICE requirements and let the file
> > remain
> > > > in the source.
> > > >
> > > > Thanks Again!
> > > >
> > > > On Thu, Apr 5, 2018 at 9:22 AM, Pedro Larroy <
> > > pedro.larroy.li...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi Meghna.
> > > > >
> > > > > Are you sure the DevGuide of googletest is a problem?
> > > > >
> > > > > Check this out:
> > > > >
> > > > > https://www.apache.org/legal/resolved.html#cc-sa
> > > > >
> > > > >
> > > > > Pedro.
> > > > >
> > > > >
> > > > > On Thu, Apr 5, 2018 at 2:59 AM, Meghna Baijal <
> > > > meghnabaijal2...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello Everyone,
> > > > > > There was a suggestion during the 1.1 release vote to remove this
> > > file
> > > > > [1]
> > > > > > from the released source since it is licensed under CC-BY-2.5.
> > > > > >
> > > > > > However, this file is a part of the googletest submodule and
> can’t
> > > > simply
> > > > > > be removed. Does anyone know how we can deal with the licensing
> of
> > > this
> > > > > > file ?
> > > > > >
> > > > > > [1] *Path to file in mxnet -*
> > > > > > apache-mxnet-src-1.1.0.rc1-incubating/3rdparty/
> > > > > googletest/googlemock/docs/
> > > > > > DevGuide.md
> > > > > > [2] *Link to github issue* :
> > > > > > https://github.com/apache/incubator-mxnet/issues/10330
> > > > > >
> > > > > > Thanks,
> > > > > > Meghna
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: blog for MXNet

[Hen]

https://blogs.apache.org/mxnet/entry/1-1-0-release-makes

On Wed, Apr 11, 2018 at 2:46 PM Aaron Markham 
wrote:

> Having a blog for MXNet would be very useful for conveying news,
> talking about features, demoing applications, and building awareness.
>
> Does anyone have particular preferences or recommendations on blog
> hosting or platform?
>
> I currently have editor access for an MXNet branded account on Medium.
> https://medium.com/mxnet
>
> There's nothing there at the moment, but at least with Medium we all
> could get started right away, and have a built-in syndication
> platform. Also, note that this is where the TensorFlow blog resides:
> https://medium.com/tensorflow
>
> Please make it known if you'd like to contribute, so you can get
> writer/editor access (to whichever platform we settle on.)
>
> Cheers,
> Aaron
>

Re: Podling Report Reminder - April 2018

[Hen]

That should have said non-committer :) I want to see the next report
written by a committer (whether that means someone else, or the project
recognizing report writing as a contribution).

One other, major imo, note on the board report.

This text is not good:

"a) Various Slack channels, dev@ mailing lists, and user discussion forums (
http://discuss.mxnet.io) are being used actively. The contributors have
been working on having all discussions on the public dev@ mailing list as
much as possible. This is an ongoing improvement process where the focus
will be to reduce the scope of private discussions to only a few
individuals before it is put on the public dev@ mailing list so that the
Apache MXNet community gets a fair chance in influencing the final
outcome/decision of the discussion."

The text is talking about raising the transparency of the project, but that
transparency is, even when raised, still below Apache's _minimum_ bar.
Saying that the community gets a 'fair' chance is insulting.

I'm a strong believer that it is perfectly fine for two or more committers
to brainstorm an idea face to face; but there's an immediate tension if
that leads to a situation where they strong arm agreement due to the number
of folk involved. There needs to be a cost to the lack of transparency, and
that cost is a lack of volume in the community discussion. My strong
recommendation is that said committers decide on a spokesperson for the
idea, that they show restraint in piling on in the debate, and that they
recuse themselves from voting +1 on a vote as they already voted when
brainstorming the idea.

Hen

[piling on => an email thread where multiple people all jump on to the
thread to say, in essence, the same thing, and wear down an opposing
argument through sheer numbers]






On Mon, Apr 9, 2018 at 12:43 PM, Hen  wrote:

> Will review to tonight.
>
> Noting that I’m going to -1 any report in the future that is written by a
> non-committee.
>
> Hen
>
>
> On Mon, Apr 9, 2018 at 11:28 AM Steffen Rochel 
> wrote:
>
>> Dear mentors - I posted the MXNet podling report at
>> https://wiki.apache.org/incubator/April2018#preview .
>> Appreciate your signoff or feedback.
>> Steffen
>>
>> On Mon, Apr 9, 2018 at 4:28 AM John D. Ament 
>> wrote:
>>
>> > Steffen
>> >
>> > Please follow the instructions at https://wiki.apache.org/incubator to
>> > get your account setup (info box at the top).
>> >
>> > John
>> >
>> > On 2018/04/09 00:57:37, Steffen Rochel  wrote:
>> > > Hi John - thanks for your feedback, will update the website
>> accordingly.
>> > >
>> > > Mentors - I don't have write access to incubator wiki, please post the
>> > > report.
>> > >
>> > > Regards,
>> > > Stefffen
>> > >
>> > >
>> > > On Sun, Apr 8, 2018 at 5:43 PM John D. Ament 
>> > wrote:
>> > >
>> > > > You need to get this report posted on the incubator wiki.
>> > > >
>> > > > Some questions about the report.
>> > > >
>> > > > You mention that 1.1.0 is available, however I cannot find a
>> download
>> > page
>> > > > on the mxnet website.  You must have a download page that points to
>> > your
>> > > > source release.
>> > > > Your downloads must point to our mirror system, not gihtub managed
>> > links.
>> > > > You also need to fix your website branding, the first mention
>> should be
>> > > > Apache MXNet (Incubating)
>> > > >
>> > > > On 2018/04/08 23:01:28, Steffen Rochel 
>> > wrote:
>> > > > > Dear Mentors - attached updated version:
>> > > > > - fixed typo
>> > > > > - added information about MXNet youtube channel
>> > > > > - added PPMC election for Jun Wu
>> > > > >
>> > > > > Steffen
>> > > > >
>> > > > > On Sun, Apr 8, 2018 at 12:44 PM Steffen Rochel <
>> > steffenroc...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Dear Mentors - please find attached podling report for April
>> 2018.
>> > > > > > Please approve or provide feedback.
>> > > > > > Apologize for the delay.
>> > > > > >
>> > > > > > Steffen
>> > > > > >
>> > > > > >
>> > > > > > On Sun, Apr 8, 2018 at 7:23 AM John D. Ament <
>> > j

Re: Podling Report Reminder - April 2018

[Hen]

Will review to tonight.

Noting that I’m going to -1 any report in the future that is written by a
non-committee.

Hen


On Mon, Apr 9, 2018 at 11:28 AM Steffen Rochel 
wrote:

> Dear mentors - I posted the MXNet podling report at
> https://wiki.apache.org/incubator/April2018#preview .
> Appreciate your signoff or feedback.
> Steffen
>
> On Mon, Apr 9, 2018 at 4:28 AM John D. Ament 
> wrote:
>
> > Steffen
> >
> > Please follow the instructions at https://wiki.apache.org/incubator to
> > get your account setup (info box at the top).
> >
> > John
> >
> > On 2018/04/09 00:57:37, Steffen Rochel  wrote:
> > > Hi John - thanks for your feedback, will update the website
> accordingly.
> > >
> > > Mentors - I don't have write access to incubator wiki, please post the
> > > report.
> > >
> > > Regards,
> > > Stefffen
> > >
> > >
> > > On Sun, Apr 8, 2018 at 5:43 PM John D. Ament 
> > wrote:
> > >
> > > > You need to get this report posted on the incubator wiki.
> > > >
> > > > Some questions about the report.
> > > >
> > > > You mention that 1.1.0 is available, however I cannot find a download
> > page
> > > > on the mxnet website.  You must have a download page that points to
> > your
> > > > source release.
> > > > Your downloads must point to our mirror system, not gihtub managed
> > links.
> > > > You also need to fix your website branding, the first mention should
> be
> > > > Apache MXNet (Incubating)
> > > >
> > > > On 2018/04/08 23:01:28, Steffen Rochel 
> > wrote:
> > > > > Dear Mentors - attached updated version:
> > > > > - fixed typo
> > > > > - added information about MXNet youtube channel
> > > > > - added PPMC election for Jun Wu
> > > > >
> > > > > Steffen
> > > > >
> > > > > On Sun, Apr 8, 2018 at 12:44 PM Steffen Rochel <
> > steffenroc...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Dear Mentors - please find attached podling report for April
> 2018.
> > > > > > Please approve or provide feedback.
> > > > > > Apologize for the delay.
> > > > > >
> > > > > > Steffen
> > > > > >
> > > > > >
> > > > > > On Sun, Apr 8, 2018 at 7:23 AM John D. Ament <
> > johndam...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > >> Just to point out - the report was due on 4/4.  You'll need to
> > get the
> > > > > >> report in very early to ensure your mentors can review.
> > > > > >>
> > > > > >> On 2018/04/08 01:45:46, Steffen Rochel  >
> > > > wrote:
> > > > > >> > Hi John - we will get a report out tomorrow (Sunday PDT).
> > > > > >> > Steffen
> > > > > >> >
> > > > > >> > On Sat, Apr 7, 2018 at 5:19 PM John D. Ament <
> > johndam...@apache.org
> > > > >
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > > Is anyone available to write the report?  Need some kind of
> > > > response
> > > > > >> from
> > > > > >> > > the podling...
> > > > > >> > >
> > > > > >> > > On 2018/04/03 02:43:12, Hen  wrote:
> > > > > >> > > > Board report time. Any committer available to write
> > something?
> > > > > >> > > >
> > > > > >> > > > Reminder of the template:
> > > > > >> > > >
> > > > > >> > > > MXNetA Flexible and Efficient Library for Deep
> > LearningMXNet has
> > > > > >> been
> > > > > >> > > > incubating since 2017-01-23.Three most important issues to
> > > > address
> > > > > >> in
> > > > > >> > > > the move towards graduation:  1.  2.  3.Any issues that
> the
> > > > > >> Incubator
> > > > > >> > > > PMC (IPMC) or ASF Board wish/need to beaware of?How has
> the
> > > > > >> community
> > > > > >> > > > developed since the last report?How has the project
> > developed
> > > > since
> > > > > >> > > > the last report?How would you assess the podling's
> > > > maturity?Please
> > > > > >> > > > feel free to add your own commentary.  [ ] Initial setup
> [
> > ]
> > > > > >> Working
> > > > > >> > > > towards first release  [ ] Community building  [ ] Nearing
> > > > > >> graduation
> > > > > >> > > > [ ] Other:Date of last release:  -XX-XXWhen were the
> > last
> > > > > >> > > > committers or PPMC members elected?
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > 
> > > > > >> > > >
> > > > > >> > > > Previous board report is in here:
> > > > > >> > > >
> > > > > >> > >
> > > > > >>
> > > >
> >
> https://www.apache.org/foundation/records/minutes/2018/board_minutes_2018_01_17.txt
> > > > > >> > > >
> > > > > >> > > > Hen
> > > > > >> > > >
> > > > > >> > > > On Mon, Apr 2, 2018 at 3:50 PM, 
> > wrote:
> > > > > >> > > >
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > > This should be appended to the Incubator Wiki page at:
> > > > > >> > > > >
> > > > > >> > > > > https://wiki.apache.org/incubator/April2018
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Quick question about a submodule file’s license

[Hen]

Noting that the linked FAQ is for CC-BY-SA and unmodified media (ie:
images, sound, video); so it's not relevant.

I think this is worth raising on legal-discuss@. CC-BY software is an
issue, but resolved.html hasn't stated anything regarding CC-BY for a
documentation file.

Hen

On Thu, Apr 5, 2018 at 10:43 AM, Meghna Baijal 
wrote:

> Thank you Pedro for looking into this. The suggestion came from PMC during
> 1.1 voting cycle.
> However, the link does seem to indicate that including it should be ok. I
> also found other Apache projects that have included this file.
>
> I will review the LICENSE and NOTICE requirements and let the file remain
> in the source.
>
> Thanks Again!
>
> On Thu, Apr 5, 2018 at 9:22 AM, Pedro Larroy  >
> wrote:
>
> > Hi Meghna.
> >
> > Are you sure the DevGuide of googletest is a problem?
> >
> > Check this out:
> >
> > https://www.apache.org/legal/resolved.html#cc-sa
> >
> >
> > Pedro.
> >
> >
> > On Thu, Apr 5, 2018 at 2:59 AM, Meghna Baijal <
> meghnabaijal2...@gmail.com>
> > wrote:
> >
> > > Hello Everyone,
> > > There was a suggestion during the 1.1 release vote to remove this file
> > [1]
> > > from the released source since it is licensed under CC-BY-2.5.
> > >
> > > However, this file is a part of the googletest submodule and can’t
> simply
> > > be removed. Does anyone know how we can deal with the licensing of this
> > > file ?
> > >
> > > [1] *Path to file in mxnet -*
> > > apache-mxnet-src-1.1.0.rc1-incubating/3rdparty/
> > googletest/googlemock/docs/
> > > DevGuide.md
> > > [2] *Link to github issue* :
> > > https://github.com/apache/incubator-mxnet/issues/10330
> > >
> > > Thanks,
> > > Meghna
> > >
> >
>

Re: Podling Report Reminder - April 2018

[Hen]

Board report time. Any committer available to write something?

Reminder of the template:

MXNetA Flexible and Efficient Library for Deep LearningMXNet has been
incubating since 2017-01-23.Three most important issues to address in
the move towards graduation:  1.  2.  3.Any issues that the Incubator
PMC (IPMC) or ASF Board wish/need to beaware of?How has the community
developed since the last report?How has the project developed since
the last report?How would you assess the podling's maturity?Please
feel free to add your own commentary.  [ ] Initial setup  [ ] Working
towards first release  [ ] Community building  [ ] Nearing graduation
[ ] Other:Date of last release:  -XX-XXWhen were the last
committers or PPMC members elected?




Previous board report is in here:
https://www.apache.org/foundation/records/minutes/2018/board_minutes_2018_01_17.txt

Hen

On Mon, Apr 2, 2018 at 3:50 PM,  wrote:

>
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/April2018
>

Fwd: Abstracts on Apache MxNet - DataWorks Summit San Jose - Submission deadline extended thru Sunday

[Hen]

-- Forwarded message -
From: Robert Hryniewicz 
Date: Fri, Feb 9, 2018 at 20:41
Subject: Re: Abstracts on Apache MxNet - DataWorks Summit San Jose -
Submission deadline extended thru Sunday
To: dev-ow...@mxnet.incubator.apache.org <
dev-ow...@mxnet.incubator.apache.org>


Hi Folks,



Just a quick reminder that *abstract* submission *deadline* for *DataWorks
Summit San Jose* (#DWS18) is has been *extended to Sun, Feb 11th *due to
tech difficulties.



We’re super interested in having abstracts with Apache MxNet!



Submit your abstracts here: https://dataworkssummit.com/*abstracts*/




This year we will focus even more on AI & Data Science. Here’s the track
description:



Artificial Intelligence (AI) is transforming every industry. Data science
and machine learning are opening new doors in process automation,
predictive analytics, and decision optimization. This track offers sessions
spanning the entire data science lifecycle: development, test, and
production.

You’ll see examples of innovative analytics applications and systems for
data visualization, statistics, machine learning, cognitive systems, and
deep learning. We’ll show you how to use modern open source workbenches to
develop, test, and evaluate advanced AI models before deploying them.
You’ll hear from leading researchers, data scientists, analysts, and
practitioners who are driving innovation in AI and data science.

Sample technologies:
Apache Spark, R, Apache Livy, Apache Zeppelin, Jupyter, scikit-learn,
Keras, TensorFlow, DeepLearning4J, Chainer, Lasagne/Blocks/Theano,
CaffeOnSpark, Apache MXNet, and PyTorch/Torch

Looking forward to some amazing abstracts! ☺



Thanks and best regards,



*Robert Hryniewicz*

Data Scientist / Architect / Evangelist

Technical Marketing | Hortonworks Inc. 

+1 (855) 846-7866 Ext: 94749

Re: JIRA notifications on dev@

[Hen]

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 
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"  >:
> >
> > > 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  >
> > > > 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: Unit tests removed

[Hen]

Doing the right thing for code is the right thing. Feelings are in how we
communicate, not in what happens to the code.

If you are saying that the unit tests should be deleted, then good, but if
the commit was in error then rolling it back seems fine to me. Given we’re
volunteers we can’t rely on someone adding the tests back later, that’s
just a good intention.

Hen

On Thu, Feb 1, 2018 at 11:11 Mu Li  wrote:

> I think simply reverting the MKL PR that Da has been working for a half
> year and immediately enabling the cpp tests in the CI without reaching an
> agreement with Da seriously hurts his feelings.
>
> I put the details at the end of
> https://github.com/apache/incubator-mxnet/pull/9661
>
>
> On Thu, Feb 1, 2018 at 10:42 AM, Chris Olivier 
> wrote:
>
> > I have created starter changes for converting to the CoreOpExecutor. This
> > code compiles the first test.
> >
> > See notes in the PR description:
> >
> > https://github.com/cjolivier01/mxnet/pull/2
> >
> > On Wed, Jan 31, 2018 at 9:47 PM, Zhao, Patric 
> > wrote:
> >
> > > Thanks, Chris, I agree the quality is the most important thing.
> > >
> > > We will try to enable these cases ASAP.
> > >
> > > ---Patric
> > >
> > > > -Original Message-
> > > > From: Chris Olivier [mailto:cjolivie...@gmail.com]
> > > > Sent: Thursday, February 1, 2018 1:04 PM
> > > > To: dev@mxnet.incubator.apache.org
> > > > Subject: Re: Unit tests removed
> > > >
> > > > C++ Unit tests test correctness of output as well as consistency of
> > *all
> > > > inputs and outputs* between different implementations (mkl, cpu, gpu,
> > > > cudnn, etc.)
> > > >
> > > > C++ Unit tests also test that varying channel axes produce the
> expected
> > > > numeric distributions.
> > > >
> > > > In addition, *batch norm tests in test_operator.py are disabled due
> to
> > CI
> > > > issues*, so this leaves batch norm largely untested (even though
> those
> > > tests
> > > > only tested numeric gradient and nothing else -- they were existing
> > tests
> > > > before I re-factored batch norm and they were weak to begin with).
> > > >
> > > > C++ unit tests also measure performance differences between the
> various
> > > > versions (cpu, mkl, gpu, cudnn, etc).
> > > > I've made several comments over the course of this mkl-dnn project
> that
> > > the
> > > > unit tests need to be fixed to adjust to the refactor, so this
> > shouldn't
> > > br a
> > > > surprise to anyone.
> > > >
> > > > Hacking out unit tests when it's inconvenient to fix them because of
> > your
> > > > code changes sets a *dangerous precedent*. What would the rule be?
> Is
> > it
> > > > "don't remove tests unless your PR is really big and it would take
> you
> > a
> > > > couple of days to fix them"?  We aren't talking about 1-2 tests,
> either
> > > --
> > > > we're talking about a LOT of tests that test various aspects of the
> > > operators.
> > > >
> > > > As for Intel, they are free to use the PR branch, and even if they
> > > can't, I don't
> > > > think that (or anything else) justifies compromising quality.
> > > >
> > > >
> > > > On Wed, Jan 31, 2018 at 8:45 PM, Haibin Lin <
> haibin.lin@gmail.com>
> > > > wrote:
> > > >
> > > > > Good catch.
> > > > >
> > > > > In general, I agree that tests are not supposed to removed,
> although
> > > > > CI is not running any of these cpp tests just yet. Usually unit
> tests
> > > > > in python for individual operators should be sufficient to test the
> > > > > correctness of operators (although I don't know how/if python tests
> > > > > can run on edge devices like iOS/Android) and it's not feasible to
> > > > > duplicate all operator python tests with their cpp counterparts.
> For
> > > > > functionalities that are not exposed to python or memory checks, I
> do
> > > > > agree that cpp tests are necessary.
> > > > >
> > > > > I am curious what are exactly tested in those cpp tests? I know
> that
> > > > > BatchNorm ops are tested in python already, but I don't have a full
&

Re: Please Help Fix MXNet Licensing Issues for the next Release!

[Hen]

I think we should revert the license file to the previous, and improve from
there. The policy is:

"The LICENSE file MUST contain the full text of the Apache License 2.0
<http://www.apache.org/licenses/LICENSE-2.0.txt>.

When a package bundles code under several licenses, the LICENSE file MUST
contain details of all these licenses. For each component which is not
Apache licensed, details of the component MUST be appended to the LICENSE file.
The component license itself MUST either be appended or else stored
elsewhere in the package with a pointer to it from the LICENSE file, e.g.
if the license is long."

Looking at Justin's feedback linked on the wiki page, his objection was
missing items in the license file.

I know there was a suggestion to remove the listing of components to make
it harder to have missing items, but that shouldn't mean removing license
text. If two components don't have exactly the same license text then they
are not the same license. Most commonly nowadays that means that you can't
merge BSD licenses together, and sometimes can't merge MIT together
(depending on variants and how you handle the copyright statements).

Hen

On Tue, Jan 30, 2018 at 2:42 PM, Meghna Baijal 
wrote:

> Hello Henri,
>
> Thank you for your review.
> As I have detailed in this PR
> <https://github.com/apache/incubator-mxnet/pull/9484>, the previous
> version
> of the LICENSE file contained a list of packages which were using the BSD
> license (based on the license text), along with the whole content of the
> actual license (Warp-CTC, Caffe, Cub, Sphinx etc). Since it was decided to
> remove this list, to be safe, I left one copy of the BSD license text in
> there. I agree this might not be the right way of doing it and would be
> happy to fix it.
>
> However, there has been a lot of back and forth on this top level LICENSE
> and NOTICE file and it would be great if you could help me understand the
> Apache policy correctly and fix these appropriately.
>
> Thanks,
> Meghna Baijal
>
>
>
>
> On Mon, Jan 29, 2018 at 7:54 PM, Hen  wrote:
>
> > The last paragraph of the LICENSE looks suspect. I doubt we've taken code
> > from the BSD project. I would suggest deleting that last paragraph.
> >
> > With MIT and BSD licenses you do have to be careful that the text of each
> > is the same. Each term is often used for a family of related licenses.
> >
> > Additionally each of MIT and BSD typically has a Copyright
> > statement accompanying it. If the rules say to remove that from LICENSE,
> > then we should be adding it to the NOTICE.
> >
> > Hen
> >
> >
> > On Wed, Jan 24, 2018 at 5:07 PM, Meghna Baijal <
> meghnabaijal2...@gmail.com
> > >
> > wrote:
> >
> > > Marco,
> > > Thanks a lot for looking through this ! Some comments below -
> > >
> > >1. *R-package:* Before we create the final tarball for the release,
> > the
> > >R-package is explicitly removed from the cloned MXNet repo. The only
> > > info I
> > >have in this regard is that “there are some unresolved licensing
> > issues
> > > in
> > >this package and cannot be released”.
> > >2. *Dockerfiles:* You can refer to this PR for details
> > >https://github.com/apache/incubator-mxnet/pull/9500. I plan to
> handle
> > >this differently next time.
> > >3. *perl-package*: There were some copyright issues in the past with
> > >this folder. I just excluded it to be on the safer side, but I think
> > it
> > >should be ok to add the ASF header here.
> > >4. *docs/** - Yes, agreed. I will add the licenses where needed but
> I
> > >still think its safer to exclude the folder as a whole from the RAT
> > > check.
> > >5. *CODEOWNERS* - agreed, will add to the list of excluded files.
> > >6. *appveyor.yml:* Is this file relevant anymore? I will add a
> license
> > >anyway.
> > >7. *tests/ci_build/pylintrc:* ok
> > >8. *example/image-classification/predict-cpp/image-
> > > classification-predict.cc
> > ><http://classification-predict.cc/>* - yes, mutiple opinions on
> this
> > > one
> > >during the voting process too.
> > >9. *gradle-wrapper *- yes, I remember that one too. I am hoping for
> > some
> > >suggestion on how this can be handled without breaking anything.
> > >
> > > Best,
> > > Meghna
> > >
> > > On Wed, Jan 24, 2018 at 4:47 PM, Marco de Abreu <
> > > marco.g.ab...@googlemail.com> wrote:
>

Re: Please Help Fix MXNet Licensing Issues for the next Release!

[Hen]

The last paragraph of the LICENSE looks suspect. I doubt we've taken code
from the BSD project. I would suggest deleting that last paragraph.

With MIT and BSD licenses you do have to be careful that the text of each
is the same. Each term is often used for a family of related licenses.

Additionally each of MIT and BSD typically has a Copyright
statement accompanying it. If the rules say to remove that from LICENSE,
then we should be adding it to the NOTICE.

Hen


On Wed, Jan 24, 2018 at 5:07 PM, Meghna Baijal 
wrote:

> Marco,
> Thanks a lot for looking through this ! Some comments below -
>
>1. *R-package:* Before we create the final tarball for the release, the
>R-package is explicitly removed from the cloned MXNet repo. The only
> info I
>have in this regard is that “there are some unresolved licensing issues
> in
>this package and cannot be released”.
>2. *Dockerfiles:* You can refer to this PR for details
>https://github.com/apache/incubator-mxnet/pull/9500. I plan to handle
>this differently next time.
>3. *perl-package*: There were some copyright issues in the past with
>this folder. I just excluded it to be on the safer side, but I think it
>should be ok to add the ASF header here.
>4. *docs/** - Yes, agreed. I will add the licenses where needed but I
>still think its safer to exclude the folder as a whole from the RAT
> check.
>5. *CODEOWNERS* - agreed, will add to the list of excluded files.
>6. *appveyor.yml:* Is this file relevant anymore? I will add a license
>anyway.
>7. *tests/ci_build/pylintrc:* ok
>8. *example/image-classification/predict-cpp/image-
> classification-predict.cc
><http://classification-predict.cc/>* - yes, mutiple opinions on this
> one
>during the voting process too.
>9. *gradle-wrapper *- yes, I remember that one too. I am hoping for some
>suggestion on how this can be handled without breaking anything.
>
> Best,
> Meghna
>
> On Wed, Jan 24, 2018 at 4:47 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com> wrote:
>
> > Hi Meghna,
> >
> > thank you for driving the licensing issues!
> >
> > - R-package: In the linked wiki, you're mentioning that R-package is not
> a
> > part of the release. Could you please elaborate? From my understand, all
> > files in the GitHub repository are part of the release.
> > - Dockerfiles: I just checked another Apache-project [1] and it seems
> like
> > they are successfully applying the license to dockerfiles. Do you see any
> > issues in doing so?
> > - perl-package: Same as R-package
> > - docs/*: Just my personal opinion, but I agree that it might not be a
> good
> > idea to have the license inside every file as some of them are directly
> > getting sent out. But we have some shell-scripts inside this directory,
> so
> > they'll need proper licensing.
> > - CODEOWNERS: This is a setting file got our GitHub repository and not
> part
> > of the release or the software itself. Thus I'd say that there's no need
> > for a license - especially considering that the content itself has no
> > value.
> > - appveyor.yml: I'd treat this like the Jenkinsfile and apply a license.
> > - tests/ci_build/pylintrc: I'd add a license
> > - example/image-classification/predict-cpp/image-
> > classification-predict.cc:
> > It seems like Mu has had issues with the licensing of this file in the
> > past. Maybe consult him
> > - gradle-wrapper: I don't have a link, but I'm very sure that there was a
> > discussion regarding this jar-file during the last release.
> >
> > Anybody, please feel free to correct me if I made a wrong assumption.
> >
> > Best regards,
> > Marco
> >
> > [1]: https://github.com/apache/bookkeeper/blob/master/docker/Dockerfile
> >
> > On Wed, Jan 24, 2018 at 4:27 PM, Meghna Baijal <
> meghnabaijal2...@gmail.com
> > >
> > wrote:
> >
> > > Hello,
> > >
> > > This is an update on the current status of the license fixes (all
> details
> > > in the wiki linked below)–
> > >
> > >1. I am constantly updating this wiki, so you can check it at any
> time
> > >to know the status -
> > >https://cwiki.apache.org/confluence/display/MXNET/
> > MXNet+Source+Licenses
> > >2. All 7 PRs have been merged however if anyone has any comments on
> > >these changes please let me know.
> > >3. There are still 6-7 files that do not have a license and are
> > failing
> > >the RAT check. These are files I was not enti

Re: Submitting changes to the MXNet website

[Hen]

Or maybe the README for https://github.com/apache/incubator-mxnet-site ?

On Tue, Jan 23, 2018 at 1:15 PM, Haibin Lin 
wrote:

> Hi Marco,
>
> Thanks for the clarification. I was wondering about the website build
> process, too. I wonder if it will be beneficial to create a page on Apache
> wiki so that people not on the mailing list will be also aware of this?
>
> Best,
> Haibin
>
> On Tue, Jan 23, 2018 at 1:08 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com> wrote:
>
> > Hello,
> >
> > I have received a few questions regarding the publish and change process
> of
> > the website at http://mxnet.incubator.apache.org/. Basically the process
> > is
> > as follows:
> >
> > Every night, the job at [1] downloads the current state of the master
> > repository and executes the script located at [2]. The output is then
> > picked up by the job at [3] and pushed to our repository at [4], which is
> > mirrored to an ASF-repository and automatically published to the website.
> > But there is one important catch during this publish-step:
> >
> > Every time the results get pushed to this website-repository, a 'rm -rf
> *;
> > git rm -r *" is being executed, leading to all manual changes on the
> > repository at [4] being overridden. This behaviour was copied from the
> old
> > CI hosted under Apache Infra. I can only guess, but my bet for this
> design
> > decision was probably to ensure consistency between the website and the
> > docs in the MXNet main repository.
> >
> > So what does this mean for the community? In fact, PRs to the repository
> at
> > [4] have no effect. Instead, please create a PR at [5] in order to get
> the
> > changes actually published to the website.
> >
> > @Committers: Please decline any PRs at [4] and ask contributors to submit
> > them to [5].
> >
> > Best regards,
> > Marco
> >
> > [1]: http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-
> mxnet-build-site/
> > [2]:
> > https://github.com/apache/incubator-mxnet/blob/master/
> > docs/build_version_doc/build_doc.sh
> > [3]: http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-
> > mxnet-publish-site/
> > [4]: https://github.com/apache/incubator-mxnet-site
> > [5]: https://github.com/apache/incubator-mxnet
> >
>

Re: dmlc packages into 3rdpary

[Hen]

Before the next release we need some kind of "this isn't Apache code" so
the reviewers can treat it accordingly. Putting in third-party/ works for
me.

I suspect it will remain controversial; but at least the focus will be in
the right way.

Hen

On Fri, Jan 19, 2018 at 11:43 AM, Chris Olivier 
wrote:

> Is the general consensus to move the dmlc packages into 3rdparty?
>
> If so, I can submit a PR that does this.
>
> I have no strong opinion on it either way and am very open to other
> opinions on this.
>
> -Chris
>

Re: Podling Report Reminder - January 2018

[Hen]

Thanks Bhavin. Let's definitely get that as an active conversation.

In general I'm okay with the report. I'm having login pains with the wiki
(yay for non-ldap service), but chatted with Suneel on IM and he said he'd
update the wiki for me (much appreciated Suneel, thank you :) ).

Hen

On Tue, Jan 2, 2018 at 10:19 PM, Bhavin Thaker 
wrote:

> Hi Henri, dev@
>
> 1/  No contributors have been proposed so far but there have been few folks
> who have had significant contributions to MXNet. There is no email thread
> yet. I propose that the committers review the contributions on a  quarterly
> basis.
>
> 2/ The hope is to get more contributors based on various MXNet talks at
> conferences, universities, etc. If anybody has suggestions on how to
> increase the contributions to MXNet, please share your ideas.
>
> Bhavin Thaker.
>
> On Tue, Jan 2, 2018 at 9:15 PM Hen  wrote:
>
> > Few items that flagged for me in the report:
> >
> > 1/  "We are working on finding more contributors to the project." +
> "There
> > is a plan to convert more contributors into committers in early 2018."
> >
> > I haven't seen this being discussed; is there a thread? Or if not, what's
> > the plan here?
> >
> > 2/ Noting that there needs to be more blogging on the Apache blog. I
> would
> > assume that an Apache blog entry is Apache 2.0 licensed; thus it would be
> > perfectly fine imo to post on the Apache site and then on the AWS site
> > (with reference to it being previously posted on the Apache blog).
> >
> > Hen
> >
> >
> > On Sun, Dec 31, 2017 at 4:31 PM, Suneel Marthi 
> wrote:
> >
> > > Report's been filed - mentors please comment and sign-off
> > >
> > > On Sun, Dec 31, 2017 at 12:42 PM, Suneel Marthi 
> > > 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 
> > 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 boa

Re: Podling Report Reminder - January 2018

[Hen]

Few items that flagged for me in the report:

1/  "We are working on finding more contributors to the project." +  "There
is a plan to convert more contributors into committers in early 2018."

I haven't seen this being discussed; is there a thread? Or if not, what's
the plan here?

2/ Noting that there needs to be more blogging on the Apache blog. I would
assume that an Apache blog entry is Apache 2.0 licensed; thus it would be
perfectly fine imo to post on the Apache site and then on the AWS site
(with reference to it being previously posted on the Apache blog).

Hen


On Sun, Dec 31, 2017 at 4:31 PM, Suneel Marthi  wrote:

> Report's been filed - mentors please comment and sign-off
>
> On Sun, Dec 31, 2017 at 12:42 PM, Suneel Marthi 
> 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  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*
> >> >
> >>
> >
> >
>

Note on when to Delete GitHub Comments

[Hen]

I added a note to the Development Process GitHub on when to delete GitHub
comments:

https://cwiki.apache.org/confluence/display/MXNET/Development+Process

Basically a reminder that it should be a PMC decision, or if needing to
move quickly a decision of the PMC Chair (mentors while a podling).

Mentioning here to encourage discussion/edit proposals if needed.

---

That gives me a chance to mention a PMC Chair's role.

When MXNet graduates, one of the initial PMC members will be nominated to
the board to be the chair. That chair is a VP/Officer of the 501(c)(3) and
is the one who is ultimately responsible to the board for the project. Very
occasionally a chair may have to do something without consulting with the
PMC as a whole, and they're expected to get it right.

Hen

Re: Perl module copyright/author notation

[Hen]

Thanks Sergey :)

Cc'd to dev@ as an FYI.

Hen

On Thu, Nov 30, 2017 at 10:58 PM, Sergey Kolychev <
sergeykolychev.git...@gmail.com> wrote:

> Yes, sure please change it as needed. Thanks!
>
> On Thu, Nov 30, 2017 at 12:44 PM, Hen  wrote:
>
>> Hi Sergey,
>>
>> In looking at the mxnet perl-package, I noticed that you have your
>> copyright listed explicitly, and in many files.
>>
>> The typical approach for Apache code is to keep copyrights in NOTICE (if
>> they are covered by the CLA), and the majority of contributors don't put
>> their copyright in, instead focusing on contributor/author.
>>
>> Are you good if I change the code to list you (and anyone else who works
>> on it and wants to add themselves) to the AUTHORS section of the
>> README.md/MXNet.pm, and remove the explicit Copyright statement?
>>
>> Thanks,
>>
>> Hen
>>
>
>

Perl module copyright/author notation

[Hen]

Hi Sergey,

In looking at the mxnet perl-package, I noticed that you have your
copyright listed explicitly, and in many files.

The typical approach for Apache code is to keep copyrights in NOTICE (if
they are covered by the CLA), and the majority of contributors don't put
their copyright in, instead focusing on contributor/author.

Are you good if I change the code to list you (and anyone else who works on
it and wants to add themselves) to the AUTHORS section of the
README.md/MXNet.pm, and remove the explicit Copyright statement?

Thanks,

Hen

FYI: [VOTE] Apache MXNet (incubating) 1.0.0 release RC0

[Hen]

Sorry, I should have cc'd dev@ on this.

-- Forwarded message --
From: Hen 
Date: Wed, Nov 29, 2017 at 1:59 PM
Subject: Re: [VOTE] Apache MXNet (incubating) 1.0.0 release RC0
To: gene...@incubator.apache.org


Thanks Justin.

Some comments inline on ones I don't think need fixing; but afaict from
MXNet dev@ activity the plan is to produce a new release and restart the
vote.

On Tue, Nov 28, 2017 at 3:54 PM, Justin Mclean 
wrote:

> Hi,
>
> -1 binding due to license, header issues and having a compiled jar in a
> source release.
>
> I checked:
> - incubating in name
> - signatures and hashes correct
> - DISCLAIMER exists
> - LICENSE has issues (see below) I also note that license issues brought
> up last time have not all been addressed. [22]
> - NOTICE seem rather brief considering the number of Apache licensed
> inclusion do any of them have NOTICE files?
>

We can double check, but I know the ones I've looked at didn't use NOTICE
files (the various dmlc/ projects). Plus as these are GitHub submodules, if
they did the NOTICE would automatically come over.


> - A number of source file are missing license headers e.g. [15][16] [18]
> [19] and many others
>

Many of these are not Apache MXNet files but from dependencies. I'll
suggest on dev@ that these submodules be moved into a third-party/
directory. Given the impact of that to builds etc, I'm hoping that can go
in a subsequent release.



> - A number of source look to have had the ASF header incorrectly added.
> - Binary included in source release [20] Note there’s an unresolved legal
> issue about this [21]
>
> Have you run rat on this release it would of help pick up most of these
> issues?
>
> In this file [1] there’s a copyright notice but it also has an ASF header
> which is a little odd. This also occurs in a number of other places.
>

This came up in the previous release (but the opposite way).

When the code came in from MXNet, it had "Copyright Contributors". We
removed that because 'what a useless statement' :), however as there are
400+ contributors and not everyone has signed a CLA, the previous release
vote asked the project to put it back in again, so they did. It's an
eyesore, but we're a bit stuck unless we're prepared to move away from our
rules of "Never remove or move a Copyright statement without approval" and
"Never edit a copyright statement".

We could (I guess) put a comment above it of "# Original MXNet copyright
statement" or some such.


>
> This file [2] also look to incorrectly have an ASF header and it’s unclear
> how the original code is licensed. From a quick like their seems to be many
> files that incorrectly have ASF headers on them e.g. [5][6][7]
> [10][12][13][14] and others.
>
> This file [3] (and others) looks to come from the TVM project which is not
> mentioned in license.
>

Why would it be? We only have to include the LICENSE from TVM, we don't
need to name them.  If TVM want to be identified, they should add a NOTICE
file.


>
> The license for this file [4] is missing from license.
>
> The link for JQuery [8] is missing from the license. Also missing license
> for these files [9][11][17] and probably others.
>
> At this point I gave up so there may be other issues.
>

Understood. A lot of these are systematic characteristics of the project
rather than flat out issues, but definitely some good finds here too.


>
> It also a good idea to publish your keys:
> gpg: assuming signed data in 'apache-mxnet-src-1.0.0.rc0-in
> cubating.tar.gz'
> gpg: Signature made Sat 25 Nov 07:48:02 2017 AEDT
> gpg:using RSA key 80FD81D7703DF31B
> gpg: requesting key 80FD81D7703DF31B from hkps server
> hkps.pool.sks-keyservers.net
> gpg: Can't check signature: No public key
>
> It’s also a good idea to sign with an apache email address rather than a
> gmail one.
>
> I’m also curious about “CODEOWNERS” file as that doesn’t seem to fit with
> any Apache model I’m aware of.
>

This is a GitHub feature. The name is unfortunate and perhaps we could add
a comment explaining what it is. It allows for automatic addition of
reviewers to a pull request. Kind of like a watch on the code.

The important thing is that a project should never tell a committer they
can't put their name in as a codeowner nee automatic-reviewer.


>
> In “CONTRIBUTORS” there’s a long list of contributors - are their plan to
> make any of these people committers?
>
> Thanks,
> Justin
>
> 1. ./apache-mxnet-src-1.0.0.rc0-incubating/perl-package/AI-MXNe
> t/lib/AI/MXNet.pm
> 2. ./apache-mxnet-src-1.0.0.rc0-incubating/example/image-classi
> fication/predict-cpp/image-classification-predict.cc
> 3. ./apach

Re: CODEOWNERS file being removed

[Hen]

Was there more discussion than Justin's question about it on general@?

My memory of CODEOWNERS was that it was related to some code review tool,
but looking at the history of dev@ I only see:

"Can't have changes merged into it until changes to files that have a
designated code owner <https://help.github.com/articles/about-codeowners/>
have been approved by that owner"

Reading GitHub:

"Code owners are automatically requested for review when someone opens a
pull request that modifies code that they own. When someone with admin or
owner permissions has enabled required reviews
<https://help.github.com/articles/enabling-required-reviews-for-pull-requests/>,
they also can optionally require approval from a code owner before the
author can merge a pull request in the repository."

I think that having a notion where anyone can put their name down as an
automatic reviewer is a good one. Apart from the unfortunate name of the
file, this should fit with Apache's culture (as long as more than one
committer can, and as long as we never say a committer can't decide to put
themselves as a codeowner). A comment in the file explaining this would be
good.

We should however, never enable the code-owner option of required reviews.
As that's an Admin/Owner feature, and I don't think Apache Infra would do
that, I think we're good there.

So my suggestion would be to add a comment that this is an
automatically-listed-on-reviews tool.

Hen


On Wed, Nov 29, 2017 at 12:35 PM, Chris Olivier 
wrote:

> Per suggestion from Apache, we are removing CODEOWNERS file from root of
> mxnet.
> If there are any objections, please voice them:
>
> Here are the contents of rht file:
>
> # Owners of Apache MXNet
>
> # Global owners
> *@apache/mxnet-committers
>
> # Owners of language bindings
> R-package/*   @thirdwing
> scala-package/*   @javelinjs
> perl-package/*@sergeykolychev
>
> # CMake owners
> CMakeLists.txt@cjolivier01
> cmake/*  @cjolivier01
>

Re: 3rdparty packages as submodules

[Hen]

What's the license of each?

By submodule do you mean git pointing to a url of a specific tag/branch, or
copying the actual code directly in?

On Tue, Nov 21, 2017 at 4:51 PM, Stephen Bull  wrote:

> I like 3rdparty, and definitely helps newcomers too. As long as it's kept
> relatively clean and up-to-date of course (not sure if that's a case for or
> against however!). :)
>
> On Mon, 20 Nov 2017 at 19:25 Chris Olivier  wrote:
>
> > I support putting gtest in 3rdparty as well. That being said, which of
> > these should we be storing in the Apache repository and which do we pull
> > from their source repositories. What’s standard practice in this case for
> > Apache projects?
> >
> > On Mon, Nov 20, 2017 at 5:54 PM Pedro Larroy <
> pedro.larroy.li...@gmail.com
> > >
> > wrote:
> >
> > > We could also add gtest as well for example.
> > >
> > >
> > >
> > > I would like to point out that is quite cumbersome to get your code
> > > tested and ready before sending a PR, this includes installing
> > > cpplint, pylint, gtest…
> > >
> > > Installing gtest and bootstrapping it is not completely trivial.
> > >
> > >
> > >
> > > Kind regards.
> > >
> > > On Mon, Nov 20, 2017 at 11:23 AM, Eric Xie  wrote:
> > > > I'm fine with a 3rdparty folder. Not sure about apache legal.
> > > >
> > > > On 2017-11-17 10:25, Chris Olivier  wrote:
> > > >> All,
> > > >>
> > > >> I often find it desirable to have a method for 3rdparty packages to
> be
> > > >> included (possibly optionally) in a 3rdparty directory.   We do this
> > > with
> > > >> 'cub' to some degree, but it's in the root and is actually a fork in
> > the
> > > >> dmlc repository.  Some samples of what might go in there:
> > > >>
> > > >> 1) Intel OpenMP (llvm-openmp) -- In order to use Intel OMP by
> default
> > > >> 2) gperftools -- In order to build statically with -fPIC, which
> isn't
> > > the
> > > >> case with the general distribution
> > > >> 3) mkl-dnn -- In order to build and have debug information available
> > for
> > > >> mkl-dnn (and possibly submit bugfixes)
> > > >>
> > > >> What do you all think?
> > > >>
> > > >> -Chris
> > > >>
> > >
> >
>

Re: AWS contributing ONNX-MXNet

[Hen]

It was contributed to 'ONNX'. Which is a joint Facebook/Microsoft project
of some kind ( http://onnx.ai/ ).

Hen

On Fri, Nov 17, 2017 at 12:35 AM, Isabel Drost-Fromm 
wrote:

>
>
> Am 16. November 2017 23:04:05 MEZ schrieb "Lupesko, Hagay" <
> lupe...@gmail.com>:
> >Today AWS announced contributing ONNX-MXNet,
>
>
> Just for clarification: this package is going to be/ intended to be
> contributed where to? Or do you mean "published under a free and open
> source license"?
>
> Isabel
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>

Re: FW: AWS contributing ONNX-MXNet

[Hen]

ames be kept in
files (I presume you're referring to the Author comment in the tutorial
file as I didn't see any others).

The Apache license requires that (section 4):

- You must give any other recipients of the Work or Derivative Works a copy
of this License; and
- You must cause any modified files to carry prominent notices stating that
You changed the files; and
- You must retain, in the Source form of any Derivative Works that You
distribute, all copyright, patent, trademark, and attribution notices from
the Source form of the Work, excluding those notices that do not pertain to
any part of the Derivative Works; and
- If the Work includes a "NOTICE" text file as part of its distribution,
then any Derivative Works that You distribute must include a readable copy
of the attribution notices contained within such NOTICE file,

Going through each in turn:

1) The repo contains a copy of the Apache 2.0 license,
2) 2 of the 6 files contain prominent notices; I agree that the other 4
should contain a prominent notice if they're derived (I haven't compared
the files, but I don't doubt your research),
3) There are no additional copyright, patent, trademark or attribution
notices in the files copied (this is why Apache requires a source header
for its projects; DMLC does not appear to have source headers on their
files, its equivalent of Apache's legal committee should strongly think
about that standardizing on that for all its projects imo);
4) There is no NOTICE file (again, imo the DMLC legal thinkers should
strongly think about having NOTICE files imo).

So agreed that there's a change to make, but there's no requirement to keep
author's names in files. Note that there is a practice (and it's a
recommended or even mandatory legal practice, I'm not sure which) to keep a
Copyright Owner's name in a file, but author and copyright owner are
different concepts.

Hen

Re: [VOTE] A Separate CI System for Apache MXNet (incubating)

[Hen]

+1 on Jenkins; makes sense to me to keep it within the same tech as used on
the Apache side.

(Noting that as this is not a required vote, I don't believe this needs to
go to general@incubator or need 3 mentor +1s). As long as 3 committers are
+1 it's good in my opinion.

Hen

On Tue, Nov 14, 2017 at 9:51 AM, kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> @Sandeep, while I've had good experiences with CodeBuild, I'm not sure if
> it would address the needs of this project due to lack of instance type
> options.  For example I don't believe they support GPU instances, which are
> required for a large portion of our build/test process.  I'd propose we use
> simple reactive auto-scaling groups (based on Jenkins queue length) which
> should also be quite easy to maintain.
>
> -Kellen
>
> On Mon, Nov 13, 2017 at 5:25 AM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> wrote:
>
> > +1 for [1]  (A setup separated from Apache Jenkins)
> >
> > On Mon, Nov 13, 2017 at 4:50 AM, sandeep krishnamurthy
> >  wrote:
> > > +1 for [1] Jenkins (A setup separated from Apache Jenkins) - with
> > > preferably AWS Code Build integration to reduce the size of
> > infrastructure
> > > we need to maintain.
> > >
> > > Thanks,
> > > Sandeep
> > >
> > > On Fri, Nov 10, 2017 at 11:57 AM, Bhavin Thaker <
> bhavintha...@gmail.com>
> > > wrote:
> > >
> > >> +1 for [1] Jenkins (A setup separated from Apache Jenkins) - with
> > various
> > >> plugins.
> > >>
> > >> Bhavin Thaker.
> > >>
> > >> On Fri, Nov 10, 2017 at 11:39 AM, Madan Jampani <
> > madan.jamp...@gmail.com>
> > >> wrote:
> > >>
> > >> > +1 for (1)
> > >> >
> > >> > On Thu, Nov 9, 2017 at 4:41 PM, Meghna Baijal <
> > >> meghnabaijal2...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Hi All,
> > >> > > A need has been identified for MXNet’s CI/CD setup to move away
> from
> > >> the
> > >> > > Apache Jenkins Service. Over the past few days there has been
> active
> > >> > > discussion on the necessary and advanced features for such a
> system
> > and
> > >> > the
> > >> > > various options available. These are being tracked in this Google
> > Doc
> > >> > > <https://docs.google.com/document/d/
> 17PEasQ2VWrXi2Cf7IGZSWGZMawxDk
> > >> > dlavUDASzUmLjk/edit> (and
> > >> > > are also in the pdf attached).
> > >> > >
> > >> > > I would like to start a vote to choose the framework for this new
> > CI/CD
> > >> > > system. The options are -
> > >> > > [1] Jenkins (A setup separated from Apache Jenkins) - with various
> > >> > plugins
> > >> > > [2] TeamCity
> > >> > > [3] Travis CI
> > >> > > [4] GitLabCI
> > >> > > [5] BuildBot
> > >> > > [6] Other - Please Name
> > >> > >
> > >> > > Please feel free to add a comment to support your choice.
> > >> > > This vote will be open from now until the end of the day on Monday
> > >> > > 11/13/2017
> > >> > >
> > >> > > Thanks,
> > >> > > Meghna Baijal
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Sandeep Krishnamurthy
> >
>

Re: The process for a patch release

[Hen]

Yes. You would just do it quicker (if such was truly needed). You would
still need at least 3 +1s, and at the moment there is the crutch that you
would also need 3 Incubator PMC +1s (or the first 3 would have to be IPMC).

If it's a security vulnerability, then we would use private@ and confer
with security@ on the process.

Hen

On Tue, Nov 7, 2017 at 1:45 PM, Chris Olivier  wrote:

> Do we need a vote for a critical patch release?
>
> On Tue, Nov 7, 2017 at 12:08 PM, Meghna Baijal  >
> wrote:
>
> > Hi All,
> > A patch release is being planned for Apache MXNet(incubating) to include
> > some important bug fixes.
> > I want to confirm that for a patch release, there is no RC and voting
> step.
> >
> > Effectively the process looks something like this -
> >
> > Step 1: Cherrypick all the necessary bugfixes into the existing release
> > branch.
> >
> > Step 2: Add a PR to update the version number etc (Example
> > https://github.com/apache/incubator-mxnet/commit/
> > e0c7906693f0c79b0ce34a4d777c26a6bf1903c1
> > )
> >
> > Step 3: Make sure the release branch build passes on
> builds.apache.jenkins
> > and nightly tests
> >
> > Step 4: tag the release branch in GitHub with the release tag - example
> > 0.12.1
> >
> > Step 5: Download from the repo and checkout the tag, package it and Sign
> > the src code into 'apache-mxnet-src-0.12.1-incubating'
> >
> > Step 6: Validate the signatures and test
> >
> > Step 7: Update the website. (pip and docker release)
> >
> > Step 8: Upload the src tar to the final destination -
> > http://www.apache.org/dist/incubator/mxnet/
> >
> > Step 9: Announce the patch release
> >
> > Thanks,
> > Meghna Baijal
> >
>

Re: The process for a patch release

[Hen]

I thought a patch release was exactly the same as a full release; except
that there is less discussion of the features involved.

Did you see a more lightweight release process described somewhere? I'd
expect an RC and vote.

Hen

On Tue, Nov 7, 2017 at 12:08 PM, Meghna Baijal 
wrote:

> Hi All,
> A patch release is being planned for Apache MXNet(incubating) to include
> some important bug fixes.
> I want to confirm that for a patch release, there is no RC and voting step.
>
> Effectively the process looks something like this -
>
> Step 1: Cherrypick all the necessary bugfixes into the existing release
> branch.
>
> Step 2: Add a PR to update the version number etc (Example
> https://github.com/apache/incubator-mxnet/commit/
> e0c7906693f0c79b0ce34a4d777c26a6bf1903c1
> )
>
> Step 3: Make sure the release branch build passes on builds.apache.jenkins
> and nightly tests
>
> Step 4: tag the release branch in GitHub with the release tag - example
> 0.12.1
>
> Step 5: Download from the repo and checkout the tag, package it and Sign
> the src code into 'apache-mxnet-src-0.12.1-incubating'
>
> Step 6: Validate the signatures and test
>
> Step 7: Update the website. (pip and docker release)
>
> Step 8: Upload the src tar to the final destination -
> http://www.apache.org/dist/incubator/mxnet/
>
> Step 9: Announce the patch release
>
> Thanks,
> Meghna Baijal
>

Using Mirrors

[Hen]

Noting that we need to move to using the Apache Mirrors for downloads
rather than direct links to apache.org/dist.

https://reference.apache.org/committer/website-policy

I did a bit of digging, and it looks like we can just refer to this:

https://www.apache.org/dyn/closer.cgi/dev/incubator/mxnet/0.12.0/

Note that you have to have a delay between publishing your release, and
announcing your release, so that the mirrors have time to sync. I believe
that's 24 hours.

Hen

On Wed, Nov 1, 2017 at 12:27 PM, Chris Olivier 
wrote:

>
>
> A Link to the Download is here: http://www.apache.org/dist/
> incubator/mxnet/
>
>
>

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Hen]

Random question - can the CI be split such that the Apache CI is doing a
basic set of checks on that hardware, and is hooked to a PR, while there is
a larger "Is trunk good for release?" test that is running periodically
rather than on every PR?

ie: do we need each PR to be run on varied hardware, or can we have this
two tier approach?

Hen

On Fri, Oct 20, 2017 at 1:01 PM, sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> Hello all,
>
> I am hereby opening up a discussion thread on how we can stabilize Apache
> MXNet CI build system.
>
> Problems:
>
> 
>
> Recently, we have seen following issues with Apache MXNet CI build systems:
>
>1. Apache Jenkins master is overloaded and we see issues like - unable
>to trigger builds, difficult to load and view the blue ocean and other
>Jenkins build status page.
>2. We are generating too many request/interaction on Apache Infra team.
>   1. Addition/deletion of new slave: Caused from scaling activity,
>   recycling, troubleshooting or any actions leading to change of slave
>   machines.
>   2. Plugins / other Jenkins Master configurations.
>   3. Experimentation on CI pipelines.
>3. Harder to debug and resolve issues - Since access to master and slave
>is not with the same community, it requires Infra and community to dive
>deep together on all action items.
>
> Possible Solutions:
>
> ==
>
>1. Can we set up a separate Jenkins CI build system for Apache MXNet
>outside Apache Infra?
>2. Can we have a separate Jenkins Master in Apache Infra for MXNet?
>3. Review design of current setup, refine and fill the gaps.
>
> @ Mentors/Infra team/Community:
>
> ==
>
> Please provide your suggestions on how we can proceed further and work on
> stabilizing the CI build systems for MXNet.
>
> Also, if the community decides on separate Jenkins CI build system, what
> important points should be taken care of apart from the below:
>
>1. Community being able to access the build page for build statuses.
>2. Committers being able to login with apache credentials.
>3. Hook setup from apache/incubator-mxnet repo to Jenkins master.
>
>
> Irrespective of the solution we come up, I think we should initiate a
> technical design discussion on how to setup the CI build system. Probably 1
> or 2 pager documents with the architecture and review with Infra and
> community members.
>
> ***There were few proposal and discussion on the slack channel, to reach
> wider community members, moving that discussion formally to this list.
>
>
> My Proposal: Option 1 - Set up separate Jenkins CI build system.
>
> Thanks,
>
> Sandeep
>
>
>
> --
> Sandeep Krishnamurthy
>

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Hen]

ssue
themselves, they are not beholden to a third party to fix it for them (and
thus need an SLA). For something like OpenOffice there is an obvious issue
there, many of its users would need longer to come up to speed to fix the
issue and the likely reply; but for MXNet, many of its users do know how to
code and don't need to go learn a programming language before starting to
look at the bug. This is also why it's very important that the MXNet
documentation explains how to get the source, how to build the source, and
how to contribute.

Security vulnerabilities are a little different. While good intentions
remain, it's assumed that a healthy project can fulfill the good
intentions, and repeated security issues without resolution will quickly
raise the question of whether the project is not mature enough for its user
base.

Hen

Website issues

[Hen]

Committers - the MXNet website needs some work to meet Apache's policies:

Site: http://mxnet.incubator.apache.org/
Policy: https://www.apache.org/foundation/marks/pmcs

Here are some I've flagged:
https://github.com/apache/incubator-mxnet-site/issues

Could someone work on this soon? It's been a long time with some basic
things not done yet.

Hen

Re: Draft of blog post for MXNet v0.12 release

[Hen]

It was noted that you've signed up. I've added you to the blog Sandeep :)

On Tue, Oct 31, 2017 at 3:37 PM, Hen  wrote:

> Confirmed on the email.
>
> Can you sign in at blogs.apache.org using your Apache LDAP credentials
> please?
>
> That will add you to the pool of users, and then one of the mentors can
> add you to the blog :)
>
> Hen
>
>
> On Tue, Oct 31, 2017 at 2:08 PM, sandeep krishnamurthy <
> sandeep.krishn...@gmail.com> wrote:
>
>> Hello Hen,
>>
>> I can help in publishing the blog post at blogs.apache.org/MXNet with
>> contents from draft by Sukwon posted here for review from community -
>> https://cwiki.apache.org/confluence/display/MXNET/Draft+of+
>> blog+post+for+MXNet+v0.12+release
>>
>>
>> Just confirming here - after we post the blog, we will be emailing to - "
>> annou...@apache.org" and "dev@mxnet.incubator.apache.org" with the blog
>> link. Correct?
>>
>> Regards,
>> Sandeep
>>
>> On Mon, Oct 30, 2017 at 4:48 PM, Hen  wrote:
>>
>> > Related question - which committer wants to publish the blog? It needs
>> to
>> > be a member of the project.
>> >
>> > On Mon, Oct 30, 2017 at 4:41 PM, Sally Khudairi  wrote:
>> >
>> > > Thanks, Sukwon; hello Chris and MXNet pPMC.
>> > >
>> > > I have been discussing this with Sukwon and have agreed on the
>> > > following tactics:
>> > > 1) blog post published on blogs.apache.org/MXNet from the pPMC;
>> > > 2) email sent to annou...@apache.org and the Apache MXNet
>> (incubating)
>> > >lists; and3) Sally will include in the Apache Weekly News Round-up
>> > once
>> > > the email
>> > >to announce@ is in the archives
>> > > There is no formal press activity surrounding this release, nor is
>> there
>> > > any official ASF publicity on this release, as the project is still
>> > > undergoing incubation.
>> > > Kind regards,
>> > > Sally
>> > >
>> > > - - -
>> > > Vice President Marketing & Publicity
>> > > The Apache Software Foundation
>> > >
>> > > Tel +1 617 921 8656
>> > > Skype sallykhudairi
>> > >
>> > >
>> > > On Mon, Oct 30, 2017, at 19:11, Suk Won Kim wrote:
>> > > > Yes,
>> > > > I have been in touch with Sally for this post, and she is aware
>> > > > of this.> It will not be published via official press release.
>> > > >
>> > > > On Mon, Oct 30, 2017 at 4:10 PM, Chris Mattmann
>> > > >  wrote:>> Has this been in coordination with
>> > > Sally? There’s a pretty hard and
>> > > >> fast Incubator rule to not promote>>  Podlings via official press
>> > > channels – where will this be published?>>
>> > > >>  Cheers,
>> > > >>  Chris
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>  On 10/30/17, 4:08 PM, "Suk Won Kim"  wrote:
>> > > >>
>> > > >>  Created a page in cwiki for a draft of blog post for MXNet
>> v0.12
>> > > >>  release.
>> > > >>  https://cwiki.apache.org/confluence/display/MXNET/
>> > > Draft+of+blog+post+for+MXNet+v0.12+release
>> > > >>
>> > > >>  Thanks.
>> > > >>  --
>> > > >>
>> > > >> *Sukwon Kim, *>>
>> > > >>
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > *Sukwon Kim, *
>> > > >
>> > > > Senior Product Manager-Technical,
>> > > > Amazon Web Services (AWS) EC2
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Sandeep Krishnamurthy
>>
>
>

Re: Draft of blog post for MXNet v0.12 release

[Hen]

High level thoughts:

* There's no "go to  to download the new version"
* I assume the title will be "Apache MXNet 0.12 released!" or some such; or
if the first line is meant to be the title (*Apache MXNet Release Adds
Support for New NVIDIA Volta GPUs and Sparse Tensor*), it could do with the
version there too.
* Perhaps include a tweet url in the blog and invite them to retweet? Not
sure if that's too needy :)
* After the two features are mentioned, I think there should be a summing
up section. Something that invites the user to try out the new release (the
go to link in my first thought) and then invites them to come
contribute/chat (info on dev@ + Slack).

A difference between an open source project and a company product is that
your users are often the pool you source new project members from. So a
release is both an invitation to them to try out the new version, and your
recruiting pipeline.

Hen



On Mon, Oct 30, 2017 at 4:08 PM, Suk Won Kim  wrote:

> Created a page in cwiki for a draft of blog post for MXNet v0.12 release.
> https://cwiki.apache.org/confluence/display/MXNET/
> Draft+of+blog+post+for+MXNet+v0.12+release
>
> Thanks.
> --
>
> *Sukwon Kim, *
>

Re: Draft of blog post for MXNet v0.12 release

[Hen]

Confirmed on the email.

Can you sign in at blogs.apache.org using your Apache LDAP credentials
please?

That will add you to the pool of users, and then one of the mentors can add
you to the blog :)

Hen


On Tue, Oct 31, 2017 at 2:08 PM, sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

> Hello Hen,
>
> I can help in publishing the blog post at blogs.apache.org/MXNet with
> contents from draft by Sukwon posted here for review from community -
> https://cwiki.apache.org/confluence/display/MXNET/
> Draft+of+blog+post+for+MXNet+v0.12+release
>
>
> Just confirming here - after we post the blog, we will be emailing to - "
> annou...@apache.org" and "dev@mxnet.incubator.apache.org" with the blog
> link. Correct?
>
> Regards,
> Sandeep
>
> On Mon, Oct 30, 2017 at 4:48 PM, Hen  wrote:
>
> > Related question - which committer wants to publish the blog? It needs to
> > be a member of the project.
> >
> > On Mon, Oct 30, 2017 at 4:41 PM, Sally Khudairi  wrote:
> >
> > > Thanks, Sukwon; hello Chris and MXNet pPMC.
> > >
> > > I have been discussing this with Sukwon and have agreed on the
> > > following tactics:
> > > 1) blog post published on blogs.apache.org/MXNet from the pPMC;
> > > 2) email sent to annou...@apache.org and the Apache MXNet (incubating)
> > >lists; and3) Sally will include in the Apache Weekly News Round-up
> > once
> > > the email
> > >to announce@ is in the archives
> > > There is no formal press activity surrounding this release, nor is
> there
> > > any official ASF publicity on this release, as the project is still
> > > undergoing incubation.
> > > Kind regards,
> > > Sally
> > >
> > > - - -
> > > Vice President Marketing & Publicity
> > > The Apache Software Foundation
> > >
> > > Tel +1 617 921 8656
> > > Skype sallykhudairi
> > >
> > >
> > > On Mon, Oct 30, 2017, at 19:11, Suk Won Kim wrote:
> > > > Yes,
> > > > I have been in touch with Sally for this post, and she is aware
> > > > of this.> It will not be published via official press release.
> > > >
> > > > On Mon, Oct 30, 2017 at 4:10 PM, Chris Mattmann
> > > >  wrote:>> Has this been in coordination with
> > > Sally? There’s a pretty hard and
> > > >> fast Incubator rule to not promote>>  Podlings via official press
> > > channels – where will this be published?>>
> > > >>  Cheers,
> > > >>  Chris
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>  On 10/30/17, 4:08 PM, "Suk Won Kim"  wrote:
> > > >>
> > > >>  Created a page in cwiki for a draft of blog post for MXNet
> v0.12
> > > >>  release.
> > > >>  https://cwiki.apache.org/confluence/display/MXNET/
> > > Draft+of+blog+post+for+MXNet+v0.12+release
> > > >>
> > > >>  Thanks.
> > > >>  --
> > > >>
> > > >> *Sukwon Kim, *>>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > *Sukwon Kim, *
> > > >
> > > > Senior Product Manager-Technical,
> > > > Amazon Web Services (AWS) EC2
> > >
> > >
> >
>
>
>
> --
> Sandeep Krishnamurthy
>

Re: Disable 'required status check' for master

[Hen]

This makes sense to me. CI isn't of value if it isn't continuous. +1.

On Tue, Oct 31, 2017 at 12:07 PM, Indhu  wrote:

> Hi,
>
> We have been having issues getting CI to work fast enough. Currently the CI
> is being the bottleneck to get commits in. This is severely impacting
> development. I propose we disable 'required status check' for the master
> branch so that we can development is not impacted. We can work on fixing
> the CI situation in parallel.
>
> Committer,
> Please vote if you are okay with disabling 'required status check' for
> master.
>
> Once we have enough votes, I'll request a mentor to file a ticket with
> infra.
>
> Thanks,
> Indu
>

Re: Slack Subscribe

[Hen]

Looks like someone has sent you an invite.

(Folk, please let the list know when you've invited, otherwise N other
people will burn time; apologies if whomever invited was doing it at
exactly the same time).

On Mon, Oct 30, 2017 at 4:55 PM, Tyler Kvochick 
wrote:

> Hello,
>
> Trying to subscribe to the MXnet slack channel.
>
> thanks
>

Re: Draft of blog post for MXNet v0.12 release

[Hen]

Related question - which committer wants to publish the blog? It needs to
be a member of the project.

On Mon, Oct 30, 2017 at 4:41 PM, Sally Khudairi  wrote:

> Thanks, Sukwon; hello Chris and MXNet pPMC.
>
> I have been discussing this with Sukwon and have agreed on the
> following tactics:
> 1) blog post published on blogs.apache.org/MXNet from the pPMC;
> 2) email sent to annou...@apache.org and the Apache MXNet (incubating)
>lists; and3) Sally will include in the Apache Weekly News Round-up once
> the email
>to announce@ is in the archives
> There is no formal press activity surrounding this release, nor is there
> any official ASF publicity on this release, as the project is still
> undergoing incubation.
> Kind regards,
> Sally
>
> - - -
> Vice President Marketing & Publicity
> The Apache Software Foundation
>
> Tel +1 617 921 8656
> Skype sallykhudairi
>
>
> On Mon, Oct 30, 2017, at 19:11, Suk Won Kim wrote:
> > Yes,
> > I have been in touch with Sally for this post, and she is aware
> > of this.> It will not be published via official press release.
> >
> > On Mon, Oct 30, 2017 at 4:10 PM, Chris Mattmann
> >  wrote:>> Has this been in coordination with
> Sally? There’s a pretty hard and
> >> fast Incubator rule to not promote>>  Podlings via official press
> channels – where will this be published?>>
> >>  Cheers,
> >>  Chris
> >>
> >>
> >>
> >>
> >>  On 10/30/17, 4:08 PM, "Suk Won Kim"  wrote:
> >>
> >>  Created a page in cwiki for a draft of blog post for MXNet v0.12
> >>  release.
> >>  https://cwiki.apache.org/confluence/display/MXNET/
> Draft+of+blog+post+for+MXNet+v0.12+release
> >>
> >>  Thanks.
> >>  --
> >>
> >> *Sukwon Kim, *>>
> >>
> >>
> >
> >
> >
> > --
> > *Sukwon Kim, *
> >
> > Senior Product Manager-Technical,
> > Amazon Web Services (AWS) EC2
>
>

Re: MXNet blog for upcoming release

[Hen]

https://issues.apache.org/jira/browse/INFRA-15407

On Mon, Oct 30, 2017 at 12:12 PM, Hen  wrote:

> Having a blog for the project sounds like a good idea.
>
> I don't see one already existing, and I see other incubator podlings with
> a blog, so I'll go ahead and open a JIRA.
>
> Hen
>
> On Mon, Oct 30, 2017 at 9:29 AM, Suk Won Kim  wrote:
>
>> Hi all,
>> Meghna is going to execute the MXNet v0.12 release on 10/31.
>> I'd like to help her with creating MXNet blog for it.
>> Can you please point me to the instructions how to create a blog?
>> Thanks!
>>
>>
>> --
>>
>> *Sukwon Kim, *
>>
>
>

Re: MXNet blog for upcoming release

[Hen]

Having a blog for the project sounds like a good idea.

I don't see one already existing, and I see other incubator podlings with a
blog, so I'll go ahead and open a JIRA.

Hen

On Mon, Oct 30, 2017 at 9:29 AM, Suk Won Kim  wrote:

> Hi all,
> Meghna is going to execute the MXNet v0.12 release on 10/31.
> I'd like to help her with creating MXNet blog for it.
> Can you please point me to the instructions how to create a blog?
> Thanks!
>
>
> --
>
> *Sukwon Kim, *
>

Re: [Proposal] Stabilizing Apache MXNet CI build system

[Hen]

How about we ask for a new mxnet repo to store all the config in?

On Fri, Oct 27, 2017 at 05:30 Pedro Larroy 
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.
>

ci mailing list?

[Hen]

Would it be useful to get an mxnet-ci mailing list setup so that it's easy
to filter build failures and general conversation into different buckets?

Hen

DMLC [Was: Request for suggestions- Supporting onnx in mxnet]

[Hen]

It wasn't about the two of you specifically, it was that it seemed to me
that we have two communities (DMLC and MXNet; communities not committers)
having a difference of opinion. This is not a healthy thing.

Apologies on the "Something is rotten"; it's an allusion to a quote from
Shakespeare's Hamlet play. Sometimes I don't do enough editing of my
British-English to International-English. It's similar to the phrasing
"something is not right here". It does have an undertone of "there are
unspoken politics here", or in this case where my implication was unclear
community overlap.

Tianqui - where are the DMLC archives? From the outside it's very hard to
see DMLC as an entity, or to see what the DMLC approach to development is.
My (perhaps arrogant assumption) is that DMLC's culture was still forming
when MXNet moved to Apache.

One of the issues raised in the last release was the large amount of DMLC
code that Apache MXNet is wrapping/including as source code. This is
unusual for an Apache project and one of the ways that unusual can impact
is that the Apache project is handing a large amount of its design to a
third party.

Hen


On Thu, Oct 19, 2017 at 12:43 PM, Mu Li  wrote:

> Hi Henri,
>
> I don't understand why you labeled Tianqi and me as from "non-compatible
> DMLC community". We are the top-2 contributors for MXNet. Actually, among
> the participants in this thread, only both of us are listed as the
> committers <https://incubator.apache.org/projects/mxnet.html>.
>
> We are also talking under the "mxnet contributor" hat. We proposed a better
> technical solution for the onnx-mxnet converter. Despite the TVM benefits
> Tianqi introduced, the NNVM/TOP is a cleaned version of MXNet/Gluon
> interface, which aligns with the direction that the MXNet frontend evolves.
> Or probably it makes people feel better we suggest to do ONNX <->
> MXNet/Gluon <-> MXNet/Operator, instead of ONNX <-> MXNet/Operator.
>
> The comment "Something is rotten." doesn't make any sense to me.
>
> Best
> Mu
>
>
> 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 effective

Re: Request for suggestions- Supporting onnx in mxnet

[Hen]

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 
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 this process. Built code on the existing effort would actually
> make the problem easier.
>
> On Thu, Oct 19, 2017 at 11:55 AM, Tianqi Chen 
> wrote:
>
> > As for where the code should sit, we have seen onnx's support for caffe2
> > sitting on a separate repo.  My suggestion would be put code under
> nnvm/top
> > and migrate into mxnet eventually when the top components get into MXNet,
> > hopefully by end of next month.
> >
> > I have elaborated my point in the last email thread. This (going through
> > nnvm/top) is an important design decision both technically (compilation,
> > more hardware) and strategically (articulate our core set of operators
> and
> > influence the model exchange format).
> >
> > I am glad to see the discussion happening and surely there is doubt, as
> > with every big step of changes.  But with the rapidly changing pace of
> deep
> > learning systems, this is the direction that we thought is most
> promising.
> > We can call for a vote if necessary among the committers for the design
> > decision if there is still debate on this issue. Or we can keep the
> > discussion open and start some effort around nnvm/top to see how it goes
> >
> > Tianqi
> >
> > On Thu, Oct 19, 2017 at 11:15 AM, Lupesko, Hagay 
> > wrote:
> >
> >> Mu,
> >>
> >> You’re mentioning plans for a new model format and compiler, but I don’t
> >> recall seeing it shared/discussed on the dev list. Can you share these,
> so
> >> it is more accessible to folks to understand the plan and vision?
> >>
> >> Personally, I think it will be a shame to add ONNX support to MXNet, and
> >> have it implemented outside of MXNet. At the end of the day, it makes
> >> things difficult for MXNet users.
> >>
> >> Hagay
> >>
> >> On 10/19/17, 10:01, "Mu Li"  >> muli@gmail.com> wrote:
> >>
> >> I'm speaking under my "MXNet contributor" hat.
> >>
> >> It will be sad that our new model format

Re: proposal to shut down apache-mxnet.slack.com

[Hen]

What sensitive information? MXNet sensitive information should be on
private@ and not Slack; and other entities sensitive information shouldn’t
be on an Apache Slack.

On Tue, Oct 17, 2017 at 09:32 Mu Li  wrote:

> I don't think it will be a problem. But we probably need to set up several
> channels at the-asf, some of them will be private due to containing
> sensitive information.
>
> On Tue, Oct 17, 2017 at 9:05 AM, Steffen Rochel 
> wrote:
>
> > Mu - do you see a problem moving the private channels to the-asf?
> > Steffen
> >
> >
> > On Mon, Oct 16, 2017 at 10:34 PM Mu Li  wrote:
> >
> > > there are several private channels on apache-mxnet.slack.com, how we
> are
> > > going to deal with it?
> > >
> > > On Mon, Oct 16, 2017 at 10:19 PM, Hen  wrote:
> > >
> > > > +1.
> > > >
> > > > On Mon, Oct 16, 2017 at 10:01 PM, Chris Olivier <
> cjolivie...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > +1. Nuke it.
> > > > >
> > > > >
> > > > > On Mon, Oct 16, 2017 at 8:23 AM Steffen Rochel <
> > > steffenroc...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > As we have now migrated the majority of people from
> > > > > apache-mxnet.slack.com
> > > > > > to the-asf.slack.com I would like to suggest to shut down
> > > > > > apache-mxnet.slack.com.
> > > > > > This will minimize the number of channels anybody should watch
> and
> > > > > > discussions going in parallel.
> > > > > >
> > > > > > Anybody who was not able to join the-asf.slack.com?
> > > > > > Any objections?
> > > > > >
> > > > > > Steffen
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: proposal to shut down apache-mxnet.slack.com

[Hen]

+1.

On Mon, Oct 16, 2017 at 10:01 PM, Chris Olivier 
wrote:

> +1. Nuke it.
>
>
> On Mon, Oct 16, 2017 at 8:23 AM Steffen Rochel 
> wrote:
>
> > As we have now migrated the majority of people from
> apache-mxnet.slack.com
> > to the-asf.slack.com I would like to suggest to shut down
> > apache-mxnet.slack.com.
> > This will minimize the number of channels anybody should watch and
> > discussions going in parallel.
> >
> > Anybody who was not able to join the-asf.slack.com?
> > Any objections?
> >
> > Steffen
> >
>