Hi David et. al, On Fri, 2022-07-01 at 10:24 -0500, David C. Rankin wrote:
All,
I was following the "[TW] nextcloud desktop client uninstallable" thread and that brought up the question of how are these build failures being identified and handled in the rolling-release process and how are they slipping through?
I ask because I'm not that familiar with the Tumbleweed QA process and am only familiar with how Arch does it. With Arch, there are two sets of repos:
(1) "testing" - where new upstream packages and build system changes are introduced. Any build type failures are identified here and package remain in testing until the issue are resolved (along with any packages that depend on them)
(2) the normal repos - when package hit here, all build and dependency issues have been resolved and the only corner cases that arise are the stray user hardware/software combinations, etc...
I suspect openSUSE has a similar setup for Tumbleweed, but in the case of nextcloud client and Calibre the FORTIFY_SOURCE=3 somehow seems to have gotten by. Now this is just "growing pains" no different to handling build with jumps in gcc or glibc versions -- there are going to be issues to fix.
My curiosity is where/how are these "growing pains" issues caught in the Tumbleweed process?
Factory contains roughly 15k source packages by now. The entire project is built up of three 'layers': Ring0: Distro bootstrap. The core to get things building Ring1: 'The DVD' - things guaranteed not to break, mainly consists of the two main desktops KDE/GNOME plus a set of packages that must build at any moment. Ring0 + Ring1 is 3238 packages (as of now - numbers vary) Those packages are being forked into the 'Letter stagings' and, are rebuilt against anything in that staging project at the time, and then passed on to openQA. only when passsing, the change in the staging can be accepted. Now, as this is 'only' ~3k packages, this leaves a gap of like 12k packages. Those are only tested to build/install properly when they are submitted to Factory themselves - any later changes are not tested on cross-impact - so they can fail to build This is what happened to nextcloud-desktop now: it failed to build since Mid June. But it was still installable, so 'nobody seemed to care' Two weeks later, a new Qt version comes by; nextcloud-desktop still not building results in 'dependencies no longer being available' Striving for a 0-build fail would be a nice-to-have, but in the ~8 years as release manager I have never seen that. The closes to that must have been in the range of 20 failures (curretnly we are at ~200) Cheers, Dominique PS the doc model is also described at https://en.opensuse.org/openSUSE:Factory_development_model