Re: [apache/incubator-mxnet] [RFC] MXNet website improvements (#17982)
Another issue: Anchor tags are shifted. Anchor tags exist, but they don't work properly. They are shifted by certain margin [potentially getting hidden by the header] For ex: 1. Go to contribute page : https://mxnet.apache.org/community/contribute.html 2. Select a specific anchor : Setup MXNet for Development [https://mxnet.apache.org/community/contribute.html#setup-mxnet-for-development] 3. It takes you here https://user-images.githubusercontent.com/10992635/83057216-766a8c00-a00b-11ea-83da-0de634bd9df6.png;> But it's supposed to show you this https://user-images.githubusercontent.com/10992635/83057243-82eee480-a00b-11ea-92e7-3d9e027a2b1a.png;> This looks like an easy fix and improves usability as anchor tags will start behaving correctly [rather than user having to scroll up to adjust the screen]. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-mxnet/issues/17982#issuecomment-634850809
Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)
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 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 > 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 > > >
Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)
Thanks for your input Carin. In that case, I'll take back my -1 and feel free to proceed. -Marco Carin Meier 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 > > 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 > > > > > 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
Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)
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 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 > > > 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
