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 be a better solution than deleting ALL of them, if the CPU ones are still valid and adhere to licensing. At least, we would break fewer users. - Carin On Wed, May 27, 2020 at 2:18 PM Lausen, Leonard <lau...@amazon.com.invalid> wrote: > 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 > > > > > > > > > >
