I have to agree that the DMLC subrepos do make the development much more
difficult sometimes.
On 5/2/18, 3:57 AM, "Pedro Larroy" wrote:
For me the situation with DMLC is problematic.
I often find myself having to fix things in the DMLC subrepos.
* These changes are imposs
Totally agree with Henry and Pedro.
On Wed, May 2, 2018 at 12:56 PM, Pedro Larroy
wrote:
> For me the situation with DMLC is problematic.
>
> I often find myself having to fix things in the DMLC subrepos.
>
> * These changes are impossible to test with the MXNet CI system without
> doing shenani
For me the situation with DMLC is problematic.
I often find myself having to fix things in the DMLC subrepos.
* These changes are impossible to test with the MXNet CI system without
doing shenanigans like changing the submodules to my own forks.
* Slows down development as fixes need to be merged
Naive question - How often does this happen? It should be rare that a
project needs to send a PR to a dependency, and much rarer that it blocks a
release.
It sounds like it’s too coupled a dependency. I suspect the DMLC code
situation is going to be a major blocker to any chance of graduating.
He
+1 on merging this "https://github.com/dmlc/mshadow/pull/319 "
I am curious how are we tracking the sub-modules's PRs which are really
important for MXNet?
This PR has been waiting to merge for almost 4 months.
On Mon, Apr 30, 2018 at 1:51 AM, Pedro Larroy
wrote:
> -1
>
> We should merge this
Thanks for raising this, Pedro. Taking a look now.
On Mon, Apr 30, 2018 at 1:51 AM, Pedro Larroy
wrote:
> -1
>
> We should merge this and update mshadow before the next release:
> https://github.com/dmlc/mshadow/pull/319 so we compile cuda for Volta.
>
> On Sat, Apr 28, 2018 at 12:53 AM, Steffe
-1
We should merge this and update mshadow before the next release:
https://github.com/dmlc/mshadow/pull/319 so we compile cuda for Volta.
On Sat, Apr 28, 2018 at 12:53 AM, Steffen Rochel
wrote:
> Hi Chris - acknowledge that building the docs is not as good as it should
> be and needs to be im
Hi Chris - acknowledge that building the docs is not as good as it should
be and needs to be improved. Is it worse compared to 1.1.0 release to
consider as release blocker?
On Fri, Apr 27, 2018 at 9:53 AM Chris Olivier wrote:
> -1
>
> Building the docs locally is an absolute nightmare. I haven
-1
Building the docs locally is an absolute nightmare. I haven;t been able to
get it to work yet.
On Thu, Apr 26, 2018 at 3:36 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:
> Hello,
>
> I'd like to request to pause this vote since I have identified an issue
> with our CMakeLists, br
Hello,
I'd like to request to pause this vote since I have identified an issue
with our CMakeLists, breaking all UNIX builds with the latest version
(3.11) of cmake. This issue is tracked at [1]. The PR to fix this is
available at [2].
Best regards,
Marco
[1]: https://github.com/apache/incubato
Thanks for reporting, Sheng. I am going to cancel the vote in a new thread
unless anyone has objections.
On Thu, Apr 26, 2018 at 3:05 PM, Sheng Zha wrote:
> -1 for the following reasons:
>
> 1. due to addition of support for fp16, the build breaks for windows and
> older version of osx (clang 8
-1 for the following reasons:
1. due to addition of support for fp16, the build breaks for windows and
older version of osx (clang 8 for example). fix is in
https://github.com/dmlc/mshadow/pull/333
2. due to addition of quantized fully connected op, cuda 7.5 build is
broken. Jun Wu is tracking th
Hi all,
As part of RC1 release, We have addressed the issue with respect to
asymmetric padding in ONNX Import module (
https://github.com/apache/incubator-mxnet/pull/10676).
We have also added existing silent failures for MXNet Conv and the
incompatibility in behavior for certain use cases between
13 matches
Mail list logo