= Proposed System Wide Change: Discontinue PPC64 as Alternative Architecture = https://fedoraproject.org/wiki/Changes/DiscontinuePPC64
Owner(s): * Dan Horák <sharkcz at fedoraproject dot org>
After a number of projects dropped support for the big endian ppc64 architecture and our move of ppc64 to "maintenance-only" mode few releases back, now a vital dependency, the Eclipse project, stops supporting ppc64. As a consequence we need to discontinue producing any ppc64 content. This is a long time anticipated step as the upstream focus on the little endian variant (ppc64le) on Linux is well known. My email [https://lists.fedoraproject.org/archives/list/ppc@lists.fedoraproject.org/me...] sent to the Fedora PPC mailing list has few more details.
== Detailed description == Fedora will stop producing ppc64 content - binary rpms or composes.
== Scope == * Proposal owners: synchronize with rel-engs
* Other developers: none
* Release engineering: #7602 [https://pagure.io/releng/issues/7602] changes in koji, bodhi and pungi configurations are expected
** List of deliverables: N/A
* Policies and guidelines: none
* Trademark approval: N/A (not needed for this Change)
"JK" == Jan Kurik jkurik@redhat.com writes:
JK> https://fedoraproject.org/wiki/Changes/DiscontinuePPC64
This may be necessary, but it's sadly unfortunate as (so far as I can tell) it leaves us with only one big-endian architecture (s390x). And while it was not difficult to get a login on a ppc64 machine for testing, I've not been able to get any shell access on s390x so far.
Having builds done on big-endian architectures has helped to point out endianness-specific breakage with least one upsteam (which, hooray, did get fixed). Having only one big-endian architecture makes it difficult to know when you are facing an endianness problem versus something specific to one architecture. I think we can all agree that "your code is broken on all big-endian architectures" sounds serious while "your code is broken on this weird mainframe thing that nobody actually has" is far less likely to elicit action by a time-constrained upstream.
- J<
On Mon, 02 Jul 2018 12:57:41 -0500 Jason L Tibbitts III tibbs@math.uh.edu wrote:
"JK" == Jan Kurik jkurik@redhat.com writes:
JK> https://fedoraproject.org/wiki/Changes/DiscontinuePPC64
This may be necessary, but it's sadly unfortunate as (so far as I can tell) it leaves us with only one big-endian architecture (s390x). And while it was not difficult to get a login on a ppc64 machine for testing, I've not been able to get any shell access on s390x so far.
Then I had to miss your request, we have a public s390x guest running Fedora that can be used by maintainers and also by interested upstreams. I'll get back to you next week, when I'll be back in the office.
Having builds done on big-endian architectures has helped to point out endianness-specific breakage with least one upsteam (which, hooray, did get fixed). Having only one big-endian architecture makes it difficult to know when you are facing an endianness problem versus something specific to one architecture. I think we can all agree that "your code is broken on all big-endian architectures" sounds serious while "your code is broken on this weird mainframe thing that nobody actually has" is far less likely to elicit action by a time-constrained upstream.
I fully understand, ppc64 is/was easier to get access to and I'm sure there are still projects with endianness issues. Although the situation is much much better than when we (re)started Fedora for ppc/ppc64 and s390/s390x cca 10 years ago. Our thanks go also to the Fedora maintainer community for the great job they are doing. The Linux on Power upstream set the directions quite clearly towards ppc64le and it was matter of time when individual projects' upstreams will discontinue ppc64 support and we will have to react. Also the complexity of the dependencies inside Fedora added to this decision.
Dan
-
Dan Horák -
Jan Kurik -
Jason L Tibbitts III