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 > > > > >
