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 Pypi packages, non-ASF third-parties (individuals or companies) are free to publish Maven packages on some non-ASF infrastructure, as long as they don't infringe trademarks of the ASF. Sheng is doing that on Pypi. Best regards Leonard On Wed, 2020-05-27 at 14:54 +0200, Marco de Abreu wrote: > 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 > > > > > > > >
