Adds travis jobs on ppc64le

[dineshks1]

This PR adds power support on travis.

[dineshks1]

This is part of the Ubuntu distribution for ppc64le. This helps us simplify testing later when distributions are re-building and re-releasing,For more info tag @gerrith3.

[dineshks1]

Please review this merge.

[dineshks1]

@springmeyer waiting for your response for merging ppc64le code.

[springmeyer]

@dineshks1 @gerrith3 - testing on ppc64le seems okay on travis. But I'm still hesitant to merge this because it might communicate that we support that platform going forward. But in reality tilelive is not seeing active development anymore so if any problems come up related to running on ppc64le we won't be fixing them. And therefore from that sense I don't see why to add this. If you want to discuss in more detail you can send me an email at dane@mapbox.com and we can set up a time to discuss.

[gerrith3]

This is a pretty common question, @springmeyer . You may not realize it but this package is already part of debian and ubuntu distros:

ubuntu@gerrit:~$ sudo apt-cache search tilelive
node-mbtiles - Tilelive store for writing to MBTiles format - Node.js module
node-tilelive - Interface for tile backends modules for Node.js
ubuntu@gerrit:~$ uname -a
Linux gerrit 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:33 UTC 2020 ppc64le ppc64le ppc64le GNU/Linux
ubuntu@gerrit:~$ cat /etc/issue
Ubuntu 20.04.1 LTS \n \l

so you aren't necessarily making any support statement here. There is a lot of "unmaintained" stable code out there that "just works" and that's fine. What helps is knowing for sure that the package works upstream, which is part of this testing that we are doing right now. Locking it in with travis regression testing probably does more to provide "support" than any active statement does. And if there is an issue that gets raised, it may or may not come to my team - if so we'll look at it. If not, it is business as usual - a defect gets raised and it gets looked at when there is interest/bandwidth/etc. Let me know if you want to talk, we can set up a quick touch base if this isn't clear enough.

thanks!

[springmeyer]

Makes sense @gerrith3 - thanks for that extra context. I'm of the opinion that node.js libraries should not be packaged in debian, but that is surely a different topic altogether.

[gerrith3]

@springmeyer yeah - and a more complex issue - not so much debian, but ubuntu, fedora, RHEL all have more need to operate in air gapped installations, which is why I think they include those. Downloading on the fly seems obvious but the ultimate security is still a good air gap...

[nyurik]

@springmeyer hi, if mapbox is not actively maintaining this repo, do you think it may consider to transfer it to the https://github.com/openmaptiles ? Of course we can have a fork there, but moving the primary repo would indicate to everyone that this is the new home of the project? Thanks!!!

[springmeyer]

@nyurik Mapbox is not actively developing tilelive, but we do have systems still using it, so it could theoretically see some maintenance if we run into bugs that impact our systems.

That said, I'm still interested in hearing what needs you have. Maybe there is something we could transfer. Do you see reasons and ways to develop tilelive further?

[agoddard]

@springmeyer based on the above, as well as Mapbox declaring the project "no longer actively maintained", and your earlier comment https://github.com/mapbox/tilelive/pull/222#issuecomment-737383541 it seems like @nyurik's suggestion would meet Mapbox's stated needs. If the project is transferred, the community can continue development on it without Mapbox having to signal that it's maintaining or supporting it, and Mapbox can submit maintenance patches for the theoretical bugs you mention (either back to the transferred project, or to its own fork) without the overhead of project management (or, again, the appearance of "active maintenance").

Thanks!

[nyurik]

Thanks @springmeyer and @agoddard for your feedback! I think @agoddard brings a valid point - there are two concerns -- Mapbox internal usage of the product as it exists today, and Mapbox's public steering of the product future development. Mapbox is clearly interested in former, but doesn't seem to be interested in the later. If so, the ideal (IMO) steps would be:

• transfer mapbox/tilelive repo to a community organization like MapLibre. This will create a redirect for anyone using the old URLs.
• create a maplibre/tilelive fork with a different name (e.g. mapbox/tilelive-private) so that GitHub's redirect system doesn't break, while Mapbox can continue working on the library for internal needs, possibly without even making the repo public.

Obviously it would be wonderful for Mapbox developers to continue participating in the projects. Would that make a good path forward, or are there other concerns/issues?

Thanks!