On Sat, Feb 22, 2020 at 09:59:00AM -0500, Santiago Torres-Arias via arch-dev-public wrote: > > > To make a long story short, I consider broken geolocation sufficient > > > reason for removal. I don't mind it being broken for my own use, but > > > shipping a package with broken functionality due to lack of upstream > > > support does not sit well with me. > > > > The short story doesn't accurately reflect reality. There's still upstream > > support, you've just not been willing to conform to the new officially > > supported process. > > > > > To protect against systems with outdated Chromium (following the stable > > > release of version 82), at the beginning of April I intend to post a > > > news item about the need to switch to another browser. That is assuming > > > no solution is found and nobody objects to the removal or wishes to > > > continue maintenance of the package with reduced functionality. > > > > If anyone wants help in getting Geolocation working again, please let me > > know. > > > I'm curious, do you have a reference on how the process has changed? I > think it'd be easier for people to gauge interest if they know what the > new process entails. I'm also wondering if the billing requirement could > be handled by SPI or some other organization-level approach....
The old process was essentially "know someone on the inside". Billing and access for Maps-based APIs has a loooooooong history. It existed before Google was really in the business of selling other APIs. Thus, it's gone through multiple iterations and a somewhat independent evolution. Lately, that's changed and it's now using standard internal infrastructure. As a side effect, the backdoor that Chrome developers used to be able to provide to distros is no longer available The new process is well-described here: https://support.google.com/nonprofits/answer/3367237?hl=en dR
