public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] [RFC] Dropping s390 (but not s390x) entirely and s390, s390x to ~arch.
@ 2021-02-16 23:55 Sam James
  0 siblings, 0 replies; only message in thread
From: Sam James @ 2021-02-16 23:55 UTC (permalink / raw
  To: gentoo-dev; +Cc: s390

[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]

Hi all,

I have two linked proposals:
1) I propose we remove support for Gentoo on s390 and support only s390x instead;
2) We drop the s390 arch (covering both s390 and s390x) keywords to ~s390 (unstable).

Right now, we support both s390 and s390x with the same keyword (’s390’) but s390x has a subprofile.
No separate keyword exists.

In reality, this means all packages should be tested on s390 (lowest common denominator).

This has some limitations:
* upstreams aren’t particularly interested in the 31/32 bit platform that is the original s390;

* Following on from That Cryptography Debacle, upstream Python and others may be looking
  to drop s390 support anyway;

* s390 is not supported by e.g. libpcre for JIT. Ditto LaTeX which means we have to
  mask a lot of documentation. It’s not a huge deal but it shows how little attention folks pay to it,

I’d like to make clear that this isn’t a knee-jerk response to recent events with the Python ecosystem;
we have a limited amount of time and volunteers and I don’t recall seeing a bug report from an s390 user
any time recently. Further, nobody other distros seem to be carrying s390 (only s390x).

(On the recent dev-python/cryptography bug upstream, it was claimed s390 isn't supported by the kernel,
but I can't find any evidence for this, so let's not base any decisions on that unless
some evidence arises.)

I tried to review old bugs and most were from Gentoo developers testing the platform, but I accept
it may have had more relevance in the past. We’ve not even built stages for it in a year and nobody
seems to have noticed.

Motivation:
* I'm the only person actively doing keywording and stabilisation for s390 and find it hard to keep up -
reducing the workload would be helpful for me but also motivate me in terms of reporting issues when
there's actually likelihood of it being fixed vs for a (thought to be) dead platform.

* I’d prefer it if we only declared support for things we can support *well*. I’d say s390 isn’t currently
in this category and at least having s390x as the target is a bit more realistic.

* We’re not really consistent with what is/isn’t stable for s390 at present anyway, hence the profiles
are dev/exp.

* We’re going to have a headache with certain things like Rust and it’s an opportunity to assess
what we’re supporting/not and ideally limiting our efforts to realistic & worthwhile targets.

In any case, I’m not trying to kill off platforms people are using, so:
1) If anybody is using this, please tell us!

2) I’m quite happy (as well as others I’ve spoken with) to keep s390x which is more well-accepted as a platform and is
still in circulation.

Thanks,
Sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-02-16 23:55 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-02-16 23:55 [gentoo-dev] [RFC] Dropping s390 (but not s390x) entirely and s390, s390x to ~arch Sam James

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox