mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Larroy <pedro.larroy.li...@gmail.com>
Subject Re: [VOTE] Remove conflicting OpenMP from CMake builds
Date Mon, 17 Jun 2019 17:57:48 GMT
I had read the "Apache Voting Process" guide here:
https://www.apache.org/foundation/voting.html  and I thought code
changes could be discussed on the mailing list in cases where the PR
is stuck or there's no response for a long time, also I understood
that -1's have to be justified.  Could you, or someone more familiar
which the Apache way enlighten on how to move this issue forward in a
constructive way?

Thanks a lot.

Pedro.

On Mon, Jun 17, 2019 at 10:46 AM Pedro Larroy
<pedro.larroy.lists@gmail.com> wrote:
>
> Thanks.
>
> How do we go on advancing this PR then? all the questions have been
> answered, performance numbers provided and more. Until how long can a
> veto stand? Also without replies to contributors.
>
> Pedro.
>
> On Fri, Jun 14, 2019 at 5:44 PM Sheng Zha <zhasheng@apache.org> wrote:
> >
> > This vote is invalid as the original PR has been vetoed by a committer. A vote on
dev@ won't help you circumvent a veto.
> >
> > -sz
> >
> > On 2019/06/14 23:59:33, Pedro Larroy <pedro.larroy.lists@gmail.com> wrote:
> > > Hi all
> > >
> > > This is a 5-day vote to act and wrap up an outstanding PR that removes
> > > linkage with multiple OpenMP from 3rdparty and uses the system
> > > provided one which might resolve a number of difficult to debug issues
> > > and possible undefined behaviour.
> > >
> > > https://github.com/apache/incubator-mxnet/pull/12160
> > >
> > > See the comments in the thread for more details but in short, linking
> > > with multiple openmp versions seems to lead to undefined behaviour,
> > > plus it would simplify not having to deal with a custom openmp version
> > > and rely on the platform provided one.
> > >
> > > This is expected to simplify builds and address a number of problems.
> > > Seems it doesn't cause any performance degradation, (the Gluon tests
> > > run almost 4x faster in my 64 core machine).
> > >
> > > There has been in depth study of performance implications by
> > > contributors like Stanislav Tsukrov and Anton Chernov.  All the
> > > concerns and comments from the reviewers have been addressed and we
> > > can't keep asking open ended questions to block PRs. Reviewers are
> > > expected to be proactive and responsive to contributors so we keep
> > > encouraging active contributors.
> > >
> > > please vote to merge this PR accordingly:
> > >
> > > +1 = approve
> > > +0 = no opinion
> > > -1 = disapprove (provide reason)
> > >
> > > If we observe regressions reported by any internal performance systems
> > > or by contributors the PR can be reverted easily. So it's not a one
> > > way door. But it will be useful to try this in master for a while.
> > >
> > > Thank you.
> > >
> > > Pedro.
> > >

Mime
View raw message