On Fri, Aug 14, 2020 at 8:39 AM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:
Am 14.08.20 um 13:23 schrieb Neal Gompa:
My experience has indicated that unless you make alternate architectures everyone's problem, it's just *not* going to get any better.
That's part of Dirk's proposal though, at least on paper. To quote: "The package maintainers commit to handle primary architectures with care and test-build them in the development projects before submitting changes. The package maintainers commit to handle regressions quickly and in general accept bugreports for that platform and work on a resolution."
Sorry, no. Not going to work. There is no reasonable way to enforce that. That being said, because *I* care, I actually *did* enable all architectures on the system:packagemanager:dnf[1] devel project a long time ago. But most devel projects will not do it. And the whole point of the staging workflow is so they don't need to. [1]: https://build.opensuse.org/project/show/system:packagemanager:dnf
For example, Fedora has x86_64, AArch64, and armv7hl as primary architectures, with ppc64le and s390x as secondary architectures. But for packagers, they are all effectively primary architectures because the build system will not let a build through without it successfully building for all architectures that it is supposed to be built for.
Most devel projects have alternative arches, so I think you're going to at least have an eye on failures there. But it's hard to prevent breakages if you just look at individual packages, because dependency changes can also break a build.
I'd love to see the stats here, because I'm pretty sure the overwhelming majority of devel projects do not.
Even with Staging you can end up breaking packages, because the Stagings don't consider the entire tree of >10,000 packages. So you'll have to rely on maintainers reacting on notifications that their package doesn't build anymore.
This is what the staging workflow is for, and if the notifications aren't working, we need better communication.
openSUSE's problem is that they don't want to take that step to make their alternate architectures actually regularly useful by *forcing* every architecture into openSUSE:Factory. There has been no proposal from Dirk or anyone that even reasonably considers eliminating the "ports" tree.
Part of the reason might be that this is a community project and most people can only reasonable debug issues on x86. Once I had to debug a miscompilation that was only observable on s390x and ppc64(be), and it was a pretty painful experience. (Just as a side note: I ended up finding the bug and porting back the necessary fix, so it never ended up in Factory:{PowerPC,zSystems}, whereas to my knowledge Fedora didn't do anything about it. Not sure if it ended up in any release though.)
This is even sillier when you realize that SUSE Linux Enterprise doesn't bother with this malarkey and actually *does* force all architectures into the same development project because they know in order to make it supportable, they have to have a consistent tree for all architectures. Otherwise the "common codebase" is a lie. SUSE employees probably have easy access to machines of all supported architectures, which makes it a bit different. Also SLE has considerably lower churn than Tumbleweed, so you're not going to need the same amount of build resources. I agree that this is overall a better model, but it's a bit harder for a rolling release community project.
Then ultimately this comes back to enabling the community to be able to fix these things. In Fedora, packagers and developers have access to test machines of all less-available architectures that they can shell into, build, test, and refine for those architectures[2]. Admittedly, because of the data center move, those are all down right now, but the general point is that they are available so that people are able to fix problems for those architectures. Solving that problem for openSUSE people should be equally easy: provide resources that the community can use for this purpose. [2]: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainer... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org