@poetaster and @mal (plus @lbt),
It’s become increasingly slow to build on obs with the growing number of releases since:
yes, but it does not matter, because the SailfishOS-OBS is not integrated in interactive CI runs. It is rather the slow downloads of a few gigabytes for each CI run at GitHub which is getting on my nerves, because it makes sense to run the CI for each commit in a pull request, and there I do wait “interactively” (or rather: sitting in front of the screen without any interaction), until a CI run has finished. This why I am working on caching downloads at GitHub.
Which goal are you trying to reach here, rsp. which issue are you trying to address?
“Is slow” does not matter per se, so I wonder why this is perceived as problem.
Furthermore, it is exactly the fact that the SailfishOS-OBS allows to build for many SailfishOS releases, including “old” ones, which makes the SFOS-OBS so attractive. I and some others rely on these “old” releases and they are my primary motivation to utilise the Sailfish-OBS and to maintain Storeman, the SailfishOS:Chum GUI app and the SailfishOS:Chum repo config RPM, plus the Storeman Installer and SailfishOS:Chum GUI Installer. If you want me out of all these, this is exactly the right step.
No, this also affects Storeman and in consequence OpenRepos, as Storeman it its only client app for SailfishOS ≥ 2.1.4.
If one wants to reduce the number of build targets, I would rather ponder how to avoid building for so many point releases of SailfishOS
4.?.0.*, because these are really superfluous: The binaries built for any
4.?.0.x release are supposed to work fine on any other
4.?.0.y release, AFAIK. Offering a single build for
4.?.0.<latest> would be sufficient, if all older build targets for a specific
4.?.0.* can be linked to the build results for
4.?.0.<latest> at the SailfishOS-OBS.