Zach,
If you are willing and able to do that on behalf of Amazon, that would be
great.
-Carin
On Fri, May 29, 2020 at 8:35 PM Zach Kimberg
wrote:
> If we replace the official CPU build, won't there still be new dependencies
> so it is not even guaranteed to work depending on whether the user h
If we replace the official CPU build, won't there still be new dependencies
so it is not even guaranteed to work depending on whether the user has the
dependencies (e.g. libgfortran) installed? I think there is also a
performance degradation if we remove mkl.
But, we could still have a third-party
Thanks. I understand now. If all the current jars are not compliant, then
they should be removed.
I also don't like the idea of "replacing" a jar on maven with another jar.
It sounds like we can consider publishing cpu jars only going forward for a
new release.
- Carin
On Fri, May 29, 2020 at 1:3
On Fri, 2020-05-29 at 12:15 -0400, Carin Meier wrote:
>
> Going forward - we with future releases, we can have all users build their
> own packages, just for the existing ones that are compliant on maven.
>
> On Fri, May 29, 2020 at 12:14 PM Carin Meier wrote:
>
> > Leonard,
> >
> > Is this #2
Going forward - we with future releases, we can have all users build their
own packages, just for the existing ones that are compliant on maven.
On Fri, May 29, 2020 at 12:14 PM Carin Meier wrote:
> Leonard,
>
> Is this #2 Option still on the table?
>
> 2) Ask the Infra team to delete all MXNet
Leonard,
Is this #2 Option still on the table?
2) Ask the Infra team to delete all MXNet GPU releases on
> repository.apache.org and provide replacement releases without
libgfortran.so
> and other potentially Category-X files (I found libmkl_ml.so in one of the
> JARs..)
It seems like it would
Ok, so let's restart the lazy consensus on the removal of the Maven artifacts.
As there were concerns that this is to rushed, let's make it a 168 hour (7 day)
lazy consenus. I'm happy to cancel it again if anyone has a better idea and
ressources to implement it.
Just to clarify, similar to the Pyp
Thanks for your input Carin.
In that case, I'll take back my -1 and feel free to proceed.
-Marco
Carin Meier schrieb am Mi., 27. Mai 2020, 14:53:
> Leonard,
>
> Thank you for putting the pull request together. Unfortunately, I don't
> have any bandwidth to assist with any JVM activities right
Leonard,
Thank you for putting the pull request together. Unfortunately, I don't
have any bandwidth to assist with any JVM activities right now, so I will
defer to those that are have time and are willing to put in the dev effort.
However, I will give my opinion that having a jar load and then fa
Hi Marco,
thank you for explaining your reasoning. Thus let's cancel the lazy consensus.
I think we're all aware of the impact of this problem you mention and I too am
concerned about it. But, please note that this discussion has been ongoing for
14 days and there has been no proposal for mitigat
Hi,
I'm upholding my -1 until a clear path to communicate and handle the change
has been provided paired with assessment to mitigate potentially caused
damage.
I understand that we're required to remove the releases since they should
not have been there in the first place. But what you're suggest
@Carin I created https://github.com/apache/incubator-mxnet/pull/18410 to update
the documentation.
@Marco The replacement is to build from source. But I'm afraid that there's
nothing to -1 here, as the existing convenience binaries are in violation of ASF
policy and the ASF board has requested the
Do we offer any replacement for those deletions or will be break stuff
then?
If we break anything, I'd -1 until we found a way moving forward to ensure
uninterrupted service.
On Tue, May 26, 2020 at 7:51 PM Carin Meier wrote:
> Does anyone have any bandwidth to update installation documentation
Does anyone have any bandwidth to update installation documentation on the
website, so it doesn't refer them to install it from maven?
Here are the links to the gpu instructions for Scala, Java, and Clojure.
The cpu ones will also need to be updated if also removed.
https://mxnet.apache.org/get_st
On Fri, 2020-05-08 at 20:49 +, Lausen, Leonard wrote:
> I see the following two potential remedies:
>
> 1) Ask the Infra team to delete all MXNet releases on repository.apache.org
>
> 2) Ask the Infra team to delete all MXNet GPU releases on
> repository.apache.org and provide replacement rel
15 matches
Mail list logo
