Let's cancel this vote for now and move the OMP conversation to a
discuss thread as suggested here in order not to antagonize anyone.
Let's find the best solution, this is not about one upping anyone but
to gather facts and document what's going on.
Chris, would you be so kind to reopen the PR so
Good suggestion. I thought the issue was discussed at length but I
agree might be better to softly bring them to the list as a discuss
first instead of a direct vote. Will do so in the future.
Thanks.
On Tue, Jun 18, 2019 at 12:56 PM Tianqi Chen wrote:
>
> In a situation like this, I would sugg
+1 for doing a [discuss] thread.
Listing historic discussion threads/issues/prs on omp would be helpful as
well.
By the way, I suggest that we remain purely technical by discussing pros
and cons. Let’s not include others’ names in technical discussion.
Thanks,
Junru
On Tue, Jun 18, 2019 at 12:5
In a situation like this, I would suggest a DISCUSS thread is more proper
before the voting one.
As the tension can generally be high in a voting thread and it is hard to
make a technical decision without previous discussions and pros/cons being
listed.
Tianqi
On Fri, Jun 14, 2019 at 4:59 PM Pedr
I tried to have a vote to bring light and clarify a PR which was not
advancing and not handled well in my opinion. As I understand, and
indicated before here by Apache mentors, the mailing list is the main
communication medium and where votes and discussion happen, so my
understanding was that it s
+1
On Tue., 18 Jun. 2019, 12:20 pm Anton Chernov, wrote:
> I would like to cite Apache Glossary [1]:
>
> Veto
> According to the Apache methodology, a change which has been made or
> proposed may be made moot through the exercise of a veto by a committer to
> the codebase in question. If the R-T
I would like to cite Apache Glossary [1]:
Veto
According to the Apache methodology, a change which has been made or
proposed may be made moot through the exercise of a veto by a committer to
the codebase in question. If the R-T-C commit policy is in effect, a veto
prevents the change from being ma
Regarding your paste of ldd, not sure what's your point. This is the
output with the patch from PR applied, the openmp version used is the
one provided by MKL:
Version of the PR that removes openmp from 3rdparty comes from MKL:
linux-vdso.so.1 (0x7ffc4c993000)
libmkldnn.so.0
Thanks for your answer Chris. I'm not militant in regards to one
option or another nor belong of any club that will accept me as
member, but I think we should drive this to conclusion and understand
why we keep it or if we should remove it and use the platform provided
version. There are open issue
I am curious why you're being so militant troll about this. libomp is used
in every MKL build (download mxnet-mkl yourself and see). I don't see any
convincing reason to change it and so far as I can tell, no real issue has
been proven to be related. Anyway, I am reluctant to feed trolls any mor
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
Vetos stand until and unless withdrawn by their casters [1]. The only path
forward would be to convince the caster to withdraw the veto.
-sz
[1] https://www.apache.org/foundation/voting.html#Veto
On 2019/06/17 17:46:59, Pedro Larroy wrote:
> Thanks.
>
> How do we go on advancing this PR then
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 wrote:
>
> This vote is invalid as the original PR
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 wrote:
> Hi all
>
> This is a 5-day vote to act and wrap up an outstanding PR that removes
> linkage with multiple OpenMP from 3rdp
+1
This is a link to the benchmarks in the wiki:
https://cwiki.apache.org/confluence/display/MXNET/Benchmarking+MXNet+with+different+OpenMP+implementations
Pedro.
On Fri, Jun 14, 2019 at 4:59 PM Pedro Larroy
wrote:
>
> Hi all
>
> This is a 5-day vote to act and wrap up an outstanding PR that r
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/1216
16 matches
Mail list logo