On 12/7/22 23:12, Fabian Vogt wrote:
Hi,
The more I think about it, the more wrong this approach looks to me.
To get one thing out of the way: I'm fine with moving support for 32bit HW outside of openSUSE:Factory. That's truly legacy now and there are visible benefits by dropping it or making it "secondary".
However, the decision to make openSUSE:Factory x86_64-v2 only has practically only downsides. Either we drop x86_64-v1 HW support completely, or introduce a project to build the distro for x86_64-v1 separately. At this point it looks like the latter is inevitable. That means:
- It doubles the amount of builds and test runs (power, storage, time) - It doubles the release effort (looking at openQA, handling product changes, all the infrastructure) - It makes it necessary to migrate affected users over, which needs to work seamlessly but also inform them about this topic - It will be treated as a second-class distro, with bug reports getting less attention if "LegacyX86" is mentioned - There will be loss of functionality when some parts are not explicitly looked at for x86_64-v1. There might no longer be MicroOS/Live CDs/whatever built. (Which also means that "LegacyX86 solves your problems" is not true, at least not for long) - Various projects are not able to distinguish between x86-64 "levels", so it's not possible to seamlessly provide x86_64-v1 container and Vagrant images. (OCI/Docker can tell armv[5678] apart, but all amd64 is just amd64).
What are the actual benefits of moving openSUSE:Factory to x86_64-v2 that make all this worth it? - "It's faster!": By how much? A lot of performance critical code already uses runtime dispatching, even Qt does that. It looks like x86_64-v2 alone does not have much performance improvement, based on the opinion of experts on this ML and (little) available data. At the highest end (HPC), custom builds with -march=native are preferred anyway. - "ALP wants us to because of 'Factory First'": The point of Factory First is to avoid extra work by addressing issues or adding features once for both upstream (oS:F) and downstream (SLE/ALP). In this case I don't think there's much (if any) benefit for ALP if Factory switches over. ALP will be built and tested separately anyway. If ALP hits some bug caused by x86_64-v2 and fixes that, this fix should be sent to openSUSE:Factory as well - that is Factory First!
Switching to -v2 now also implies that there will be a switch to -v3 or later at some point in the future. Then we'll have this discussion all over again. That then implies dropping support for -v2, so we can only do that after -v2 is no longer relevant, which is much later than other distros which might already provide -v3+ binaries next to -v1/-v2.
On the plus side if we do end up with a -v1 port then it makes the -v3 discussion much easier to have again once ALP is released or close to release and tumbleweed is more free to move away from it, so in a year and a half to 2 years we could possibly have just -v1 and -v3 in tumbleweed which is what most people feel is best we just have to go via -v2 until such a time as this major version of ALP is released or in beta. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B