Re: [VOTE] Release MXNet version 1.3.0.RC0

2018-09-06 Thread Anirudh 
-1 Considering that using fp16 with gluon is much easier than the
alternative where you need access to the model code, this fix is really
useful. I understand the pain of doing mxnet release and appreciate Roshani
and Shengs efforts, but this seems like something we should fix.

On Thu, Sep 6, 2018, 4:57 PM Haibin Lin  wrote:

> +1 built from source and passes dist_sync_kvstore test on Ubuntu.
>
> Best,
> Haibin
>
> On Thu, Sep 6, 2018 at 1:32 PM Indhu  wrote:
>
> > +1
> >
> > The release candidate looks good. I'm able to build and run basic models.
> >
> > One the FP16 issue:
> >
> > Like others have pointed out, releases on expensive in terms of time and
> > effort. There needs to be a high and more objective bar on what qualifies
> > as a release blocker to make sure we are not setting precedence for a lot
> > of release blockers in future.
> >
> > I think a release blocker is justified only if there is a serious bug
> > discovered in one of the features included in the release or if there is
> a
> > regression. Given FP16 supports is not a new feature claimed in this
> > release and this is not a regression in this release candidate, I'm
> > inclined to release this candidate and include the FP16 fix in a
> subsequent
> > release.
> >
> > Thanks,
> > Indu
> >
> > On Wed, Sep 5, 2018 at 10:21 AM Aaron Markham  >
> > wrote:
> >
> > > 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 <
> > roshaninagmo...@gmail.com>
> > > 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 <
> cjolivie...@gmail.com>
> > > > > 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
> > > > > > <
> https://www.apache.org/foundation/glossary.html#MajorityApproval>
> > > --
> > > > > 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

Re: [VOTE] Release MXNet version 1.3.0.RC0

2018-09-06 Thread Haibin Lin 
+1 built from source and passes dist_sync_kvstore test on Ubuntu.

Best,
Haibin

On Thu, Sep 6, 2018 at 1:32 PM Indhu  wrote:

> +1
>
> The release candidate looks good. I'm able to build and run basic models.
>
> One the FP16 issue:
>
> Like others have pointed out, releases on expensive in terms of time and
> effort. There needs to be a high and more objective bar on what qualifies
> as a release blocker to make sure we are not setting precedence for a lot
> of release blockers in future.
>
> I think a release blocker is justified only if there is a serious bug
> discovered in one of the features included in the release or if there is a
> regression. Given FP16 supports is not a new feature claimed in this
> release and this is not a regression in this release candidate, I'm
> inclined to release this candidate and include the FP16 fix in a subsequent
> release.
>
> Thanks,
> Indu
>
> On Wed, Sep 5, 2018 at 10:21 AM Aaron Markham 
> wrote:
>
> > 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 <
> roshaninagmo...@gmail.com>
> > 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]
>

Re: Publish MXNet images to DockerHub

2018-09-06 Thread kellen sunderland 
Hey folks, I've got a TensorRT Dockerfile here:
https://raw.githubusercontent.com/KellenSunderland/incubator-mxnet/tensorrt_runtime_docker/docker/Dockerfile.tensorrt

I'm wondering what the next step would be in merging it.  Do all agree that
it would make sense to get rid of the current docker folder?  Would merging
a basic replacement folder like this make sense as a placeholder?
https://github.com/KellenSunderland/incubator-mxnet/tree/tensorrt_runtime_docker/docker

-Kellen


On Thu, Jul 26, 2018 at 4:36 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> Awesome.  Thanks Meghna.
>
> On Wed, Jul 25, 2018, 11:08 PM Meghna Baijal 
> wrote:
>
>> Hi Anirudh,
>> Thanks for bringing this up.
>> The Python Images are being actively released for each MXNet version.
>> Until
>> last release I was using the script Mu has pointed out but from 1.2.1 I
>> replaced these dockerfiles to use the pip binaries instead of building
>> from
>> source.
>> Images for all other language bindings were being released only until
>> MXNet
>> 0.12.0 since they were not being maintained. I think there are a couple of
>> github issues open to track broken dockerfiles.
>>
>> Kellen,
>>
>> I can help you publish the docker images to dockerhub.
>>
>>
>> Thanks,
>>
>> Meghna Baijal
>>
>>
>>
>>
>> On Tue, Jul 24, 2018 at 4:45 PM Anirudh Acharya 
>> wrote:
>>
>> > Yes that would be good. Also I just noticed that in the Installation
>> > instructions page only python has docker image installation instruction
>> > here -
>> >
>> >
>> http://mxnet.incubator.apache.org/install/index.html?platform=Linux=Python=CPU
>> > Similar instructions need to be there for other bindings too.
>> >
>> > On Tue, Jul 24, 2018 at 4:04 PM kellen sunderland <
>> > kellen.sunderl...@gmail.com> wrote:
>> >
>> > > I was actually interested in pushing a version of MXNet with TensorRT
>> > > enabled some time in the next few weeks just so that people can
>> > experiment
>> > > with the feature without worrying about installing the right protoc
>> and
>> > > onnx versions.  If people here think it's a good idea I can open a PR
>> > with
>> > > a runtime-docker folder with the intent that this work could be a
>> > template
>> > > for others who want to contribute runtime Dockerfiles?  If a few
>> > > contributors do put together an Dockerfile with TensorRT enabled,
>> would
>> > it
>> > > be possible to get that image pushed to the MXNet Dockerhub repo by a
>> > > committer?
>> > >
>> > > On Sun, Jul 22, 2018 at 3:57 PM Anirudh Acharya <
>> anirudhk...@gmail.com>
>> > > wrote:
>> > >
>> > > > @Naveen No, I meant in general, for all bindings. Irrespective of
>> > whether
>> > > > we use a package management repository, being able to pull an image
>> > from
>> > > > docker hub would be convenient for anyone wanting to get started on
>> > MXNet
>> > > > or run services( as Kellen said).
>> > > >
>> > > >
>> > > > On Sun, Jul 22, 2018 at 11:20 AM kellen sunderland <
>> > > > kellen.sunderl...@gmail.com> wrote:
>> > > >
>> > > > > I think it's a good idea Anirudh.  It should help users easily get
>> > > MXNet
>> > > > up
>> > > > > and running whether they're running services, following tutorials,
>> > etc.
>> > > > >
>> > > > > On Sun, Jul 22, 2018 at 8:10 AM Naveen Swamy 
>> > > wrote:
>> > > > >
>> > > > > > I don't think we need for JVM languages, they have a good
>> > dependency
>> > > > > > management through Maven Central. We weren't publishing
>> regularly
>> > to
>> > > > > Maven,
>> > > > > > now we do.
>> > > > > >
>> > > > > > Anirudh, I am guessing you are interested docker for R
>> language, If
>> > > > the R
>> > > > > > packages were published to CRAN do you still see a need for
>> docker
>> > ?
>> > > > > Could
>> > > > > > you elaborate how this would be helpful and easy if they were to
>> > use
>> > > > > other
>> > > > > > packages in CRAN?
>> > > > > >
>> > > > > > On Sat, Jul 21, 2018 at 10:51 PM, Anirudh Acharya <
>> > > > anirudhk...@gmail.com
>> > > > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Yes, correct cu90 is indeed there, thanks for pointing it.
>> > > > > > >
>> > > > > > > So the question, should we be publishing to Docker Hub as
>> part of
>> > > the
>> > > > > > > release process so that bindings other than python are also
>> > > published
>> > > > > and
>> > > > > > > there is a policy on what cuda versions we publish?
>> > > > > > >
>> > > > > > >
>> > > > > > > Thanks
>> > > > > > > ANirudh
>> > > > > > >
>> > > > > > > On Sat, Jul 21, 2018 at 9:56 PM Mu Li 
>> > wrote:
>> > > > > > >
>> > > > > > > > cu90 and cu90mkl are also available, see
>> > > > > > > > https://hub.docker.com/r/mxnet/python/tags/
>> > > > > > > >
>> > > > > > > > On Sat, Jul 21, 2018 at 9:51 PM, Anirudh Acharya <
>> > > > > > anirudhk...@gmail.com>
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > The python binding that is actively maintained is
>> > > > > > > > >
>> > > > > > > > > mxnet-mkl  1.2.1
>> > > > > > > > >
>> > > > > > > >

Re: [VOTE] Release MXNet version 1.3.0.RC0

2018-09-06 Thread Indhu 
+1

The release candidate looks good. I'm able to build and run basic models.

One the FP16 issue:

Like others have pointed out, releases on expensive in terms of time and
effort. There needs to be a high and more objective bar on what qualifies
as a release blocker to make sure we are not setting precedence for a lot
of release blockers in future.

I think a release blocker is justified only if there is a serious bug
discovered in one of the features included in the release or if there is a
regression. Given FP16 supports is not a new feature claimed in this
release and this is not a regression in this release candidate, I'm
inclined to release this candidate and include the FP16 fix in a subsequent
release.

Thanks,
Indu

On Wed, Sep 5, 2018 at 10:21 AM Aaron Markham 
wrote:

> 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 <
> > >

Re: [VOTE] Release MXNet version 1.3.0.RC0

2018-09-06 Thread Roshani Nagmote 
Thanks Kellen and Naveen for pointing it out.
Now we have 3 committers +1 votes to move forward with the release. But it
will be great if more people can test the release.

I am extending the timeline for voting till 7 pm today. Please test and
vote.

Thanks,
Roshani

On Thu, Sep 6, 2018 at 5:46 AM Naveen Swamy  wrote:

> +1
>
>
> Roshani/Sheng,
>
> Thanks for putting this release together, I was able to test the release
> only now. As Kellen indicated this release does not have enough committer
> votes, I suggest you extend the timeline.
>
> I downloaded the source code from
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.3.0.rc0/.
>
> I verified the signature of the release and built the Scala package from
> this source, I was able to run Scala Unit Tests and Integration tests
> successfully.
>
> Also IMO, the issue that Sandeep though is good to include in the release,
> I would not consider it a release blocker since it has a work around and
> you can add it to release notes as a link to the github issue with the
> workaround.
>
> Other notes (consider adding to retrospective):
>
> On running  gpg --verify, I received a message that the signature is Good
> from Sheng Zha along with a WARNING(gpg: WARNING: This key is not certified
> with a trusted signature!), On researching I found this is fine[1] and the
> fingerprint matches with Sheng's Key here
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS.
>
> Next time, please send a link to the source and signatures on apache dist
> server
>
> I am currently working with Qing to create and test a maven package for
> Scala, please wait and add that to the Announcement email.
>
> Next time, please give a day or two after the RC is cut so we can create
> packages for various language bindings(Scala, Clojure, R) --(currently this
> is manual), so we can get the packages that users use tested during the RC
> phase.
>
> During the release, I suggest the release manager communicate
> regularly(daily) on dev@ until an announcement is made so everyone is
> aware
> of the status and can plan their work to accommodate building packages,
> testing RC, etc.,
>
> 1.
>
> http://www.apache.org/dev/release-signing.html#valid-untrusted-vs-invalid-trusted
>
>
> Thanks, Naveen
>
>
>
> On Wed, Sep 5, 2018 at 10:20 AM, Aaron Markham 
> wrote:
>
> > 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 <
> roshaninagmo...@gmail.com>
> > 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
> > > > >

Re: Request to Join Slack Channel

2018-09-06 Thread Steffen Rochel 
Hi Shane - welcome to the Apache MXNet project. Lets us know what you will
be working on and reach out for help from the community as needed.
Steffen

On Thu, Sep 6, 2018 at 7:06 AM Shane Cousins 
wrote:

> Request to Join Slack Channel
>

Request to Join Slack Channel

2018-09-06 Thread Shane Cousins 
Request to Join Slack Channel

Re: [VOTE] Release MXNet version 1.3.0.RC0

2018-09-06 Thread Naveen Swamy 
+1


Roshani/Sheng,

Thanks for putting this release together, I was able to test the release
only now. As Kellen indicated this release does not have enough committer
votes, I suggest you extend the timeline.

I downloaded the source code from
https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.3.0.rc0/.

I verified the signature of the release and built the Scala package from
this source, I was able to run Scala Unit Tests and Integration tests
successfully.

Also IMO, the issue that Sandeep though is good to include in the release,
I would not consider it a release blocker since it has a work around and
you can add it to release notes as a link to the github issue with the
workaround.

Other notes (consider adding to retrospective):

On running  gpg --verify, I received a message that the signature is Good
from Sheng Zha along with a WARNING(gpg: WARNING: This key is not certified
with a trusted signature!), On researching I found this is fine[1] and the
fingerprint matches with Sheng's Key here
https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS.

Next time, please send a link to the source and signatures on apache dist
server

I am currently working with Qing to create and test a maven package for
Scala, please wait and add that to the Announcement email.

Next time, please give a day or two after the RC is cut so we can create
packages for various language bindings(Scala, Clojure, R) --(currently this
is manual), so we can get the packages that users use tested during the RC
phase.

During the release, I suggest the release manager communicate
regularly(daily) on dev@ until an announcement is made so everyone is aware
of the status and can plan their work to accommodate building packages,
testing RC, etc.,

1.
http://www.apache.org/dev/release-signing.html#valid-untrusted-vs-invalid-trusted


Thanks, Naveen



On Wed, Sep 5, 2018 at 10:20 AM, Aaron Markham 
wrote:

> 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

Re: Source images for logos

2018-09-06 Thread Marco de Abreu 
Hi Marcello,

Attachments don't work for Apache email lists.

-Marco

Bossi, Marcelo  schrieb am Do., 6. Sep. 2018,
01:54:

> 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.
>
>
>

Re: [RESULT][VOTE] Release MXNet version 1.3.0

2018-09-06 Thread kellen sunderland 
Hey Roshani, did we only get two votes from committers?  Apache releases
require a minimum quorum of three approving ipmc members.

https://www.apache.org/foundation/voting.html

"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 Thu, Sep 6, 2018 at 7:13 AM Roshani Nagmote 
wrote:

> 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
>