Re: LabelBot New Design in Production

[Hagay Lupesko]

Thanks for this useful contribution Harsh!

+1 to an updated issue template
and +1 to Marco's idea as well
Anything that helps the community triage and make it easier for folks that
file issues is greatly appreciated

Hagay

On Thu, Nov 8, 2018 at 4:05 PM Marco de Abreu
 wrote:

> Great job, Harsh!
>
> That's a very good idea, Naveen. Harsh, Qing and I have been thinking about
> the bot "welcoming" the user when they create an issue or pull request by
> creating a comment as soon as the thread gets created. This message could
> contain basic instructions like these commands, recommendations that are
> dependent on the users requests and other dynamic content that we could
> improve over time (think about it recommending you to check out the discuss
> forum when you ask a question, asking you to provide a minimum reproducible
> example if you report a bug, etc). That way, we would reduce the amount
> boilerplate in the issue template and at the same time provide the user
> with custom tailored assistance.
>
> Best regards,
> Marco
>
> On Fri, Nov 9, 2018 at 1:00 AM Naveen Swamy  wrote:
>
> > Great job!, this is very helpful to triage issues!, users when creating a
> > new Issue could themselves tag the issues. May be we should add that to
> the
> > issue template?
> >
> > On Thu, Nov 8, 2018 at 3:54 PM Harsh Patel 
> > wrote:
> >
> > > Hey all,
> > > The upgraded label bot has been pushed into production. Current
> > > functionality includes
> > > add, delete, and update.
> > > (i.e. @mxnet-label-bot add ['label']
> > > @mxnet-label-bot remove ['label']
> > > @mxnet-label-bot update ['label'])
> > >
> > > Users should feel free to leave suggestions and any potential issues.
> The
> > > forum to this best would be here:
> > > https://github.com/apache/incubator-mxnet/issues/13163
> > >
> > > Best,
> > > -Harsh Patel
> > >
> >
>

Re: MKLDNN dynamically linked

[Hagay Lupesko]

+1
Kellen made a good call about watching out for the license. Not an issue
for MKL-DNN though, which I believe has an Apache 2 license.

On Thu, Nov 8, 2018 at 3:51 PM Zhao, Patric  wrote:

> +1 for static link :)
>
> Feel free to let us know if anything we can help.
>
> > -Original Message-
> > From: kellen sunderland [mailto:kellen.sunderl...@gmail.com]
> > Sent: Friday, November 9, 2018 7:30 AM
> > To: dev@mxnet.incubator.apache.org
> > Cc: d...@mxnet.apache.org
> > Subject: Re: MKLDNN dynamically linked
> >
> > I think we should bias towards static linking.  It should make using
> mxnet
> > easier in a lot of cases for users.  As long as the license permits
> static linking
> > (i.e. is non-gpl) I'd +1 static linking for portability and ease of
> use.  The only
> > caveat would be in cases where the package size would cause grief for
> PyPi
> > maintainers.
> >
> > On Thu, Nov 8, 2018, 3:54 PM Sheng Zha  >
> > > +1. Ideally, MKLDNN can be statically linked. mxnet-mkl relies on Make
> > > +for
> > > building it so help is wanted on mxnet.
> > >
> > > -sz
> > >
> > > On 2018/11/08 21:28:50, Alex Zai  wrote:
> > > > Currently in mxnet-mkl the libmxnet.so is dynamically linked to to
> > > > libmkldnn.so.0. This is known to cause some issues if the wrong
> > > > version
> > > of
> > > > mkldnn is linked. Can we static link this file instead?
> > > >
> > > > Alex
> > > >
> > >
>

Re: Up-streaming MXNet HIP Port

[Karnam, Srihari]

Dear team,


Please review this and feedback:


https://cwiki.apache.org/confluence/display/MXNET/Upstreaming+of+Mxnet+HIP+port


Regards


From: Pedro Larroy 
Sent: Wednesday, October 24, 2018 5:38 PM
To: dev@mxnet.incubator.apache.org
Subject: Re: Up-streaming MXNet HIP Port

Hi Srihari

Thanks for the document. We could add it to the relevant section in the
wiki so it's easier to keep track whenever you feel comfortable with it.
https://cwiki.apache.org/confluence/display/MXNET/Design+Proposals

The calls to synchronize and wait looks very similar. Shall we use
polymorphism or a bridge pattern to abstract this common calls instead of
using the preprocessor? both seem to use the same abstraction (streams).
Using the suggested pattern instead of preprocessor would lead to code that
is easier to maintain and instrument. A shortcoming would be if the APIs to
abstract would be too different.

Pedro.

On Wed, Oct 24, 2018 at 6:13 AM Karnam, Srihari 
wrote:

> Dear All,
>
>
> Please review the design for Up-Streaming MXNet HIP Port.
>
>
>
> https://docs.google.com/document/d/1uGr1KPVDqDVUwnhM0vtmxkZZpE2Mf9slNF9e2IbwVj0/edit?usp=sharing
>
>
> Regards,
>
> Srihari Karnam
>

Re: Map OpenCV assertions to mxnet::Error

[Anirudh]

Hi Lieven,

Thanks a lot for this proposal and welcome to the community ! Apologies for
the delay in the reply.
I think it is a nice proposal and opencv exceptions are good point to start
from.
Would you be able to add the proposal to a new cwiki or add the proposal to
the existing cwiki that you linked.
I suggest you add your new error struct to io.h. Also, I dont think for the
proposal, you would need to make any frontend changes.

Would you also be willing to add a phase 2 for the proposal which addresses
the following:

1. How will these errors be propagated to the frontend ? We need to have a
mapping of error codes from backend to frontend to communicate what kind of
exception it is.
2. Handling of std::exception.

Anirudh



On Sun, Nov 4, 2018 at 2:54 AM Lieven Govaerts  wrote:

> Hi MXNet devs,
>
>
> I'd like some feedback on the following proposal before I start
> implementing it.
>
> Context:
> I am working on migrating a classification product currently using Caffe to
> MXNet. Along the way I'm encountering some issues loading and augmenting
> the images dataset.
>
> Basically it seems my dataset contains some technically invalid images.
> When loading them using mx.io.ImageRecordIter (from a Python script), they
> get passed eventually to the OpenCV library which will throw a C++
> exception. MXNet currently doesn't capture those, resulting in my script
> aborting with a not very clear error message:
>
> "
> terminate called after throwing an instance of 'cv::Exception'
>
>   what():  OpenCV(3.4.3)
> /home/lgo/dev/opencv-3.4.3/modules/imgproc/src/resize.cpp:4044: error:
> (-215:Assertion failed) !ssize.empty() in function 'resize'
>
> Aborted (core dumped)
> "
>
> These type of issues have been reported before and I see a high level
> action plan has been documented in the wiki:
>
> https://cwiki.apache.org/confluence/display/MXNET/Improved+Exception+Handling+in+MXNet+-+Phase+2
>
> See also my previous pull request, which prevents OpenCV assertions by
> re-implementing the same checks in MXNet code:
> https://github.com/apache/incubator-mxnet/pull/12999
>
>
> As I'm focused now on data loading and OpenCV, I would like to propose the
> following implementation steps:
> 1. Catch cv:exception in all calls to OpenCV functions that can raise one
> (cv::resize, cv::imdecode, cv::addWeighted, cv::mean, cv::copyMakeBorder,
> cv::warpAffine ..)
> => a new macro CHECK_CV_NO_ASSERT
>
> 2. Create a new mxnet::Error class for OpenCV exceptions. Map the
> cv::exception fields to this new Error class: code, err, file, func, line,
> msg, what.
> Make the CHECK_CV_NO_ASSERT macro throw this new mxnet::Error.
> => struct OpenCVError: public dmlc::Error
>
> 3. Add unit tests where possible.
>
> Scope: There are many calls to OpenCV function in different parts of the
> MXNet code. I plan to focus on:
> - src/io/image_*
> - src/ndarray/ndarray.cc
> - plugin/opencv/cv_api.cc
>
> The other modules (R-package, cpp-package, example, julia, tools,
> plugin/sframe) are related to programming languages I don't use. The sframe
> plugin is not documented at all so it's not clear what it does (or why
> you'd keep it in the repo).
>
> Is include/mxnet/base.h a good place to define the new macro and Error
> struct? I'm not sure which include file is visible in all places where
> OpenCV calls are currently used.
>
> Some assumptions:
> - The public API may contain references to 3rd party library OpenCV
> - There is some value in knowing if an Error is the result of a call to the
> OpenCV library. If not, I might as well wrap std::Exception in a more
> generic way.
>
> If I just make these changes the main process will still abort, but now at
> least with a clear error message + stack trace(*). Updating all processing
> codes to handle OpenCVError's correctly is a next step, outside the scope
> of this proposal.
>
> regards,
>
> Lieven
>
>
> (*) Example stack trace:
>
> [23:31:30] src/io/iter_image_recordio_2.cc:172: ImageRecordIOParser2:
> ./train.txt.rec, use 1 threads for decoding..
>
> [23:31:34] src/io/iter_image_recordio_2.cc:172: ImageRecordIOParser2:
> ./val.txt.rec, use 1 threads for decoding..
>
> Traceback (most recent call last):
>
>   File "./test_train_carmodel_resnet.py", line 126, in 
>
> for i, batch in enumerate(train_data):
>
>   File "/home/lgo/dev/incubator-mxnet/python/mxnet/io/io.py", line 228, in
> __next__
>
> return self.next()
>
>   File "/home/lgo/dev/incubator-mxnet/python/mxnet/io/io.py", line 856, in
> next
>
> check_call(_LIB.MXDataIterNext(self.handle, ctypes.byref(next_res)))
>
>   File "/home/lgo/dev/incubator-mxnet/python/mxnet/base.py", line 252, in
> check_call
>
> raise MXNetError(py_str(_LIB.MXGetLastError()))
>
> mxnet.base.MXNetError: [23:31:34] src/io/image_aug_default.cc:413: OpenCV
> exception caught:
>
> OpenCV(3.4.3)
> /home/lgo/dev/opencv-3.4.3/modules/imgproc/src/resize.cpp:4044: error:
> (-215:Assertion failed) !ssize.empty() in function 'resize'
>
>
>
> Stack 

Re: Run Sphinx checks on MXNet CI

[Aaron Markham]

Hi Anirudh,

Once the existing errors in docs building are cleaned up, I'm all for
having CI bubble up a build break when docs are broken by a PR. That
way we're keeping things up to date and not letting a minor bug turn
into a serious issue for the entire API documentation. One break
causes a ripple effect that can go unnoticed and then trying to find
it is like a needle in a haystack when there are already thousands of
warnings or errors that are being ignored.

We now have several docs troubleshooting tips in a documentation guide
thanks to the contributions of @frankfliu, @Roshrini, @vandanavk,
@vdantu, @vrakesh, and @zachgk.

This documentation guide is published on the developer cwiki:
https://cwiki.apache.org/confluence/display/MXNET/Documentation+Guide

I plan to continue to add to this guide as more PRs come in that
exhibit new ways of handling errors or warnings. That way, creating
docs and troubleshooting any build issues will be much easier.

Please let me know if you have any questions or feedback. You can
always add that directly to the wiki too.

Cheers,
Aaron


On Thu, Nov 8, 2018 at 11:21 AM Anirudh Acharya  wrote:
>
> Hi,
>
> Recently there was a barrage of issues related to documentation that was
> raised here -
> https://github.com/apache/incubator-mxnet/issues/created_by/aaronmarkham
> All the issues are related to Sphinx errors and warnings. These errors
> often lead to broken documentation. Ideally such errors should be caught
> before a PR gets merged, on the CI.
>
> Since we use Sphinx to generate the documentation for MXNet, can we have
> the CI run Sphinx tests on every PR so that we can preempt the problem of
> broken documentation.
>
> Any thoughts from the community? What might be involved to make this change
> to the CI?
>
>
> Regards
> Anirudh Acharya

Re: LabelBot New Design in Production

[Naveen Swamy]

Great job!, this is very helpful to triage issues!, users when creating a
new Issue could themselves tag the issues. May be we should add that to the
issue template?

On Thu, Nov 8, 2018 at 3:54 PM Harsh Patel 
wrote:

> Hey all,
> The upgraded label bot has been pushed into production. Current
> functionality includes
> add, delete, and update.
> (i.e. @mxnet-label-bot add ['label']
> @mxnet-label-bot remove ['label']
> @mxnet-label-bot update ['label'])
>
> Users should feel free to leave suggestions and any potential issues. The
> forum to this best would be here:
> https://github.com/apache/incubator-mxnet/issues/13163
>
> Best,
> -Harsh Patel
>

LabelBot New Design in Production

[Harsh Patel]

Hey all,
The upgraded label bot has been pushed into production. Current
functionality includes
add, delete, and update.
(i.e. @mxnet-label-bot add ['label']
@mxnet-label-bot remove ['label']
@mxnet-label-bot update ['label'])

Users should feel free to leave suggestions and any potential issues. The
forum to this best would be here:
https://github.com/apache/incubator-mxnet/issues/13163

Best,
-Harsh Patel

Catch divide-by-zero floating number exception in backend

[Lin Yuan]

Dear MXNet Community,

I recently found the NaN errors sometimes could be due to some
divide-by-zero float number bugs in engine backend. However, by default,
such an exception will not be thrown. I added a signal trap to catch this
error (https://github.com/apache/incubator-mxnet/pull/13190) and caught a
few exceptions when running the python unit test. But this only works for
Linux OS.

I would like to get more feedback on the best practice to catch such bugs
in the code and if we should enforce such checks in CI. Any comment is
appreciated.

Best Regards,

Lin

Re: MKLDNN dynamically linked

[kellen sunderland]

I think we should bias towards static linking.  It should make using mxnet
easier in a lot of cases for users.  As long as the license permits static
linking (i.e. is non-gpl) I'd +1 static linking for portability and ease of
use.  The only caveat would be in cases where the package size would cause
grief for PyPi maintainers.

On Thu, Nov 8, 2018, 3:54 PM Sheng Zha  +1. Ideally, MKLDNN can be statically linked. mxnet-mkl relies on Make for
> building it so help is wanted on mxnet.
>
> -sz
>
> On 2018/11/08 21:28:50, Alex Zai  wrote:
> > Currently in mxnet-mkl the libmxnet.so is dynamically linked to to
> > libmkldnn.so.0. This is known to cause some issues if the wrong version
> of
> > mkldnn is linked. Can we static link this file instead?
> >
> > Alex
> >
>

Re: MKLDNN dynamically linked

[Sheng Zha]

+1. Ideally, MKLDNN can be statically linked. mxnet-mkl relies on Make for 
building it so help is wanted on mxnet.

-sz

On 2018/11/08 21:28:50, Alex Zai  wrote: 
> Currently in mxnet-mkl the libmxnet.so is dynamically linked to to
> libmkldnn.so.0. This is known to cause some issues if the wrong version of
> mkldnn is linked. Can we static link this file instead?
> 
> Alex
> 

Re: [VOTE] Separating PMC and Committership

[Qing Lan]

+1 (non-binding)

On 11/8/18, 2:41 PM, "kellen sunderland"  wrote:

+1 (non-binding)

On Thu, Nov 8, 2018 at 10:37 AM Thomas DELTEIL 
wrote:

> +1 (non-binding)
>
> Le jeu. 8 nov. 2018 à 10:04, Carin Meier  a écrit :
>
> > Reminder - Vote ends tomorrow-  Friday Nov 9th at 6:00 am EST
> >
> > On Mon, Nov 5, 2018 at 11:29 AM Carin Meier 
> wrote:
> >
> > > This is a procedural vote on whether to separate the committer and 
PPMC
> > > levels in the project. The current state is that a user is considered
> as
> > > both a committer and a PPMC member at the same time. This vote is to
> > change
> > > that to be able to invite a person in as a committer separately from a
> > PPMC
> > > member.
> > >
> > > Document reference:
> > >
> >
> 
https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
> > >
> > > Discussion thread:
> > >
> >
> 
https://lists.apache.org/thread.html/9c6ecda02e081aa6b689c92badc9dcf05ced6fb3691fd370471773d1@%3Cdev.mxnet.apache.org%3E
> > >
> > > The vote will be a procedural issue vote as defined
> > > https://www.apache.org/foundation/voting.html
> > >
> > > Votes on procedural issues follow the common format of majority rule
> > unless
> > > otherwise stated. That is, if there are more favourable votes than
> > > unfavourable ones, the issue is considered to have passed -- 
regardless
> > of
> > > the number of votes in each category. (If the number of votes seems 
too
> > > small to be representative of a community consensus, the issue is
> > typically
> > > not pursued. However, see the description of lazy consensus
> > >  for a
> > > modifying factor.)
> > >
> > > The vote will run until Friday Nov 9th at 6:00 am EST
> > >
> > > Thanks,
> > > Carin
> > >
> > >
> > >
> >
>

Re: [VOTE] Separating PMC and Committership

[kellen sunderland]

+1 (non-binding)

On Thu, Nov 8, 2018 at 10:37 AM Thomas DELTEIL 
wrote:

> +1 (non-binding)
>
> Le jeu. 8 nov. 2018 à 10:04, Carin Meier  a écrit :
>
> > Reminder - Vote ends tomorrow-  Friday Nov 9th at 6:00 am EST
> >
> > On Mon, Nov 5, 2018 at 11:29 AM Carin Meier 
> wrote:
> >
> > > This is a procedural vote on whether to separate the committer and PPMC
> > > levels in the project. The current state is that a user is considered
> as
> > > both a committer and a PPMC member at the same time. This vote is to
> > change
> > > that to be able to invite a person in as a committer separately from a
> > PPMC
> > > member.
> > >
> > > Document reference:
> > >
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
> > >
> > > Discussion thread:
> > >
> >
> https://lists.apache.org/thread.html/9c6ecda02e081aa6b689c92badc9dcf05ced6fb3691fd370471773d1@%3Cdev.mxnet.apache.org%3E
> > >
> > > The vote will be a procedural issue vote as defined
> > > https://www.apache.org/foundation/voting.html
> > >
> > > Votes on procedural issues follow the common format of majority rule
> > unless
> > > otherwise stated. That is, if there are more favourable votes than
> > > unfavourable ones, the issue is considered to have passed -- regardless
> > of
> > > the number of votes in each category. (If the number of votes seems too
> > > small to be representative of a community consensus, the issue is
> > typically
> > > not pursued. However, see the description of lazy consensus
> > >  for a
> > > modifying factor.)
> > >
> > > The vote will run until Friday Nov 9th at 6:00 am EST
> > >
> > > Thanks,
> > > Carin
> > >
> > >
> > >
> >
>

MKLDNN dynamically linked

[Alex Zai]

Currently in mxnet-mkl the libmxnet.so is dynamically linked to to
libmkldnn.so.0. This is known to cause some issues if the wrong version of
mkldnn is linked. Can we static link this file instead?

Alex

Re: [Announce] Upcoming Apache MXNet (incubating) 1.3.1 patch release

[Naveen Swamy]

Anton, I don't think we need to add the Mac OS tests for 1.3.1 branch since
travis CI is timing out and creates blockers, it also did not exist for
v1.3.0.


On Thu, Nov 8, 2018 at 10:04 AM Anton Chernov  wrote:

> A PR to fix the tests:
>
> Remove test for non existing index copy operator (v1.3.x)
> https://github.com/apache/incubator-mxnet/pull/13180
>
>
> Best
> Anton
>
> чт, 8 нояб. 2018 г. в 10:05, Anton Chernov :
>
> > An addition has been made to include MacOS tests for the v1.3.x branch:
> >
> > [MXNET-908] Enable minimal OSX Travis build (v1.3.x)
> > https://github.com/apache/incubator-mxnet/pull/13179
> >
> > It includes following PR's for master:
> >
> > [MXNET-908] Enable minimal OSX Travis build
> > https://github.com/apache/incubator-mxnet/pull/12462
> >
> > [MXNET-908] Enable python tests in Travis
> > https://github.com/apache/incubator-mxnet/pull/12550
> >
> > [MXNET-968] Fix MacOS python tests
> > https://github.com/apache/incubator-mxnet/pull/12590
> >
> >
> > Best
> > Anton
> >
> >
> > чт, 8 нояб. 2018 г. в 9:38, Anton Chernov :
> >
> >> Thank you everyone for your support and suggestions. All proposed PR's
> >> have been merged. We will tag the release candidate and start the vote
> on
> >> Friday, the 9th of November 2018.
> >>
> >> Unfortunately after the merges the tests started to fail:
> >>
> >> http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-mxnet/job/v1.3.x/
> >>
> >> I will look into the failures, but any help as usual is very
> appreciated.
> >>
> >> The nightly tests are fine:
> >> http://jenkins.mxnet-ci.amazon-ml.com/job/NightlyTests/job/v1.3.x/
> >>
> >>
> >> Best
> >> Anton
> >>
> >>
> >>
> >>
> >> ср, 7 нояб. 2018 г. в 17:19, Anton Chernov :
> >>
> >>> Yes, you are right about the versions wording, thanks for
> clarification.
> >>>
> >>> A performance improvement can be considered a bugfix as well. I see no
> >>> big risks in including PR's by Haibin and Lin into the patch release.
> >>>
> >>> @Haibin, if you can reopen the PR's they should be good to go for the
> >>> relase, considering the importance of the improvements.
> >>>
> >>> I propose the following bugfixes for the release as well (already
> >>> created corresponding PR's):
> >>>
> >>> Fixed __setattr__ method of _MXClassPropertyMetaClass (v1.3.x)
> >>> https://github.com/apache/incubator-mxnet/pull/13157
> >>>
> >>> fixed symbols naming in RNNCell, LSTMCell, GRUCell (v1.3.x)
> >>> https://github.com/apache/incubator-mxnet/pull/13158
> >>>
> >>> We will be starting to merge the PR's shortly. If are no more proposals
> >>> for backporting I would consider the list as set.
> >>>
> >>> Best
> >>> Anton
> >>>
> >>> ср, 7 нояб. 2018 г. в 17:01, Sheng Zha :
> >>>
>  Hi Anton,
> 
>  I hear your concern about a simultaneous 1.4.0 release and it
> certainly
>  is a valid one.
> 
>  Regarding the release, let’s agree on the language first. According to
>  semver.org, 1.3.1 release is considered patch release, which is for
>  backward compatible bug fixes, while 1.4.0 release is considered minor
>  release, which is for backward compatible new features. A major
> release
>  would mean 2.0.
> 
>  The three PRs suggested by Haibin and Lin are all introducing new
>  features. If they go into a patch release, it would require an
> exception
>  accepted by the community. Also, if other violation happens it could
> be
>  ground for declining a release during votes.
> 
>  -sz
> 
>  > On Nov 7, 2018, at 2:25 AM, Anton Chernov 
>  wrote:
>  >
>  > [MXNET-1179] Enforce deterministic algorithms in convolution layers
> 
> >>>
>

Run Sphinx checks on MXNet CI

[Anirudh Acharya]

Hi,

Recently there was a barrage of issues related to documentation that was
raised here -
https://github.com/apache/incubator-mxnet/issues/created_by/aaronmarkham
All the issues are related to Sphinx errors and warnings. These errors
often lead to broken documentation. Ideally such errors should be caught
before a PR gets merged, on the CI.

Since we use Sphinx to generate the documentation for MXNet, can we have
the CI run Sphinx tests on every PR so that we can preempt the problem of
broken documentation.

Any thoughts from the community? What might be involved to make this change
to the CI?


Regards
Anirudh Acharya

Re: [VOTE] Separating PMC and Committership

[Thomas DELTEIL]

+1 (non-binding)

Le jeu. 8 nov. 2018 à 10:04, Carin Meier  a écrit :

> Reminder - Vote ends tomorrow-  Friday Nov 9th at 6:00 am EST
>
> On Mon, Nov 5, 2018 at 11:29 AM Carin Meier  wrote:
>
> > This is a procedural vote on whether to separate the committer and PPMC
> > levels in the project. The current state is that a user is considered as
> > both a committer and a PPMC member at the same time. This vote is to
> change
> > that to be able to invite a person in as a committer separately from a
> PPMC
> > member.
> >
> > Document reference:
> >
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
> >
> > Discussion thread:
> >
> https://lists.apache.org/thread.html/9c6ecda02e081aa6b689c92badc9dcf05ced6fb3691fd370471773d1@%3Cdev.mxnet.apache.org%3E
> >
> > The vote will be a procedural issue vote as defined
> > https://www.apache.org/foundation/voting.html
> >
> > Votes on procedural issues follow the common format of majority rule
> unless
> > otherwise stated. That is, if there are more favourable votes than
> > unfavourable ones, the issue is considered to have passed -- regardless
> of
> > the number of votes in each category. (If the number of votes seems too
> > small to be representative of a community consensus, the issue is
> typically
> > not pursued. However, see the description of lazy consensus
> >  for a
> > modifying factor.)
> >
> > The vote will run until Friday Nov 9th at 6:00 am EST
> >
> > Thanks,
> > Carin
> >
> >
> >
>

Re: [Announce] Upcoming Apache MXNet (incubating) 1.3.1 patch release

[Anton Chernov]

Thank you everyone for your support and suggestions. All proposed PR's have
been merged. We will tag the release candidate and start the vote on
Friday, the 9th of November 2018.

Unfortunately after the merges the tests started to fail:

http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-mxnet/job/v1.3.x/

I will look into the failures, but any help as usual is very appreciated.

The nightly tests are fine:
http://jenkins.mxnet-ci.amazon-ml.com/job/NightlyTests/job/v1.3.x/


Best
Anton




ср, 7 нояб. 2018 г. в 17:19, Anton Chernov :

> Yes, you are right about the versions wording, thanks for clarification.
>
> A performance improvement can be considered a bugfix as well. I see no big
> risks in including PR's by Haibin and Lin into the patch release.
>
> @Haibin, if you can reopen the PR's they should be good to go for the
> relase, considering the importance of the improvements.
>
> I propose the following bugfixes for the release as well (already created
> corresponding PR's):
>
> Fixed __setattr__ method of _MXClassPropertyMetaClass (v1.3.x)
> https://github.com/apache/incubator-mxnet/pull/13157
>
> fixed symbols naming in RNNCell, LSTMCell, GRUCell (v1.3.x)
> https://github.com/apache/incubator-mxnet/pull/13158
>
> We will be starting to merge the PR's shortly. If are no more proposals
> for backporting I would consider the list as set.
>
> Best
> Anton
>
> ср, 7 нояб. 2018 г. в 17:01, Sheng Zha :
>
>> Hi Anton,
>>
>> I hear your concern about a simultaneous 1.4.0 release and it certainly
>> is a valid one.
>>
>> Regarding the release, let’s agree on the language first. According to
>> semver.org, 1.3.1 release is considered patch release, which is for
>> backward compatible bug fixes, while 1.4.0 release is considered minor
>> release, which is for backward compatible new features. A major release
>> would mean 2.0.
>>
>> The three PRs suggested by Haibin and Lin are all introducing new
>> features. If they go into a patch release, it would require an exception
>> accepted by the community. Also, if other violation happens it could be
>> ground for declining a release during votes.
>>
>> -sz
>>
>> > On Nov 7, 2018, at 2:25 AM, Anton Chernov  wrote:
>> >
>> > [MXNET-1179] Enforce deterministic algorithms in convolution layers
>>
>

Re: Requesting access for SLACK

[Hagay Lupesko]

Invite sent Gaurav!

On Wed, Nov 7, 2018 at 1:33 PM Gaurav Gireesh 
wrote:

> Hi!
> I would like to request access to the Slack channel for MXNet.
>
> Thanks and regards,
> Gaurav Gireesh
>

Re: [Announce] Upcoming Apache MXNet (incubating) 1.3.1 patch release

[Anton Chernov]

A PR to fix the tests:

Remove test for non existing index copy operator (v1.3.x)
https://github.com/apache/incubator-mxnet/pull/13180


Best
Anton

чт, 8 нояб. 2018 г. в 10:05, Anton Chernov :

> An addition has been made to include MacOS tests for the v1.3.x branch:
>
> [MXNET-908] Enable minimal OSX Travis build (v1.3.x)
> https://github.com/apache/incubator-mxnet/pull/13179
>
> It includes following PR's for master:
>
> [MXNET-908] Enable minimal OSX Travis build
> https://github.com/apache/incubator-mxnet/pull/12462
>
> [MXNET-908] Enable python tests in Travis
> https://github.com/apache/incubator-mxnet/pull/12550
>
> [MXNET-968] Fix MacOS python tests
> https://github.com/apache/incubator-mxnet/pull/12590
>
>
> Best
> Anton
>
>
> чт, 8 нояб. 2018 г. в 9:38, Anton Chernov :
>
>> Thank you everyone for your support and suggestions. All proposed PR's
>> have been merged. We will tag the release candidate and start the vote on
>> Friday, the 9th of November 2018.
>>
>> Unfortunately after the merges the tests started to fail:
>>
>> http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-mxnet/job/v1.3.x/
>>
>> I will look into the failures, but any help as usual is very appreciated.
>>
>> The nightly tests are fine:
>> http://jenkins.mxnet-ci.amazon-ml.com/job/NightlyTests/job/v1.3.x/
>>
>>
>> Best
>> Anton
>>
>>
>>
>>
>> ср, 7 нояб. 2018 г. в 17:19, Anton Chernov :
>>
>>> Yes, you are right about the versions wording, thanks for clarification.
>>>
>>> A performance improvement can be considered a bugfix as well. I see no
>>> big risks in including PR's by Haibin and Lin into the patch release.
>>>
>>> @Haibin, if you can reopen the PR's they should be good to go for the
>>> relase, considering the importance of the improvements.
>>>
>>> I propose the following bugfixes for the release as well (already
>>> created corresponding PR's):
>>>
>>> Fixed __setattr__ method of _MXClassPropertyMetaClass (v1.3.x)
>>> https://github.com/apache/incubator-mxnet/pull/13157
>>>
>>> fixed symbols naming in RNNCell, LSTMCell, GRUCell (v1.3.x)
>>> https://github.com/apache/incubator-mxnet/pull/13158
>>>
>>> We will be starting to merge the PR's shortly. If are no more proposals
>>> for backporting I would consider the list as set.
>>>
>>> Best
>>> Anton
>>>
>>> ср, 7 нояб. 2018 г. в 17:01, Sheng Zha :
>>>
 Hi Anton,

 I hear your concern about a simultaneous 1.4.0 release and it certainly
 is a valid one.

 Regarding the release, let’s agree on the language first. According to
 semver.org, 1.3.1 release is considered patch release, which is for
 backward compatible bug fixes, while 1.4.0 release is considered minor
 release, which is for backward compatible new features. A major release
 would mean 2.0.

 The three PRs suggested by Haibin and Lin are all introducing new
 features. If they go into a patch release, it would require an exception
 accepted by the community. Also, if other violation happens it could be
 ground for declining a release during votes.

 -sz

 > On Nov 7, 2018, at 2:25 AM, Anton Chernov 
 wrote:
 >
 > [MXNET-1179] Enforce deterministic algorithms in convolution layers

>>>

Re: [VOTE] Separating PMC and Committership

[Carin Meier]

Reminder - Vote ends tomorrow-  Friday Nov 9th at 6:00 am EST

On Mon, Nov 5, 2018 at 11:29 AM Carin Meier  wrote:

> This is a procedural vote on whether to separate the committer and PPMC
> levels in the project. The current state is that a user is considered as
> both a committer and a PPMC member at the same time. This vote is to change
> that to be able to invite a person in as a committer separately from a PPMC
> member.
>
> Document reference:
> https://cwiki.apache.org/confluence/display/MXNET/Become+an+Apache+MXNet+%28incubating%29+Committer+and+PPMC+Member
>
> Discussion thread:
> https://lists.apache.org/thread.html/9c6ecda02e081aa6b689c92badc9dcf05ced6fb3691fd370471773d1@%3Cdev.mxnet.apache.org%3E
>
> The vote will be a procedural issue vote as defined
> https://www.apache.org/foundation/voting.html
>
> Votes on procedural issues follow the common format of majority rule unless
> otherwise stated. That is, if there are more favourable votes than
> unfavourable ones, the issue is considered to have passed -- regardless of
> the number of votes in each category. (If the number of votes seems too
> small to be representative of a community consensus, the issue is typically
> not pursued. However, see the description of lazy consensus
>  for a
> modifying factor.)
>
> The vote will run until Friday Nov 9th at 6:00 am EST
>
> Thanks,
> Carin
>
>
>

Re: [Announce] Upcoming Apache MXNet (incubating) 1.3.1 patch release

[Anton Chernov]

An addition has been made to include MacOS tests for the v1.3.x branch:

[MXNET-908] Enable minimal OSX Travis build (v1.3.x)
https://github.com/apache/incubator-mxnet/pull/13179

It includes following PR's for master:

[MXNET-908] Enable minimal OSX Travis build
https://github.com/apache/incubator-mxnet/pull/12462

[MXNET-908] Enable python tests in Travis
https://github.com/apache/incubator-mxnet/pull/12550

[MXNET-968] Fix MacOS python tests
https://github.com/apache/incubator-mxnet/pull/12590


Best
Anton


чт, 8 нояб. 2018 г. в 9:38, Anton Chernov :

> Thank you everyone for your support and suggestions. All proposed PR's
> have been merged. We will tag the release candidate and start the vote on
> Friday, the 9th of November 2018.
>
> Unfortunately after the merges the tests started to fail:
>
> http://jenkins.mxnet-ci.amazon-ml.com/job/incubator-mxnet/job/v1.3.x/
>
> I will look into the failures, but any help as usual is very appreciated.
>
> The nightly tests are fine:
> http://jenkins.mxnet-ci.amazon-ml.com/job/NightlyTests/job/v1.3.x/
>
>
> Best
> Anton
>
>
>
>
> ср, 7 нояб. 2018 г. в 17:19, Anton Chernov :
>
>> Yes, you are right about the versions wording, thanks for clarification.
>>
>> A performance improvement can be considered a bugfix as well. I see no
>> big risks in including PR's by Haibin and Lin into the patch release.
>>
>> @Haibin, if you can reopen the PR's they should be good to go for the
>> relase, considering the importance of the improvements.
>>
>> I propose the following bugfixes for the release as well (already created
>> corresponding PR's):
>>
>> Fixed __setattr__ method of _MXClassPropertyMetaClass (v1.3.x)
>> https://github.com/apache/incubator-mxnet/pull/13157
>>
>> fixed symbols naming in RNNCell, LSTMCell, GRUCell (v1.3.x)
>> https://github.com/apache/incubator-mxnet/pull/13158
>>
>> We will be starting to merge the PR's shortly. If are no more proposals
>> for backporting I would consider the list as set.
>>
>> Best
>> Anton
>>
>> ср, 7 нояб. 2018 г. в 17:01, Sheng Zha :
>>
>>> Hi Anton,
>>>
>>> I hear your concern about a simultaneous 1.4.0 release and it certainly
>>> is a valid one.
>>>
>>> Regarding the release, let’s agree on the language first. According to
>>> semver.org, 1.3.1 release is considered patch release, which is for
>>> backward compatible bug fixes, while 1.4.0 release is considered minor
>>> release, which is for backward compatible new features. A major release
>>> would mean 2.0.
>>>
>>> The three PRs suggested by Haibin and Lin are all introducing new
>>> features. If they go into a patch release, it would require an exception
>>> accepted by the community. Also, if other violation happens it could be
>>> ground for declining a release during votes.
>>>
>>> -sz
>>>
>>> > On Nov 7, 2018, at 2:25 AM, Anton Chernov  wrote:
>>> >
>>> > [MXNET-1179] Enforce deterministic algorithms in convolution layers
>>>
>>