Going forward - we with future releases, we can have all users build their own packages, just for the existing ones that are compliant on maven.
On Fri, May 29, 2020 at 12:14 PM Carin Meier <carinme...@gmail.com> wrote: > 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 >> > > > > > > > > >> >
