Thanks for your input Carin. In that case, I'll take back my -1 and feel free to proceed.
-Marco Carin Meier <carinme...@gmail.com> 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 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 fail with > an error message is worse than not having the artifact on Maven at all. > If it is going to fail, it should fail fast before it breaks things later > in the chain. > > Removing the artifact from maven is awful and it will break users. This is > undoubtably a situation that none of us want to be in, but I understand > from a legal standpoint that we have no other option. The best I can > suggest is to open a preemptive issue on Github, so that users can > remediate the problem by building the package themselves. > > Let's work together to get though this the best we can and move forward > towards graduation. > > Best, > Carin > > On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard <lau...@amazon.com.invalid > > > wrote: > > > 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 mitigating the problems. > Maybe 2 > > weeks to you is "driven out of necessity on full speed". From my > > perspective 14 > > days is a reasonable timeframe. The issues are severe and certainly block > > any > > progress on the graduation of MXNet. So this issue shouldn't be taken > > lightly. > > > > In either case, thank you for your belated addition of a new proposal: > > "replace > > the published package with a stub with the same signatures (so it loads > > properly), but throwing a fatal error message on load, linking to our > > documentation and explaining the situation" > > > > It's certainly better than deleting the packages, and less effort than > > re-doing > > all the releases in an ASF-compliant manner. Let's wait another few days > > if any > > MXNet committers, perhaps one that is already familiar with the JVM > > packaging > > and ecosystem, will volunteer to implement this. > > > > Best regards > > Leonard > > > > > > On Wed, 2020-05-27 at 02:36 +0200, Marco de Abreu wrote: > > > 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 suggesting here > > is > > > to make a full stop on the highway without even turning on your hazard > > > lights before. Thus, I'd recommend to take a few deep breaths (a few > days > > > more or less don't hurt as long as we're working on that issue) and > think > > > about a proper way to reduce the user impact. At the current point, > this > > > feel like it's completely driven out of necessity on full speed without > > > thinking about our users. > > > > > > Reality is that our users will be hit with a bunch of "could not find > > > dependency 'mxnet'" and that's a really bad user experience. > > > > > > Instead, we should figure out how other projects are handling retired > or > > > revoked packages on the various distributed platforms. One example how > to > > > approach the situation could be to replace the published package with a > > > stub with the same signatures (so it loads properly), but throwing a > > fatal > > > error message on load, linking to our documentation and explaining the > > > situation. Another way could be to talk to the publishing platforms and > > > check if there's a way to replace a package with a notice so when a > > > dependency management resolves it, it won't just say "not found" but > > > provide meaningful information. Simply expecting that users will visit > > the > > > website and figure it out is not sufficient and to me that user > > experience > > > journey has to be addressed before we purge the releases. > > > > > > Best regards, > > > Marco > > > > > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard > > <lau...@amazon.com.invalid> > > > wrote: > > > > > > > @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 their removal. These binaries > > only > > > > exists > > > > because the PPMC has previously failed to follow the ASF release > > policies > > > > for > > > > convenience binaries (the policies were only followed and discussed > for > > > > source > > > > releases). > > > > > > > > If you have a different proposal to the ones discussed during the > last > > 14 > > > > days, > > > > please present it. If you would like to volunteer re-doing all the > old > > > > convenience releases in an ASF compliant manner, that would also be > > great. > > > > > > > > Please clarify this if your "-1" is intended to start a procedural > vote > > > > according to [1] in which the majority of votes determines the > > outcome. In > > > > that > > > > case I suggest to change the email title to begin with [VOTE]. > > Otherwise > > > > I'll > > > > assume the lazy consensus still remains. > > > > > > > > [1]: https://www.apache.org/foundation/voting.html > > > > > > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote: > > > > > > > > > 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 <carinme...@gmail.com> > > > > wrote: > > > > > > 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_started?platform=linux&language=scala&processor=gpu&; > > ; > > > > ; > > > > > > > > > > > > > https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&; > > ; > > > > ; > > > > > > > > > > > > > https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&; > > ; > > > > ; > > > > > > Thanks, > > > > > > Carin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard > > > > <lau...@amazon.com.invalid > > > > > > wrote: > > > > > > > > > > > > > On Fri, 2020-05-08 at 20:49 +0000, 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 releases > without > > > > > > > libgfortran.so > > > > > > > > and other potentially Category-X files (I found libmkl_ml.so > in > > > > one of > > > > > > > the > > > > > > > > JARs..) > > > > > > > > > > > > > > > > If no-one steps up to do 2) or no-one suggests a better > > option, I > > > > > > > recommend we > > > > > > > > go for option 1). Let's start discussing the options. Once > > > > discussion > > > > > > has > > > > > > > > settled, I'll initiate a lazy consensus or vote session. > > > > > > > > > > > > > > As the discussion appears to have settled and there appears to > > be no > > > > > > > progress on > > > > > > > providing replacement JARs without Category-X files for old > > > > releases, I > > > > > > > would > > > > > > > like to start 72 hour lazy consensus on "Ask the Infra team to > > > > delete all > > > > > > > MXNet > > > > > > > releases on repository.apache.org". > > > > > > > > > > > > > > Best regards > > > > > > > Leonard > > > > > > > > > >
