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.li...@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 <zhash...@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.li...@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. > > >
