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