Added power support for the travis.yml file with ppc64le.

[sreekanth370]

Added power support for the travis.yml file with ppc64le. This is part of the Ubuntu distribution for ppc64le. This helps us simplify testing later when distributions are re-building and re-releasing

[Diaoul]

Thanks for your contribution. I'm not sure I understand why this is needed. This package isn't dependent on the architecture of the CPU. As long as Python runs fine, this package will run fine.

[sreekanth370]

Hey, This is Power architecture - primarily the bigger enterprise class systems from IBM for banking/insurance/retail/etc.etc but this ensures that your code and all dependencies are tested on the Power architecture. Debian/Ubuntu, and Fedora/RHEL/CentOS have ppc64le (Power) distributions and this code goes into those distributions. This ensures that top of tree is always validated on ppc64le using (free) Power servers at Travis CI

[sreekanth370]

For more info tag @gerrith3

[Diaoul]

I think if Babelfish works on Python this is fine enough, the code itself is platform independent as it is pure python. Ensuring Python works on this architecture automatically ensures that babelfish will work as well. Obvious this will remain true unless babelfish suddenly becomes platform dependent which is not planned. Or am I missing something?

[sreekanth370]

For more info tag @gerrith3

[labrys]

@Diaoul This user is a bot account that spams repos with pull requests for ppc64le. I would close this PR.

[gerrith3]

@labrys actually that is untrue - Sreekanth is an IBM employee working for me, who has been working with Travis to provide free Power CI to the community and helping the community take advantage of those where they are already using Travis on Intel. Hopefully that is not your only reason for closing out a PR. He did full testing of this project on a ppc64le machine, set up a run under his own travis account and verified that the testing options are valid for both intel and power. To throw that work away because you believe he is a bot is not very logical.

[Diaoul]

The reason for closing this PR is explained in my previous comment, the latter discussion about the account being a bot or not is not related and purely a timing coincidence as I received the notification after a comment on the PR. I closed the PR due to the lack of response on it after 3 months now, which seemed enough time for you to reply after you had been tagged by Sreekanth. In short my reasoning is: Babelfish is pure Python, Python is platform-independent, hence testing on one platform is enough to ensure cross-platform support. If you have a diverging opinion please explain how this is not sufficient for you, I'd be happy to reconsider this contribution.

[labrys]

@gerrith3 My reason for suggesting closing was that as Diaoul pointed out there is no compelling reason to test on the architecture.

My assertion that Sreekanth is a bot was to inform Diaoul not to expect a response as Sreekanth made similar pull requests across many libraries and when faced with similar questions they reply with the same exact response For more info tag @gerrith3 with no follow up response.

I too would like to know if there is any value in testing a pure-python package on the the Power architecture for my own tests. If you have one please share it with Sreekanth too so he can enlighten people instead with a timely response instead of simply tagging you.

[gerrith3]

@dimotsai @labrys thanks both for responding, and my apologies for not responding. The team has tagged me on a lot of these as they were working to update some 3,000+ packages to ensure currency on Power/ppc64le. I have tried to address many that requested info, but unfortunately I read Sreekanth's comment as a request for you to tag me directly if you had questions, so my apologies for not realizing there was an open question here.

However, as you've said, Python packages are, by nature, mostly architecture independent. However, we find that while porting things to Power is generally easy, there are still about 10-15% of python packages that have build or run time dependencies outside the scope of a specific github project, and that is where those packages often fail. We've found that testing on Power explicitly catches many of these and helps to be more precise about what level of support people might expect on a package. For instance, I believe Sreekanth found that the permissions on the pip wheels directory on Power was not the same user/group as on Intel (possibly a write permissions issue?) and that pypy was excluded, although on that one I'm not sure why.

However, the point here is that there are often niggling little differences between Power and Intel - we are trying to resolve all of those, but additional test/validation cases and of course, building up the ecosystem with tested Power components will over time minimize those differences. The fact that multiple distros have done this validation at various points in time is great, but we are trying to reduce the cost of packaging a Linux distro for Power across the board and moving verification/validation closer to development where any issues can be found and fixed much more quickly, often by the original contributor before the contribution is even accepted. This improved overall transparency into the entire process of building the ecosystem as well.

Hopefully this helps - ultimately the choice is yours, but we have tried to do due diligence up front, follow the normal process for being a contributor to a project, and doing all necessary testing to help support this platform. Thanks for reading!

[labrys]

So, correct me if I'm wrong, it sounds to me like you want as many people as possible testing the Power ecosystem more because of potential issues with the Power Linux distros and not the packages themselves so you can identify and resolve them.

[gerrith3]

@labrys More simply, I'd like to dramatically reduce the overall cost of making Linux on Power available to all of our end users. Trying to keep multi-arch support current with 100 million repositories and the work of 31 million developers is too much for IBM and a few partners to contain by itself, and the cost of our few developers learning about every one of the 100 million repositories is a pretty tall order. But, the incremental cost to each community is typically pretty tiny and puts the focus back on each submitted pull request to make sure the developer hasn't unknowingly broken another architecture.