[RESULT][VOTE] Release MXNet version 1.3.0

[Roshani Nagmote]

Hi All,

Thank you for spending the time to test MXNet 1.3.0.RC0 release.
Sandeep mentioned the issue
 when the user
tries to load model params trained/saved as FP16 in gluon. The fix
 will go into the
master branch and users who want to use it can build MXNet from master. We
will not block release for this.

So, this vote passes with *four* +1, *two* 0  and *two* -1 votes.

*+1 votes*

*Committers:*

- Joshua Zhang

- Carin


*Community:*

- Pigeon Lucky

- Steffen


*0 votes:*

*Community:*

- Thomas

- Aaron


*-1 votes:*

*Committers:*

- Sandeep


*Community:*

- Hagay



*Vote Thread:*

https://lists.apache.org/thread.html/8ad6f14811be465cdf663d6962980fd95e12193626292631a21ec6f1@%3Cdev.mxnet.apache.org%3E


I will continue with the release process on general@ and the release
announcement will follow in the next few days.


Thanks,
Roshani

Re: Source images for logos

[Bossi, Marcelo]

I just received this PDF file yesterday (see attachment) that we use for 
printing stickers. I don't know if this is high res quality for banners and 
t-shirts.

Marcelo

On 9/5/18, 4:47 PM, "Simon Corston-Oliver"  wrote:

Do we have source files (SVG or similar format) for the various MXNet logos
e.g. the Gluon logo:

https://github.com/dmlc/web-data/blob/master/mxnet/image/image-gluon-logo.png?raw=true

We'd like to produce different sizes e.g. for banners or t-shirts for
conferences.

Source images for logos

[Simon Corston-Oliver]

Do we have source files (SVG or similar format) for the various MXNet logos
e.g. the Gluon logo:
https://github.com/dmlc/web-data/blob/master/mxnet/image/image-gluon-logo.png?raw=true

We'd like to produce different sizes e.g. for banners or t-shirts for
conferences.

Re: contributing

[Ivan Serdyuk]

Welcome to the club.

On Wed, Sep 5, 2018 at 10:46 PM matd...@gmail.com  wrote:

> Hi folks,
> I'm interested in contributing on the Scala part.
> I'm relatively new to MXNet, but I think I can take some "low hanging
> fruits" as they say.
>
> To start, I would appreciate some hints to iterate quick on
> dev/compile/test. Using make it's a bit ... cumbersome.
>
> ++
> Mathieu
>

Updated invitation with note: Apache MXNet Hangout 5pm PDT @ Wed Sep 5, 2018 5pm - 6pm (PDT) (dev@mxnet.incubator.apache.org)

[steffenrochel]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20180906T00Z
DTEND:20180906T01Z
DTSTAMP:20180905T190420Z
ORGANIZER;CN=Steffen Rochel:mailto:steffenroc...@gmail.com
UID:2co9qpt209vhp3n9rppsciq...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Steffen Rochel;X-NUM-GUESTS=0:mailto:steffenroc...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:dev@mxnet.incubato
 r.apache.org
CREATED:20180802T223928Z
DESCRIPTION:See details https://cwiki.apache.org/confluence/di
 splay/MXNET/Hangout+September+5th+2018+8am+and+5pm+PDT" target="_blank">her
 eYou have been invited to an online meeting\, powered by Amazon
  Chime.1. Click to join the meeting:https://chime.aws/54527
 34911Meeting ID: 5452 73 49112. You can use your computer’s
  microphone and speakers\, however\, a headset is recommended. Or\, call in
  using your phone:United States Toll-Free: +1 855-552-4463Meeti
 ng PIN: 5452 73 4911One-click Mobile Dial-in (United States (1)): +
 1 206-462-5569\,\,5452734911#United States (1): +1 206-462-5569
 International: https://chime.aws/dialinnumbers/3. To connect from a
 n in-room video system\, use one of the following Amazon Chime bridges:
 SIP video system: meet.chime.inorH.323 system: 52.23.133.56
 Meeting PIN: 5452734911#\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this secti
 on of the description.\n\nView your event at https://www.google.com/calenda
 r/event?action=VIEW=MmNvOXFwdDIwOXZocDNuOXJwcHNjaXFic3MgZGV2QG14bmV0Lml
 uY3ViYXRvci5hcGFjaGUub3Jn=MjMjc3RlZmZlbnJvY2hlbEBnbWFpbC5jb21jNjA1NDFmO
 Dc3NjFjZGJhODljZTlkNTg3OTkyYjM5ZDU3N2E2YWE3=America%2FLos_Angeles=en
 =0.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180905T190420Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Apache MXNet Hangout 5pm PDT
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Updated invitation with note: Apache MXNet Hangout 8am PDT @ Wed Sep 5, 2018 8am - 9am (PDT) (dev@mxnet.incubator.apache.org)

[steffenrochel]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20180905T15Z
DTEND:20180905T16Z
DTSTAMP:20180905T150529Z
ORGANIZER;CN=Steffen Rochel:mailto:steffenroc...@gmail.com
UID:4sb67q8679arcajd3n8recb...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Steffen Rochel;X-NUM-GUESTS=0:mailto:steffenroc...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=dev@mxnet.incubator.apache.org;X-NUM-GUESTS=0:mailto:dev@mxnet.incubato
 r.apache.org
CREATED:20180802T223807Z
DESCRIPTION:Apache MXNet Hangout Call information:1. Click to j
 oin the meeting: https://chime.aws/4432972704; target="_blank">htt
 ps://chime.aws/6357 02 3396\;Meeting ID: 6357 02 33962. Yo
 u can use your computer’s microphone and speakers\, however\, a headset is 
 recommended. Or\, call in using your phone:United States Toll-Free:
  +1 855-552-4463Meeting PIN: 6357 02 3396One-click Mobile Dial-
 in (United States (1)): +1 206-462-5569\,\,6357 02 3396#United Stat
 es (1): +1 206-462-5569International: https://chime.aws/dialin
 numbers/" target="_blank">https://chime.aws/dialinnumbers/\n\n-::~:~::~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~
 ::-\nPlease do not edit this section of the description.\n\nView your event
  at https://www.google.com/calendar/event?action=VIEW=NHNiNjdxODY3OWFyY
 2FqZDNuOHJlY2JicnEgZGV2QG14bmV0LmluY3ViYXRvci5hcGFjaGUub3Jn=MjMjc3RlZmZ
 lbnJvY2hlbEBnbWFpbC5jb20wNjRmMTNhZmExNjQ3YmE0NDQxZWUyNTIyYjNiZWRhMTU5NmMxM2
 E5=America%2FLos_Angeles=en=0.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180905T150529Z
LOCATION:Palo Alto\, CA\, USA
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Apache MXNet Hangout 8am PDT
TRANSP:OPAQUE
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
BEGIN:VALARM
ACTION:NONE
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
X-WR-ALARMUID:57447D7C-D410-453B-8119-645E7666AFDA
UID:57447D7C-D410-453B-8119-645E7666AFDA
ACKNOWLEDGED:20180905T144948Z
X-APPLE-DEFAULT-ALARM:TRUE
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

contributing

[matdpro]

Hi folks,
I'm interested in contributing on the Scala part.
I'm relatively new to MXNet, but I think I can take some "low hanging fruits" 
as they say.

To start, I would appreciate some hints to iterate quick on dev/compile/test. 
Using make it's a bit ... cumbersome.

++
Mathieu

Updated meeting ID for virtual Apache MXNet hangout on Sep 5th 5pm PDT

[Steffen Rochel]

For the hangout at 5pm PDT today please use:
You have been invited to an online meeting, powered by Amazon Chime.

1. Click to join the meeting:

https://chime.aws/5452734911

Meeting ID: 5452 73 4911

2. You can use your computer’s microphone and speakers, however, a headset
is recommended. Or, call in using your phone:

United States Toll-Free: +1 855-552-4463
Meeting PIN: 5452 73 4911

One-click Mobile Dial-in (United States (1)): +1 206-462-5569,,5452734911#

United States (1): +1 206-462-5569
International: https://chime.aws/dialinnumbers/



On Wed, Sep 5, 2018 at 8:03 AM Steffen Rochel 
wrote:

> My apology, something is not working with the meeting ID, Please use 6357
> 02 3396#
> Steffen
>
> On Thu, Aug 30, 2018 at 7:52 AM Steffen Rochel 
> wrote:
>
>> Our next virtual Apache MXNet hangout will be on Sep 5th at 8am and 5pm
>> PDT. Hope you can join.
>>
>> *Meeting information:*
>>
>> 1. Click to join the meeting: https://chime.aws/4432972704   Meeting ID:
>> 4432 97 2704
>>
>> 2. You can use your computer’s microphone and speakers, however, a
>> headset is recommended. Or, call in using your phone:
>>
>> United States Toll-Free: +1 855-552-4463 <(855)%20552-4463>
>> Meeting PIN: 4432 97 2704
>>
>> One-click Mobile Dial-in (United States (1)): +1 206-462-5569
>> <(206)%20462-5569>,,4432972704 <(443)%20297-2704>#
>>
>> United States (1): +1 206-462-5569 <(206)%20462-5569>
>> International: https://chime.aws/dialinnumbers/
>>
>> Regards,
>>
>> Steffen
>>
>>
>> Proposed Agenda:
>>
>>1. Introduction of participants
>>2. Release 1.3 updates
>>3. Feedback on PR Best Practices
>>
>>4. Brainstorm for next release(s)
>>
>>

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[Tianqi Chen]

Alrite, then I think it is fine as long as we can kept up with build speed
without timeout.


Tianqi

On Wed, Sep 5, 2018 at 9:14 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Travis actually has explicit support for ccache, it's a platform feature.
> I've run it and it seems to work quite well.  See for example this build:
> https://travis-ci.org/KellenSunderland/incubator-mxnet/builds/424768656
>
> On Wed, Sep 5, 2018 at 7:10 PM Tianqi Chen 
> wrote:
>
> > Travis it self is stateless, which means ccache is not likely going to
> > work. As far as I understand, if jenkins master is in the public domain,
> > you do not need to setup a vpn to the subset of the master.
> >
> > As for versions of MacOS, we are likely going to be fine with one
> version,
> > as usually the problems exhibits on mac are similar
> >
> > Tianqi
> > On Wed, Sep 5, 2018 at 9:04 AM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > @Tianqi: Yeah there's going to be a lot of trade-offs to using
> Travis.  I
> > > hope we can get it running fast enough with ccache that it won't
> timeout
> > > when running tests, but even that is questionable.  In my private
> testing
> > > it was running in about 35 minutes and the global timeout for Travis
> jobs
> > > is 45 minutes.  I'd say let's run it for a few builds and see how it
> > goes.
> > > It won't be enabled in a mode that blocks PRs any time soon.
> > >
> > > I don't think physical hardware is a great solution.  We would have to
> > > purchase the hardware, then maintain security updates, install
> different
> > > versions of XCode / MacOS, setup a vpn to our jenkins master, etc.  I
> > would
> > > also worry that if the machine goes down for whatever reason it would
> > block
> > > PRs, and someone would have to be physically present to turn it back
> on.
> > > Even assuming we set all the hardware up it's still not scalable so
> we'd
> > > have to over-provision.
> > >
> > > I'm hoping the Travis solution works for the time being. If it doesn't
> > > we'll have to take a look at a few other options, but I've spent a fair
> > > amount of time thinking about this and I don't think there are any good
> > > options that don't have trade-offs.
> > >
> > > @Lin: Great!  Thanks for the offer.  There'll be a few features we want
> > to
> > > re-enable once the Job gets hooked up again.  I'll ping you when it's
> > ready
> > > and see if there's anything you think would be interesting to help
> with.
> > >
> > > -Kellen
> > >
> > > On Wed, Sep 5, 2018 at 6:58 PM Lin Yuan  wrote:
> > >
> > > > Hi Kellen,
> > > >
> > > > I would love to contribute. Please let me know if you have any
> > particular
> > > > work item that I can help.
> > > >
> > > > Best,
> > > >
> > > > Lin
> > > >
> > > > On Wed, Sep 5, 2018 at 9:51 AM Tianqi Chen  >
> > > > wrote:
> > > >
> > > > > is it possible for us to get a MacBook and hook it to the current
> > > Jenkins
> > > > > CI? Travis OSX usually build from scratch and that was pretty slow
> > > > >
> > > > > Tianqi
> > > > >
> > > > >
> > > > > On Wed, Sep 5, 2018 at 8:49 AM kellen sunderland <
> > > > > kellen.sunderl...@gmail.com> wrote:
> > > > >
> > > > > > Great you feel that way Lin, please feel free to contribute if
> you
> > > have
> > > > > any
> > > > > > features you'd like tested.  We are using the travis image
> xcode9.4
> > > > which
> > > > > > is based on MacOS 10.13.
> > > > > >
> > > > > > On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan 
> > wrote:
> > > > > >
> > > > > > > Hi Kellen,
> > > > > > >
> > > > > > > Many thanks for your and Marco's effort! I think this is a very
> > > > crucial
> > > > > > > piece to improve MXNet stability.
> > > > > > >
> > > > > > > To add some data points:
> > > > > > > 1) Customers using CoreML to MXNet converter were blocked for a
> > > while
> > > > > > > because the converter was broken and no unit test was in place
> to
> > > > > detect
> > > > > > > that.
> > > > > > > 2) Developers on Mac cannot verify their local commits because
> > some
> > > > > unit
> > > > > > > tests on master were broken. This wasted much time and resource
> > on
> > > > > > jenkins
> > > > > > > server to detect the failure.
> > > > > > > 3) Please consider running the CI on Mac OS 10.13 since this is
> > the
> > > > > > minimum
> > > > > > > Mac OS version that supports CoreML (to support CoreML to MXNet
> > > > > > converter)
> > > > > > >
> > > > > > > Best Regards,
> > > > > > >
> > > > > > > Lin
> > > > > > >
> > > > > > > On Wed, Sep 5, 2018, 3:02 AM kellen sunderland <
> > > > > > > kellen.sunderl...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I'm bumping this thread as we've recently had our first
> serious
> > > bug
> > > > > on
> > > > > > > > MacOS that would have been caught by enabling Travis.
> > > > > > > >
> > > > > > > > I'm going to do a little experimental work together with
> Marco
> > > with
> > > > > the
> > > > > > > > goal of enabling a minimal Travis build that 

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[Marco de Abreu]

Regarding connecting slaves to a public Jenkins instance. Technically you
are right, Tianqi, but our security design requires slaves to be within the
VPC (which is also possible for on-premise computers) and we don't allow
any connections to the public endpoint. Thus, it's not that trivial. We
want to avoid physical hardware as much as possible due to the reasons
stated by Kellen.

-Marco

On Wed, Sep 5, 2018 at 7:14 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Travis actually has explicit support for ccache, it's a platform feature.
> I've run it and it seems to work quite well.  See for example this build:
> https://travis-ci.org/KellenSunderland/incubator-mxnet/builds/424768656
>
> On Wed, Sep 5, 2018 at 7:10 PM Tianqi Chen 
> wrote:
>
> > Travis it self is stateless, which means ccache is not likely going to
> > work. As far as I understand, if jenkins master is in the public domain,
> > you do not need to setup a vpn to the subset of the master.
> >
> > As for versions of MacOS, we are likely going to be fine with one
> version,
> > as usually the problems exhibits on mac are similar
> >
> > Tianqi
> > On Wed, Sep 5, 2018 at 9:04 AM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > @Tianqi: Yeah there's going to be a lot of trade-offs to using
> Travis.  I
> > > hope we can get it running fast enough with ccache that it won't
> timeout
> > > when running tests, but even that is questionable.  In my private
> testing
> > > it was running in about 35 minutes and the global timeout for Travis
> jobs
> > > is 45 minutes.  I'd say let's run it for a few builds and see how it
> > goes.
> > > It won't be enabled in a mode that blocks PRs any time soon.
> > >
> > > I don't think physical hardware is a great solution.  We would have to
> > > purchase the hardware, then maintain security updates, install
> different
> > > versions of XCode / MacOS, setup a vpn to our jenkins master, etc.  I
> > would
> > > also worry that if the machine goes down for whatever reason it would
> > block
> > > PRs, and someone would have to be physically present to turn it back
> on.
> > > Even assuming we set all the hardware up it's still not scalable so
> we'd
> > > have to over-provision.
> > >
> > > I'm hoping the Travis solution works for the time being. If it doesn't
> > > we'll have to take a look at a few other options, but I've spent a fair
> > > amount of time thinking about this and I don't think there are any good
> > > options that don't have trade-offs.
> > >
> > > @Lin: Great!  Thanks for the offer.  There'll be a few features we want
> > to
> > > re-enable once the Job gets hooked up again.  I'll ping you when it's
> > ready
> > > and see if there's anything you think would be interesting to help
> with.
> > >
> > > -Kellen
> > >
> > > On Wed, Sep 5, 2018 at 6:58 PM Lin Yuan  wrote:
> > >
> > > > Hi Kellen,
> > > >
> > > > I would love to contribute. Please let me know if you have any
> > particular
> > > > work item that I can help.
> > > >
> > > > Best,
> > > >
> > > > Lin
> > > >
> > > > On Wed, Sep 5, 2018 at 9:51 AM Tianqi Chen  >
> > > > wrote:
> > > >
> > > > > is it possible for us to get a MacBook and hook it to the current
> > > Jenkins
> > > > > CI? Travis OSX usually build from scratch and that was pretty slow
> > > > >
> > > > > Tianqi
> > > > >
> > > > >
> > > > > On Wed, Sep 5, 2018 at 8:49 AM kellen sunderland <
> > > > > kellen.sunderl...@gmail.com> wrote:
> > > > >
> > > > > > Great you feel that way Lin, please feel free to contribute if
> you
> > > have
> > > > > any
> > > > > > features you'd like tested.  We are using the travis image
> xcode9.4
> > > > which
> > > > > > is based on MacOS 10.13.
> > > > > >
> > > > > > On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan 
> > wrote:
> > > > > >
> > > > > > > Hi Kellen,
> > > > > > >
> > > > > > > Many thanks for your and Marco's effort! I think this is a very
> > > > crucial
> > > > > > > piece to improve MXNet stability.
> > > > > > >
> > > > > > > To add some data points:
> > > > > > > 1) Customers using CoreML to MXNet converter were blocked for a
> > > while
> > > > > > > because the converter was broken and no unit test was in place
> to
> > > > > detect
> > > > > > > that.
> > > > > > > 2) Developers on Mac cannot verify their local commits because
> > some
> > > > > unit
> > > > > > > tests on master were broken. This wasted much time and resource
> > on
> > > > > > jenkins
> > > > > > > server to detect the failure.
> > > > > > > 3) Please consider running the CI on Mac OS 10.13 since this is
> > the
> > > > > > minimum
> > > > > > > Mac OS version that supports CoreML (to support CoreML to MXNet
> > > > > > converter)
> > > > > > >
> > > > > > > Best Regards,
> > > > > > >
> > > > > > > Lin
> > > > > > >
> > > > > > > On Wed, Sep 5, 2018, 3:02 AM kellen sunderland <
> > > > > > > kellen.sunderl...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I'm bumping this thread as we've recently had our 

Re: [VOTE] Release MXNet version 1.3.0.RC0

[Aaron Markham]

0 (non-binding) If we have a problem that blocks users, and a solution in
hand... then we should fix it, but not at the expense of starting the
release cycle again just for one fix. Users can cherry pick or build from
master if they want the fix right away, right? I'd change my mind to -1 if
this wasn't the case, with good reason, and if the user impact was critical
to adoption or risks abandonment.


On Wed, Sep 5, 2018 at 9:57 AM Roshani Nagmote 
wrote:

> I believe everyone here is working hard to make MXNet a better framework
> for users. It's completely okay to have different opinions, we can decide
> together if this issue is a blocker or not after voting time is over.
>
> As I mentioned before, voting will end at 7 pm today. So there is still
> time to test the release. If there are any other issues anyone finds, I
> will be happy to start the process again and work on RC1. For now, I want
> to encourage everyone to utilize this time and vote. :)
>
> Thanks,
> Roshani
>
> On Tue, Sep 4, 2018 at 10:35 PM sandeep krishnamurthy <
> sandeep.krishn...@gmail.com> wrote:
>
> >1. As a Apache MXNet community member, I raised the concern of broken
> >functionality for the user. I explained and provided the data points
> on
> > the
> >issue, workaround and why I think it is important. If after all this,
> > you
> >think my vote is biased on my employer just because a user I quoted is
> > from
> >Amazon, this is more concerning to me on my voting abilities.
> >2. My -1 no where undermines the huge amount of effort that goes
> behind
> >the scene for a release to happen. Great respect and recognition for
> >everyone involved in all the releases of MXNet in the past and this. I
> >voted on my judgement of what may be good for the users of MXNet.
> >3. As pointed by Naveen & Chris, -1 are NOT veto. Feel free to decide
> >and progress on the release as we already have >3 +1 in this thread.
> >
> >
> > Best,
> >
> > Sandeep
> >
> > On Tue, Sep 4, 2018 at 8:29 PM Chris Olivier 
> > wrote:
> >
> > > btw, there are no vetoes on package releases:
> > >
> > > VOTES ON PACKAGE RELEASES
> > > 
> > >
> > > Votes on whether a package is ready to be released use majority
> approval
> > >  --
> > i.e.
> > > at least three PMC members must vote affirmatively for release, and
> there
> > > must be more positive than negative votes.Releases may not be vetoed.
> > > Generally
> > > the community will cancel the release vote if anyone identifies serious
> > > problems, but in most cases the ultimate decision, lies with the
> > individual
> > > serving as release manager. The specifics of the process may vary from
> > > project to project, but the 'minimum quorum of three +1 votes' rule is
> > > universal.
> > >
> > > On Tue, Sep 4, 2018 at 7:12 PM Sheng Zha  wrote:
> > >
> > > > Thanks for sharing your opinions, Thomas. Your recognition and
> respect
> > of
> > > > people's efforts on preparing the release candidate are certainly
> > > > appreciated.
> > > >
> > > > Now that the vote is set to fail thanks to the veto, there will be
> > plenty
> > > > of opportunities to include those bug fixes, including the one Zhi
> > > > mentioned [1], which was already merged in the master and yet chose
> not
> > > to
> > > > block this release with [2]. I will be happy to work with Roshani to
> > > > prepare another release candidate once ready.
> > > >
> > > > -sz
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/f02e952bec22c82cb00a6741390a78f55373311c97464997bb455a6c@%3Cdev.mxnet.apache.org%3E
> > > > [2]
> > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/85d3fcabb3437ba7f1af455cf69aa13eb3afd1ea1d1f6f891e9c339c@%3Cdev.mxnet.apache.org%3E
> > > >
> > > > On Tue, Sep 4, 2018 at 6:02 PM Thomas DELTEIL <
> > thomas.delte...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > -0
> > > > > (non-binding)
> > > > >
> > > > > If I may add some nuancing plus a personal data point as one of the
> > > users
> > > > > commenting in the bug report in question:
> > > > >
> > > > > - Performance vs. Basic functionality => I don't think high
> > performance
> > > > > use-cases and basic functionality are two obviously opposed
> concepts
> > > and
> > > > > see no contradiction in Hagay's and Sandeep's statements.
> > > > > Float16 support is feature of MXNet that provides more than twice
> the
> > > > > performance of Float32 on supported platforms, hence the high
> > > performance
> > > > > use-case. The bug is that the basic functionality of reloading a
> > saved
> > > > > float16 models is currently broken.
> > > > >
> > > > > - This bug vs Other bugs => Contrary the vast majority of the 140
> > open
> > > > bugs
> > > > > that are mentioned above, I would put to Sandeep's credit that this
> > one
> > > > bug
> > > > > has a PR open that 

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[kellen sunderland]

Travis actually has explicit support for ccache, it's a platform feature.
I've run it and it seems to work quite well.  See for example this build:
https://travis-ci.org/KellenSunderland/incubator-mxnet/builds/424768656

On Wed, Sep 5, 2018 at 7:10 PM Tianqi Chen  wrote:

> Travis it self is stateless, which means ccache is not likely going to
> work. As far as I understand, if jenkins master is in the public domain,
> you do not need to setup a vpn to the subset of the master.
>
> As for versions of MacOS, we are likely going to be fine with one version,
> as usually the problems exhibits on mac are similar
>
> Tianqi
> On Wed, Sep 5, 2018 at 9:04 AM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > @Tianqi: Yeah there's going to be a lot of trade-offs to using Travis.  I
> > hope we can get it running fast enough with ccache that it won't timeout
> > when running tests, but even that is questionable.  In my private testing
> > it was running in about 35 minutes and the global timeout for Travis jobs
> > is 45 minutes.  I'd say let's run it for a few builds and see how it
> goes.
> > It won't be enabled in a mode that blocks PRs any time soon.
> >
> > I don't think physical hardware is a great solution.  We would have to
> > purchase the hardware, then maintain security updates, install different
> > versions of XCode / MacOS, setup a vpn to our jenkins master, etc.  I
> would
> > also worry that if the machine goes down for whatever reason it would
> block
> > PRs, and someone would have to be physically present to turn it back on.
> > Even assuming we set all the hardware up it's still not scalable so we'd
> > have to over-provision.
> >
> > I'm hoping the Travis solution works for the time being. If it doesn't
> > we'll have to take a look at a few other options, but I've spent a fair
> > amount of time thinking about this and I don't think there are any good
> > options that don't have trade-offs.
> >
> > @Lin: Great!  Thanks for the offer.  There'll be a few features we want
> to
> > re-enable once the Job gets hooked up again.  I'll ping you when it's
> ready
> > and see if there's anything you think would be interesting to help with.
> >
> > -Kellen
> >
> > On Wed, Sep 5, 2018 at 6:58 PM Lin Yuan  wrote:
> >
> > > Hi Kellen,
> > >
> > > I would love to contribute. Please let me know if you have any
> particular
> > > work item that I can help.
> > >
> > > Best,
> > >
> > > Lin
> > >
> > > On Wed, Sep 5, 2018 at 9:51 AM Tianqi Chen 
> > > wrote:
> > >
> > > > is it possible for us to get a MacBook and hook it to the current
> > Jenkins
> > > > CI? Travis OSX usually build from scratch and that was pretty slow
> > > >
> > > > Tianqi
> > > >
> > > >
> > > > On Wed, Sep 5, 2018 at 8:49 AM kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > > > Great you feel that way Lin, please feel free to contribute if you
> > have
> > > > any
> > > > > features you'd like tested.  We are using the travis image xcode9.4
> > > which
> > > > > is based on MacOS 10.13.
> > > > >
> > > > > On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan 
> wrote:
> > > > >
> > > > > > Hi Kellen,
> > > > > >
> > > > > > Many thanks for your and Marco's effort! I think this is a very
> > > crucial
> > > > > > piece to improve MXNet stability.
> > > > > >
> > > > > > To add some data points:
> > > > > > 1) Customers using CoreML to MXNet converter were blocked for a
> > while
> > > > > > because the converter was broken and no unit test was in place to
> > > > detect
> > > > > > that.
> > > > > > 2) Developers on Mac cannot verify their local commits because
> some
> > > > unit
> > > > > > tests on master were broken. This wasted much time and resource
> on
> > > > > jenkins
> > > > > > server to detect the failure.
> > > > > > 3) Please consider running the CI on Mac OS 10.13 since this is
> the
> > > > > minimum
> > > > > > Mac OS version that supports CoreML (to support CoreML to MXNet
> > > > > converter)
> > > > > >
> > > > > > Best Regards,
> > > > > >
> > > > > > Lin
> > > > > >
> > > > > > On Wed, Sep 5, 2018, 3:02 AM kellen sunderland <
> > > > > > kellen.sunderl...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I'm bumping this thread as we've recently had our first serious
> > bug
> > > > on
> > > > > > > MacOS that would have been caught by enabling Travis.
> > > > > > >
> > > > > > > I'm going to do a little experimental work together with Marco
> > with
> > > > the
> > > > > > > goal of enabling a minimal Travis build that will run python
> > tests.
> > > > So
> > > > > > far
> > > > > > > I've verified that Travis will in fact find a bug that
> currently
> > > > exists
> > > > > > in
> > > > > > > master and has been reproduced by MacOS clients.  This
> indicates
> > to
> > > > me
> > > > > > that
> > > > > > > adding Travis will add value to our CI.
> > > > > > >
> > > > > > > My best guess is that it might take us some iteration before we
> > > find
> > > > a
> > > > > > > scalable 

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[Tianqi Chen]

Travis it self is stateless, which means ccache is not likely going to
work. As far as I understand, if jenkins master is in the public domain,
you do not need to setup a vpn to the subset of the master.

As for versions of MacOS, we are likely going to be fine with one version,
as usually the problems exhibits on mac are similar

Tianqi
On Wed, Sep 5, 2018 at 9:04 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> @Tianqi: Yeah there's going to be a lot of trade-offs to using Travis.  I
> hope we can get it running fast enough with ccache that it won't timeout
> when running tests, but even that is questionable.  In my private testing
> it was running in about 35 minutes and the global timeout for Travis jobs
> is 45 minutes.  I'd say let's run it for a few builds and see how it goes.
> It won't be enabled in a mode that blocks PRs any time soon.
>
> I don't think physical hardware is a great solution.  We would have to
> purchase the hardware, then maintain security updates, install different
> versions of XCode / MacOS, setup a vpn to our jenkins master, etc.  I would
> also worry that if the machine goes down for whatever reason it would block
> PRs, and someone would have to be physically present to turn it back on.
> Even assuming we set all the hardware up it's still not scalable so we'd
> have to over-provision.
>
> I'm hoping the Travis solution works for the time being. If it doesn't
> we'll have to take a look at a few other options, but I've spent a fair
> amount of time thinking about this and I don't think there are any good
> options that don't have trade-offs.
>
> @Lin: Great!  Thanks for the offer.  There'll be a few features we want to
> re-enable once the Job gets hooked up again.  I'll ping you when it's ready
> and see if there's anything you think would be interesting to help with.
>
> -Kellen
>
> On Wed, Sep 5, 2018 at 6:58 PM Lin Yuan  wrote:
>
> > Hi Kellen,
> >
> > I would love to contribute. Please let me know if you have any particular
> > work item that I can help.
> >
> > Best,
> >
> > Lin
> >
> > On Wed, Sep 5, 2018 at 9:51 AM Tianqi Chen 
> > wrote:
> >
> > > is it possible for us to get a MacBook and hook it to the current
> Jenkins
> > > CI? Travis OSX usually build from scratch and that was pretty slow
> > >
> > > Tianqi
> > >
> > >
> > > On Wed, Sep 5, 2018 at 8:49 AM kellen sunderland <
> > > kellen.sunderl...@gmail.com> wrote:
> > >
> > > > Great you feel that way Lin, please feel free to contribute if you
> have
> > > any
> > > > features you'd like tested.  We are using the travis image xcode9.4
> > which
> > > > is based on MacOS 10.13.
> > > >
> > > > On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan  wrote:
> > > >
> > > > > Hi Kellen,
> > > > >
> > > > > Many thanks for your and Marco's effort! I think this is a very
> > crucial
> > > > > piece to improve MXNet stability.
> > > > >
> > > > > To add some data points:
> > > > > 1) Customers using CoreML to MXNet converter were blocked for a
> while
> > > > > because the converter was broken and no unit test was in place to
> > > detect
> > > > > that.
> > > > > 2) Developers on Mac cannot verify their local commits because some
> > > unit
> > > > > tests on master were broken. This wasted much time and resource on
> > > > jenkins
> > > > > server to detect the failure.
> > > > > 3) Please consider running the CI on Mac OS 10.13 since this is the
> > > > minimum
> > > > > Mac OS version that supports CoreML (to support CoreML to MXNet
> > > > converter)
> > > > >
> > > > > Best Regards,
> > > > >
> > > > > Lin
> > > > >
> > > > > On Wed, Sep 5, 2018, 3:02 AM kellen sunderland <
> > > > > kellen.sunderl...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I'm bumping this thread as we've recently had our first serious
> bug
> > > on
> > > > > > MacOS that would have been caught by enabling Travis.
> > > > > >
> > > > > > I'm going to do a little experimental work together with Marco
> with
> > > the
> > > > > > goal of enabling a minimal Travis build that will run python
> tests.
> > > So
> > > > > far
> > > > > > I've verified that Travis will in fact find a bug that currently
> > > exists
> > > > > in
> > > > > > master and has been reproduced by MacOS clients.  This indicates
> to
> > > me
> > > > > that
> > > > > > adding Travis will add value to our CI.
> > > > > >
> > > > > > My best guess is that it might take us some iteration before we
> > find
> > > a
> > > > > > scalable way to integrate Travis.  Given this we're going to
> enable
> > > > > Travis
> > > > > > in non-blocking mode (i.e. failures are safe to ignore for the
> time
> > > > > being).
> > > > > >
> > > > > > To help mitigate the risk of timeouts, and to remove legacy code
> > I'm
> > > > > going
> > > > > > to re-create the travis.yml file from scratch.  I think it'll be
> > much
> > > > > less
> > > > > > confusing if we only have working code related to Travis in our
> > > > codebase,
> > > > > > so that contributors won't have to experiment 

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[kellen sunderland]

@Tianqi: Yeah there's going to be a lot of trade-offs to using Travis.  I
hope we can get it running fast enough with ccache that it won't timeout
when running tests, but even that is questionable.  In my private testing
it was running in about 35 minutes and the global timeout for Travis jobs
is 45 minutes.  I'd say let's run it for a few builds and see how it goes.
It won't be enabled in a mode that blocks PRs any time soon.

I don't think physical hardware is a great solution.  We would have to
purchase the hardware, then maintain security updates, install different
versions of XCode / MacOS, setup a vpn to our jenkins master, etc.  I would
also worry that if the machine goes down for whatever reason it would block
PRs, and someone would have to be physically present to turn it back on.
Even assuming we set all the hardware up it's still not scalable so we'd
have to over-provision.

I'm hoping the Travis solution works for the time being. If it doesn't
we'll have to take a look at a few other options, but I've spent a fair
amount of time thinking about this and I don't think there are any good
options that don't have trade-offs.

@Lin: Great!  Thanks for the offer.  There'll be a few features we want to
re-enable once the Job gets hooked up again.  I'll ping you when it's ready
and see if there's anything you think would be interesting to help with.

-Kellen

On Wed, Sep 5, 2018 at 6:58 PM Lin Yuan  wrote:

> Hi Kellen,
>
> I would love to contribute. Please let me know if you have any particular
> work item that I can help.
>
> Best,
>
> Lin
>
> On Wed, Sep 5, 2018 at 9:51 AM Tianqi Chen 
> wrote:
>
> > is it possible for us to get a MacBook and hook it to the current Jenkins
> > CI? Travis OSX usually build from scratch and that was pretty slow
> >
> > Tianqi
> >
> >
> > On Wed, Sep 5, 2018 at 8:49 AM kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > Great you feel that way Lin, please feel free to contribute if you have
> > any
> > > features you'd like tested.  We are using the travis image xcode9.4
> which
> > > is based on MacOS 10.13.
> > >
> > > On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan  wrote:
> > >
> > > > Hi Kellen,
> > > >
> > > > Many thanks for your and Marco's effort! I think this is a very
> crucial
> > > > piece to improve MXNet stability.
> > > >
> > > > To add some data points:
> > > > 1) Customers using CoreML to MXNet converter were blocked for a while
> > > > because the converter was broken and no unit test was in place to
> > detect
> > > > that.
> > > > 2) Developers on Mac cannot verify their local commits because some
> > unit
> > > > tests on master were broken. This wasted much time and resource on
> > > jenkins
> > > > server to detect the failure.
> > > > 3) Please consider running the CI on Mac OS 10.13 since this is the
> > > minimum
> > > > Mac OS version that supports CoreML (to support CoreML to MXNet
> > > converter)
> > > >
> > > > Best Regards,
> > > >
> > > > Lin
> > > >
> > > > On Wed, Sep 5, 2018, 3:02 AM kellen sunderland <
> > > > kellen.sunderl...@gmail.com>
> > > > wrote:
> > > >
> > > > > I'm bumping this thread as we've recently had our first serious bug
> > on
> > > > > MacOS that would have been caught by enabling Travis.
> > > > >
> > > > > I'm going to do a little experimental work together with Marco with
> > the
> > > > > goal of enabling a minimal Travis build that will run python tests.
> > So
> > > > far
> > > > > I've verified that Travis will in fact find a bug that currently
> > exists
> > > > in
> > > > > master and has been reproduced by MacOS clients.  This indicates to
> > me
> > > > that
> > > > > adding Travis will add value to our CI.
> > > > >
> > > > > My best guess is that it might take us some iteration before we
> find
> > a
> > > > > scalable way to integrate Travis.  Given this we're going to enable
> > > > Travis
> > > > > in non-blocking mode (i.e. failures are safe to ignore for the time
> > > > being).
> > > > >
> > > > > To help mitigate the risk of timeouts, and to remove legacy code
> I'm
> > > > going
> > > > > to re-create the travis.yml file from scratch.  I think it'll be
> much
> > > > less
> > > > > confusing if we only have working code related to Travis in our
> > > codebase,
> > > > > so that contributors won't have to experiment to see what is or
> isn't
> > > > > working.  We've got some great, but slightly out-of-date
> > functionality
> > > in
> > > > > the legacy .travis.yml file.  I hope we can work together to update
> > the
> > > > > legacy features, ensure they work with the current folder structure
> > and
> > > > > also make sure the features run within Travis's 45 minute global
> time
> > > > > window.
> > > > >
> > > > > I'd also like to set expectations that this is strictly a volunteer
> > > > > effort.  I'd welcome help from the community for support and
> > > maintenance.
> > > > > The model downloading caching work particularly stands out to me as
> > > > > something I'd like to 

Re: [VOTE] Release MXNet version 1.3.0.RC0

[Roshani Nagmote]

I believe everyone here is working hard to make MXNet a better framework
for users. It's completely okay to have different opinions, we can decide
together if this issue is a blocker or not after voting time is over.

As I mentioned before, voting will end at 7 pm today. So there is still
time to test the release. If there are any other issues anyone finds, I
will be happy to start the process again and work on RC1. For now, I want
to encourage everyone to utilize this time and vote. :)

Thanks,
Roshani

On Tue, Sep 4, 2018 at 10:35 PM sandeep krishnamurthy <
sandeep.krishn...@gmail.com> wrote:

>1. As a Apache MXNet community member, I raised the concern of broken
>functionality for the user. I explained and provided the data points on
> the
>issue, workaround and why I think it is important. If after all this,
> you
>think my vote is biased on my employer just because a user I quoted is
> from
>Amazon, this is more concerning to me on my voting abilities.
>2. My -1 no where undermines the huge amount of effort that goes behind
>the scene for a release to happen. Great respect and recognition for
>everyone involved in all the releases of MXNet in the past and this. I
>voted on my judgement of what may be good for the users of MXNet.
>3. As pointed by Naveen & Chris, -1 are NOT veto. Feel free to decide
>and progress on the release as we already have >3 +1 in this thread.
>
>
> Best,
>
> Sandeep
>
> On Tue, Sep 4, 2018 at 8:29 PM Chris Olivier 
> wrote:
>
> > btw, there are no vetoes on package releases:
> >
> > VOTES ON PACKAGE RELEASES
> > 
> >
> > Votes on whether a package is ready to be released use majority approval
> >  --
> i.e.
> > at least three PMC members must vote affirmatively for release, and there
> > must be more positive than negative votes.Releases may not be vetoed.
> > Generally
> > the community will cancel the release vote if anyone identifies serious
> > problems, but in most cases the ultimate decision, lies with the
> individual
> > serving as release manager. The specifics of the process may vary from
> > project to project, but the 'minimum quorum of three +1 votes' rule is
> > universal.
> >
> > On Tue, Sep 4, 2018 at 7:12 PM Sheng Zha  wrote:
> >
> > > Thanks for sharing your opinions, Thomas. Your recognition and respect
> of
> > > people's efforts on preparing the release candidate are certainly
> > > appreciated.
> > >
> > > Now that the vote is set to fail thanks to the veto, there will be
> plenty
> > > of opportunities to include those bug fixes, including the one Zhi
> > > mentioned [1], which was already merged in the master and yet chose not
> > to
> > > block this release with [2]. I will be happy to work with Roshani to
> > > prepare another release candidate once ready.
> > >
> > > -sz
> > >
> > > [1]
> > >
> > >
> >
> https://lists.apache.org/thread.html/f02e952bec22c82cb00a6741390a78f55373311c97464997bb455a6c@%3Cdev.mxnet.apache.org%3E
> > > [2]
> > >
> > >
> >
> https://lists.apache.org/thread.html/85d3fcabb3437ba7f1af455cf69aa13eb3afd1ea1d1f6f891e9c339c@%3Cdev.mxnet.apache.org%3E
> > >
> > > On Tue, Sep 4, 2018 at 6:02 PM Thomas DELTEIL <
> thomas.delte...@gmail.com
> > >
> > > wrote:
> > >
> > > > -0
> > > > (non-binding)
> > > >
> > > > If I may add some nuancing plus a personal data point as one of the
> > users
> > > > commenting in the bug report in question:
> > > >
> > > > - Performance vs. Basic functionality => I don't think high
> performance
> > > > use-cases and basic functionality are two obviously opposed concepts
> > and
> > > > see no contradiction in Hagay's and Sandeep's statements.
> > > > Float16 support is feature of MXNet that provides more than twice the
> > > > performance of Float32 on supported platforms, hence the high
> > performance
> > > > use-case. The bug is that the basic functionality of reloading a
> saved
> > > > float16 models is currently broken.
> > > >
> > > > - This bug vs Other bugs => Contrary the vast majority of the 140
> open
> > > bugs
> > > > that are mentioned above, I would put to Sandeep's credit that this
> one
> > > bug
> > > > has a PR open that provides a fix for it. This would make it a better
> > > > candidate to get included in this release than a bug that has no fix
> > > ready
> > > > for it.
> > > >
> > > > - Personal datapoint: I recently did some experimentation with
> float16
> > > [1]
> > > > and actually coincidentally just published a video on optimizing
> > > > performance for Gluon. Float16 conversion is one of the most, if not
> > the
> > > > most effective way to get performance out of MXNet [2]. I believe
> there
> > > is
> > > > a lot of value in publicizing more its use and hence making sure at
> > least
> > > > the basic support for normal use-cases is present.
> > > >
> > > > Of course this needs to be balanced with 

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[Tianqi Chen]

is it possible for us to get a MacBook and hook it to the current Jenkins
CI? Travis OSX usually build from scratch and that was pretty slow

Tianqi


On Wed, Sep 5, 2018 at 8:49 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Great you feel that way Lin, please feel free to contribute if you have any
> features you'd like tested.  We are using the travis image xcode9.4 which
> is based on MacOS 10.13.
>
> On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan  wrote:
>
> > Hi Kellen,
> >
> > Many thanks for your and Marco's effort! I think this is a very crucial
> > piece to improve MXNet stability.
> >
> > To add some data points:
> > 1) Customers using CoreML to MXNet converter were blocked for a while
> > because the converter was broken and no unit test was in place to detect
> > that.
> > 2) Developers on Mac cannot verify their local commits because some unit
> > tests on master were broken. This wasted much time and resource on
> jenkins
> > server to detect the failure.
> > 3) Please consider running the CI on Mac OS 10.13 since this is the
> minimum
> > Mac OS version that supports CoreML (to support CoreML to MXNet
> converter)
> >
> > Best Regards,
> >
> > Lin
> >
> > On Wed, Sep 5, 2018, 3:02 AM kellen sunderland <
> > kellen.sunderl...@gmail.com>
> > wrote:
> >
> > > I'm bumping this thread as we've recently had our first serious bug on
> > > MacOS that would have been caught by enabling Travis.
> > >
> > > I'm going to do a little experimental work together with Marco with the
> > > goal of enabling a minimal Travis build that will run python tests.  So
> > far
> > > I've verified that Travis will in fact find a bug that currently exists
> > in
> > > master and has been reproduced by MacOS clients.  This indicates to me
> > that
> > > adding Travis will add value to our CI.
> > >
> > > My best guess is that it might take us some iteration before we find a
> > > scalable way to integrate Travis.  Given this we're going to enable
> > Travis
> > > in non-blocking mode (i.e. failures are safe to ignore for the time
> > being).
> > >
> > > To help mitigate the risk of timeouts, and to remove legacy code I'm
> > going
> > > to re-create the travis.yml file from scratch.  I think it'll be much
> > less
> > > confusing if we only have working code related to Travis in our
> codebase,
> > > so that contributors won't have to experiment to see what is or isn't
> > > working.  We've got some great, but slightly out-of-date functionality
> in
> > > the legacy .travis.yml file.  I hope we can work together to update the
> > > legacy features, ensure they work with the current folder structure and
> > > also make sure the features run within Travis's 45 minute global time
> > > window.
> > >
> > > I'd also like to set expectations that this is strictly a volunteer
> > > effort.  I'd welcome help from the community for support and
> maintenance.
> > > The model downloading caching work particularly stands out to me as
> > > something I'd like to re-enable again as soon as possible.
> > >
> > > -Kellen
> > >
> > > On Tue, Jan 9, 2018 at 11:52 AM Marco de Abreu <
> > > marco.g.ab...@googlemail.com>
> > > wrote:
> > >
> > > > Looks good! +1
> > > >
> > > > On Tue, Jan 9, 2018 at 10:24 AM, kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > > > I think most were in favour of at a minimum creating a clang build
> so
> > > > I've
> > > > > created a PR
> > > > > https://github.com/apache/incubator-mxnet/pull/9330/commits/
> > > > > 84089ea14123ebe4d66cc92e82a2d529cfbd8b19.
> > > > > My hope is this will catch many of the issues blocking OSX builds.
> > In
> > > > fact
> > > > > it already caught one issue.  If you guys are in favour I can
> remove
> > > the
> > > > > WIP and ask that it be merged.
> > > > >
> > > > > On Thu, Jan 4, 2018 at 6:29 PM, Chris Olivier <
> cjolivie...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Nope, I have been on vacation.
> > > > > >
> > > > > > On Thu, Jan 4, 2018 at 9:10 AM, kellen sunderland <
> > > > > > kellen.sunderl...@gmail.com> wrote:
> > > > > >
> > > > > > > Hope everyone had a good break.  Just wanted to check if there
> > were
> > > > > > further
> > > > > > > thoughts on OSX builds.  Chris, did you have time to look into
> > > > > > virtualizing
> > > > > > > Mac OS?  Would it make sense for us to put something in place
> in
> > > the
> > > > > > > interim e.g. the clang solution?
> > > > > > >
> > > > > > > On Tue, Dec 12, 2017 at 7:59 PM, de Abreu, Marco <
> > > mab...@amazon.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Thanks for looking into this, Chris! No hurries on that one,
> > > we’ll
> > > > > look
> > > > > > > > into it next stage when we add new system- and
> > > build-configurations
> > > > > to
> > > > > > > the
> > > > > > > > CI.
> > > > > > > >
> > > > > > > > On 12.12.17, 19:12, "Chris Olivier" 
> > > wrote:
> > > > > > > >
> > > > > > > > I am on vacation starting Thursday.
> > > > > > > >
> > > > 

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[kellen sunderland]

Great you feel that way Lin, please feel free to contribute if you have any
features you'd like tested.  We are using the travis image xcode9.4 which
is based on MacOS 10.13.

On Wed, Sep 5, 2018 at 6:40 PM Lin Yuan  wrote:

> Hi Kellen,
>
> Many thanks for your and Marco's effort! I think this is a very crucial
> piece to improve MXNet stability.
>
> To add some data points:
> 1) Customers using CoreML to MXNet converter were blocked for a while
> because the converter was broken and no unit test was in place to detect
> that.
> 2) Developers on Mac cannot verify their local commits because some unit
> tests on master were broken. This wasted much time and resource on jenkins
> server to detect the failure.
> 3) Please consider running the CI on Mac OS 10.13 since this is the minimum
> Mac OS version that supports CoreML (to support CoreML to MXNet converter)
>
> Best Regards,
>
> Lin
>
> On Wed, Sep 5, 2018, 3:02 AM kellen sunderland <
> kellen.sunderl...@gmail.com>
> wrote:
>
> > I'm bumping this thread as we've recently had our first serious bug on
> > MacOS that would have been caught by enabling Travis.
> >
> > I'm going to do a little experimental work together with Marco with the
> > goal of enabling a minimal Travis build that will run python tests.  So
> far
> > I've verified that Travis will in fact find a bug that currently exists
> in
> > master and has been reproduced by MacOS clients.  This indicates to me
> that
> > adding Travis will add value to our CI.
> >
> > My best guess is that it might take us some iteration before we find a
> > scalable way to integrate Travis.  Given this we're going to enable
> Travis
> > in non-blocking mode (i.e. failures are safe to ignore for the time
> being).
> >
> > To help mitigate the risk of timeouts, and to remove legacy code I'm
> going
> > to re-create the travis.yml file from scratch.  I think it'll be much
> less
> > confusing if we only have working code related to Travis in our codebase,
> > so that contributors won't have to experiment to see what is or isn't
> > working.  We've got some great, but slightly out-of-date functionality in
> > the legacy .travis.yml file.  I hope we can work together to update the
> > legacy features, ensure they work with the current folder structure and
> > also make sure the features run within Travis's 45 minute global time
> > window.
> >
> > I'd also like to set expectations that this is strictly a volunteer
> > effort.  I'd welcome help from the community for support and maintenance.
> > The model downloading caching work particularly stands out to me as
> > something I'd like to re-enable again as soon as possible.
> >
> > -Kellen
> >
> > On Tue, Jan 9, 2018 at 11:52 AM Marco de Abreu <
> > marco.g.ab...@googlemail.com>
> > wrote:
> >
> > > Looks good! +1
> > >
> > > On Tue, Jan 9, 2018 at 10:24 AM, kellen sunderland <
> > > kellen.sunderl...@gmail.com> wrote:
> > >
> > > > I think most were in favour of at a minimum creating a clang build so
> > > I've
> > > > created a PR
> > > > https://github.com/apache/incubator-mxnet/pull/9330/commits/
> > > > 84089ea14123ebe4d66cc92e82a2d529cfbd8b19.
> > > > My hope is this will catch many of the issues blocking OSX builds.
> In
> > > fact
> > > > it already caught one issue.  If you guys are in favour I can remove
> > the
> > > > WIP and ask that it be merged.
> > > >
> > > > On Thu, Jan 4, 2018 at 6:29 PM, Chris Olivier  >
> > > > wrote:
> > > >
> > > > > Nope, I have been on vacation.
> > > > >
> > > > > On Thu, Jan 4, 2018 at 9:10 AM, kellen sunderland <
> > > > > kellen.sunderl...@gmail.com> wrote:
> > > > >
> > > > > > Hope everyone had a good break.  Just wanted to check if there
> were
> > > > > further
> > > > > > thoughts on OSX builds.  Chris, did you have time to look into
> > > > > virtualizing
> > > > > > Mac OS?  Would it make sense for us to put something in place in
> > the
> > > > > > interim e.g. the clang solution?
> > > > > >
> > > > > > On Tue, Dec 12, 2017 at 7:59 PM, de Abreu, Marco <
> > mab...@amazon.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Thanks for looking into this, Chris! No hurries on that one,
> > we’ll
> > > > look
> > > > > > > into it next stage when we add new system- and
> > build-configurations
> > > > to
> > > > > > the
> > > > > > > CI.
> > > > > > >
> > > > > > > On 12.12.17, 19:12, "Chris Olivier" 
> > wrote:
> > > > > > >
> > > > > > > I am on vacation starting Thursday.
> > > > > > >
> > > > > > > On Tue, Dec 12, 2017 at 9:49 AM kellen sunderland <
> > > > > > > kellen.sunderl...@gmail.com> wrote:
> > > > > > >
> > > > > > > > Absolutely, let's do an investigation and see if it's
> > > possible
> > > > to
> > > > > > > > virtualize.  Would you have time to look into it a bit
> > > further?
> > > > > > > >
> > > > > > > > On Tue, Dec 12, 2017 at 6:47 PM, Chris Olivier <
> > > > > > > cjolivie...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Don’t get me 

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[Lin Yuan]

Hi Kellen,

Many thanks for your and Marco's effort! I think this is a very crucial
piece to improve MXNet stability.

To add some data points:
1) Customers using CoreML to MXNet converter were blocked for a while
because the converter was broken and no unit test was in place to detect
that.
2) Developers on Mac cannot verify their local commits because some unit
tests on master were broken. This wasted much time and resource on jenkins
server to detect the failure.
3) Please consider running the CI on Mac OS 10.13 since this is the minimum
Mac OS version that supports CoreML (to support CoreML to MXNet converter)

Best Regards,

Lin

On Wed, Sep 5, 2018, 3:02 AM kellen sunderland 
wrote:

> I'm bumping this thread as we've recently had our first serious bug on
> MacOS that would have been caught by enabling Travis.
>
> I'm going to do a little experimental work together with Marco with the
> goal of enabling a minimal Travis build that will run python tests.  So far
> I've verified that Travis will in fact find a bug that currently exists in
> master and has been reproduced by MacOS clients.  This indicates to me that
> adding Travis will add value to our CI.
>
> My best guess is that it might take us some iteration before we find a
> scalable way to integrate Travis.  Given this we're going to enable Travis
> in non-blocking mode (i.e. failures are safe to ignore for the time being).
>
> To help mitigate the risk of timeouts, and to remove legacy code I'm going
> to re-create the travis.yml file from scratch.  I think it'll be much less
> confusing if we only have working code related to Travis in our codebase,
> so that contributors won't have to experiment to see what is or isn't
> working.  We've got some great, but slightly out-of-date functionality in
> the legacy .travis.yml file.  I hope we can work together to update the
> legacy features, ensure they work with the current folder structure and
> also make sure the features run within Travis's 45 minute global time
> window.
>
> I'd also like to set expectations that this is strictly a volunteer
> effort.  I'd welcome help from the community for support and maintenance.
> The model downloading caching work particularly stands out to me as
> something I'd like to re-enable again as soon as possible.
>
> -Kellen
>
> On Tue, Jan 9, 2018 at 11:52 AM Marco de Abreu <
> marco.g.ab...@googlemail.com>
> wrote:
>
> > Looks good! +1
> >
> > On Tue, Jan 9, 2018 at 10:24 AM, kellen sunderland <
> > kellen.sunderl...@gmail.com> wrote:
> >
> > > I think most were in favour of at a minimum creating a clang build so
> > I've
> > > created a PR
> > > https://github.com/apache/incubator-mxnet/pull/9330/commits/
> > > 84089ea14123ebe4d66cc92e82a2d529cfbd8b19.
> > > My hope is this will catch many of the issues blocking OSX builds.  In
> > fact
> > > it already caught one issue.  If you guys are in favour I can remove
> the
> > > WIP and ask that it be merged.
> > >
> > > On Thu, Jan 4, 2018 at 6:29 PM, Chris Olivier 
> > > wrote:
> > >
> > > > Nope, I have been on vacation.
> > > >
> > > > On Thu, Jan 4, 2018 at 9:10 AM, kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > > > Hope everyone had a good break.  Just wanted to check if there were
> > > > further
> > > > > thoughts on OSX builds.  Chris, did you have time to look into
> > > > virtualizing
> > > > > Mac OS?  Would it make sense for us to put something in place in
> the
> > > > > interim e.g. the clang solution?
> > > > >
> > > > > On Tue, Dec 12, 2017 at 7:59 PM, de Abreu, Marco <
> mab...@amazon.com>
> > > > > wrote:
> > > > >
> > > > > > Thanks for looking into this, Chris! No hurries on that one,
> we’ll
> > > look
> > > > > > into it next stage when we add new system- and
> build-configurations
> > > to
> > > > > the
> > > > > > CI.
> > > > > >
> > > > > > On 12.12.17, 19:12, "Chris Olivier" 
> wrote:
> > > > > >
> > > > > > I am on vacation starting Thursday.
> > > > > >
> > > > > > On Tue, Dec 12, 2017 at 9:49 AM kellen sunderland <
> > > > > > kellen.sunderl...@gmail.com> wrote:
> > > > > >
> > > > > > > Absolutely, let's do an investigation and see if it's
> > possible
> > > to
> > > > > > > virtualize.  Would you have time to look into it a bit
> > further?
> > > > > > >
> > > > > > > On Tue, Dec 12, 2017 at 6:47 PM, Chris Olivier <
> > > > > > cjolivie...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Don’t get me wrong, I’m not saying this Mac OS Jenkins
> > > solution
> > > > > is
> > > > > > doable
> > > > > > > > but I feel like we should investigate because the payoff
> > > would
> > > > be
> > > > > > large.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Dec 12, 2017 at 9:38 AM Chris Olivier <
> > > > > > cjolivie...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Apple’s Darwin OS Is recently open-sourced.
> > > > > > > > > 

Re: reminder next virtual Apache MXNet hangout on Sep 5th 8am and 5pm PDT

[Steffen Rochel]

My apology, something is not working with the meeting ID, Please use 6357
02 3396#
Steffen

On Thu, Aug 30, 2018 at 7:52 AM Steffen Rochel 
wrote:

> Our next virtual Apache MXNet hangout will be on Sep 5th at 8am and 5pm
> PDT. Hope you can join.
>
> *Meeting information:*
>
> 1. Click to join the meeting: https://chime.aws/4432972704   Meeting ID:
> 4432 97 2704
>
> 2. You can use your computer’s microphone and speakers, however, a headset
> is recommended. Or, call in using your phone:
>
> United States Toll-Free: +1 855-552-4463 <(855)%20552-4463>
> Meeting PIN: 4432 97 2704
>
> One-click Mobile Dial-in (United States (1)): +1 206-462-5569
> <(206)%20462-5569>,,4432972704 <(443)%20297-2704>#
>
> United States (1): +1 206-462-5569 <(206)%20462-5569>
> International: https://chime.aws/dialinnumbers/
>
> Regards,
>
> Steffen
>
>
> Proposed Agenda:
>
>1. Introduction of participants
>2. Release 1.3 updates
>3. Feedback on PR Best Practices
>
>4. Brainstorm for next release(s)
>
>

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[kellen sunderland]

I'm bumping this thread as we've recently had our first serious bug on
MacOS that would have been caught by enabling Travis.

I'm going to do a little experimental work together with Marco with the
goal of enabling a minimal Travis build that will run python tests.  So far
I've verified that Travis will in fact find a bug that currently exists in
master and has been reproduced by MacOS clients.  This indicates to me that
adding Travis will add value to our CI.

My best guess is that it might take us some iteration before we find a
scalable way to integrate Travis.  Given this we're going to enable Travis
in non-blocking mode (i.e. failures are safe to ignore for the time being).

To help mitigate the risk of timeouts, and to remove legacy code I'm going
to re-create the travis.yml file from scratch.  I think it'll be much less
confusing if we only have working code related to Travis in our codebase,
so that contributors won't have to experiment to see what is or isn't
working.  We've got some great, but slightly out-of-date functionality in
the legacy .travis.yml file.  I hope we can work together to update the
legacy features, ensure they work with the current folder structure and
also make sure the features run within Travis's 45 minute global time
window.

I'd also like to set expectations that this is strictly a volunteer
effort.  I'd welcome help from the community for support and maintenance.
The model downloading caching work particularly stands out to me as
something I'd like to re-enable again as soon as possible.

-Kellen

On Tue, Jan 9, 2018 at 11:52 AM Marco de Abreu 
wrote:

> Looks good! +1
>
> On Tue, Jan 9, 2018 at 10:24 AM, kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > I think most were in favour of at a minimum creating a clang build so
> I've
> > created a PR
> > https://github.com/apache/incubator-mxnet/pull/9330/commits/
> > 84089ea14123ebe4d66cc92e82a2d529cfbd8b19.
> > My hope is this will catch many of the issues blocking OSX builds.  In
> fact
> > it already caught one issue.  If you guys are in favour I can remove the
> > WIP and ask that it be merged.
> >
> > On Thu, Jan 4, 2018 at 6:29 PM, Chris Olivier 
> > wrote:
> >
> > > Nope, I have been on vacation.
> > >
> > > On Thu, Jan 4, 2018 at 9:10 AM, kellen sunderland <
> > > kellen.sunderl...@gmail.com> wrote:
> > >
> > > > Hope everyone had a good break.  Just wanted to check if there were
> > > further
> > > > thoughts on OSX builds.  Chris, did you have time to look into
> > > virtualizing
> > > > Mac OS?  Would it make sense for us to put something in place in the
> > > > interim e.g. the clang solution?
> > > >
> > > > On Tue, Dec 12, 2017 at 7:59 PM, de Abreu, Marco 
> > > > wrote:
> > > >
> > > > > Thanks for looking into this, Chris! No hurries on that one, we’ll
> > look
> > > > > into it next stage when we add new system- and build-configurations
> > to
> > > > the
> > > > > CI.
> > > > >
> > > > > On 12.12.17, 19:12, "Chris Olivier"  wrote:
> > > > >
> > > > > I am on vacation starting Thursday.
> > > > >
> > > > > On Tue, Dec 12, 2017 at 9:49 AM kellen sunderland <
> > > > > kellen.sunderl...@gmail.com> wrote:
> > > > >
> > > > > > Absolutely, let's do an investigation and see if it's
> possible
> > to
> > > > > > virtualize.  Would you have time to look into it a bit
> further?
> > > > > >
> > > > > > On Tue, Dec 12, 2017 at 6:47 PM, Chris Olivier <
> > > > > cjolivie...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Don’t get me wrong, I’m not saying this Mac OS Jenkins
> > solution
> > > > is
> > > > > doable
> > > > > > > but I feel like we should investigate because the payoff
> > would
> > > be
> > > > > large.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Dec 12, 2017 at 9:38 AM Chris Olivier <
> > > > > cjolivie...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Apple’s Darwin OS Is recently open-sourced.
> > > > > > > > https://github.com/PureDarwin/PureDarwin
> > > > > > > >
> > > > > > > > How to convert this into a non-GUI VM I am not sure but I
> > am
> > > > > willing to
> > > > > > > > bet that people have done it already.
> > > > > > > >
> > > > > > > > On Tue, Dec 12, 2017 at 9:16 AM kellen sunderland <
> > > > > > > > kellen.sunderl...@gmail.com> wrote:
> > > > > > > >
> > > > > > > >> It might be technically possible, but I think it would
> > > violate
> > > > > the
> > > > > > MacOS
> > > > > > > >> license: http://store.apple.com/
> > > Catalog/US/Images/MacOSX.htm
> > > > > > > >>
> > > > > > > >> "2. Permitted License Uses and Restrictions.
> > > > > > > >> A. This License allows you to install and use one copy
> of
> > > the
> > > > > Apple
> > > > > > > >> Software on a single Apple-labeled computer at a time.
> > This
> > > > > License
> > > > > > does
> > > > > > > >> not allow the Apple Software to exist on more 

Re: Propose to discontinue supporting Apache MXNet on Windows 7

[kellen sunderland]

I've seen enough anecdotes to switch to -1.  Visual Studio 2017 claims
support for Windows 7:
https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs
so I'm not sure if compiler support is really an issue.

On Tue, Sep 4, 2018 at 8:09 PM Joshua Z. Zhang  wrote:

> I have contacted some friends in industry, they claim that some controller
> PCs are still on win7 and have no plan to upgrade in near future, so I
> would strongly go -1.
>
> In terms of build system on Windows 7, MS does give warnings in VS 2015,
> but with compatibility mode, we can still install it without issue. So I
> guess it’s marketing strategy not technical problem on MS side.
>
> Zhi
>
> > On Sep 4, 2018, at 9:02 AM, sebastianb 
> wrote:
> >
> > One more data point: Mathematica still supports Windows 7 (with Platform
> Update), and we use MXNet as a backend for our neural net framework. So I
> would also vote against deprecating Windows 7 support.
> >
> >> On Sep 2, 2018, at 7:40 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.INVALID> wrote:
> >>
> >> Thanks for the data and these quite important points. I agree and hereby
> >> change my vote to -1.
> >>
> >> Barber, Christopher  schrieb am So., 2.
> Sep.
> >> 2018, 18:56:
> >>
> >>> FWIW, my company is only beginning to transition to Windows 10 now,
> and my
> >>> past experience would lead me to believe that many enterprises stick
> with
> >>> old versions of Windows long past when you think they would.
> >>>
> >>> Seems to me that if you are unwilling to deprecate python 2.7, then
> >>> continuing to support Windows 7 is a no-brainer. You are more likely
> to get
> >>> users to switch to python 3 than you are to get them to install a new
> >>> operating system.
> >>>
> >>> And do you really want to drop support for platforms that your
> competitors
> >>> still support? Given MXNet's market share, I wouldn't dream of
> dropping a
> >>> platform until after the more popular frameworks have already done so.
> >>>
> >>> I also believe that it is possible to install more recent versions of
> >>> Visual Studio on Windows 7.
> >>>
> >>> On 9/2/18, 1:57 AM, "kellen sunderland" 
> >>> wrote:
> >>>
> >>>   Google analytics are sadly probably the best numbers we're going to
> >>> get.
> >>>   Of course these numbers are likely to over-represent windows usage,
> as
> >>> I'm
> >>>   sure many people are looking up documentation on a windows machine
> >>> while
> >>>   ssh'd into a cloud instance or IoT device.
> >>>
> >>>   What's the trend over time for these numbers Mu?  Is Windows 7 usage
> >>>   relatively stable over the last year?
> >>>
> >>>   On Sun, Sep 2, 2018 at 1:58 AM Mu Li  wrote:
> >>>
>  According to google analytics, ~12% users who visited mxnet's
> >>> website are
>  using Windows 7. It's a significant number. Even though we cannot
> >>> conclude
>  that all of these users will run MXNet on Windows 7, I suggest we
> >>> still
>  support win7.
> 
>  BTW, anyone who can access mxnet's google analytics report can
> >>> verify this
>  number by following this instruction:
> 
> 
> >>>
> https://stackoverflow.com/questions/1340778/detecting-windows-7-with-google-analytics
> 
> 
> 
>  On Sat, Sep 1, 2018 at 1:55 PM Steffen Rochel <
> >>> steffenroc...@gmail.com>
>  wrote:
> 
> > I support a data driven decision. Any suggestions how we can obtain
>  insight
> > about OS usage of the MXNet user community?
> > Can we get such information from pip install statistics or should
> >>> we
> > perform a user poll on the discussion forum?
> > On the other hand the lack of data should not prevent us from
> >>> moving
> > forward and dropping support for outdated OS.
> > In any case we would have to announce dropping a platform support
> >>> at
>  least
> > a release in advance.
> > Steffen
> >
> > On Thu, Aug 30, 2018 at 12:21 PM Sheng Zha 
> >>> wrote:
> >
> >> Hi Kellen,
> >>
> >> Thanks for the explanation. Unfortunately, I don't have the
> >>> usage data,
> > so
> >> I refrained from voting. If any of the voters have such data I'd
> >>> love
>  to
> >> see it too.
> >>
> >> -sz
> >>
> >> On 2018/08/30 14:58:09, kellen sunderland <
> >>> kellen.sunderl...@gmail.com
> >
> >> wrote:
> >>> I haven't spoken to anyone about the decision (as I'm
> >>> currently on an
> >>> island in the med) but to me the quick +1s are likely a result
> >>> of
>  this
> >>> being a fairly straightforward decision.  The factors that
> >>> went into
>  my
> >>> thinking were (1) prioritizing growing platforms rather than
>  shrinking
> >>> platforms (i.e. thinking long term rather than shirt term) and
> >>> (2)
> >> earning
> >>> our customers' trust.  Claiming support for a platform when we
> >>> can't
> >>> realistically deliver it would lose us trust.  I'd prefer to