Which DOD releases should the SailfishOS-OBS support?

General
#1

It’s become increasingly slow to build on obs with the growing number of releases since:

The question is what should/must stay and what is superfluous.

In some discussion on irc, my suggestion was to REMOVE support for:

  • 3.1.0.12
  • 4.0.1.48
  • 4.1.0.24
  • 4.3.0.12
  • 4.4.0.58

I believe @mal would go further and remove 3.2 and 3.3 which I’ve not included here to ask @olf for hist feedback and 4.4.0.64 / 4.4.0.68 for feedback from @piggz. and of course, @rinigus?

Do any porters have more feedback???

EDIT: This pertains mostly to chum!

1 Like
#2

There is the onda tablet (v5), which is stuck at 3.3.0.16, so i would vote for that. On the other hand it cannot connect to any service, because of outdated certificates. I couldn’t update them, so some help would be appreciated, but this is getting offtopic now. The oneplus x is also stuck at a certain release, but i don’t remember which, but definitely below 4.x

#3

I vote for 4.x releases. It’s because of security issues of using outdated devices.

#4

Oneplus x is on 3.1.0.12, but the question here is also if it can still connect

#5

Ok, I believe the connection issues, if they are SSL related, have been addressed in depth by @olf ? https://forum.sailfishos.org/t/guide-fix-certificate-issues-on-sailfishos/

1 Like
#6

It should support any release which has a working port, regardless of age (within reason).

E.g. the 3.4 series is useful to provide inofficial security fixes for J1 devices.

Community ports may be stuck on random old releases, simply because development has ceased or never provided OTA updates.

What could help wrt. building on Chum:

  1. Don’t build while Jolla is working on releases. :wink: :wink: This is when Chum build engines tend to be slow.
  2. As developer, minimize active repos so as not to clog the build engine pool. While developping, testing, a single arch and version should suffice.
  3. arch x86 is fastest when building (no emulation overhead)
2 Likes
#7

@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.

#8

I believe the full versions are useful wrt. adding them to ssu repo (and friends), as here the OS release can be specified as a variable in the URL.

#9

Yes, but that only means that all the point-releases of a SailfishOS release have to be resolvable at the SailfishOS-OBS, but not necessarily build.
This is why I suggested to research:

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.

#10

Thank you for the feedback. Not meaning to be obtuse, but I believe the list I posted above has you and the storeman releases of interest (except 3.1) covered?

#11

I’ve been doing this where I ‘know’ a release is pointless to support since I have things that depend on > 4.2, for instance.

Sometimes one also has to ask @rinigus and @piggz to after the fact since I’ve either neglected it or mis-managed it.

In any case, you are correct. Attend to removing things you can.

#12

Sorry, this is nonsense: No user who is deliberately or coerced into using an older SailfioshOS release will switch to a newer release, if you cut them off from receiving newer app versions. IMO this measure would just appear to be evil to all of those.

Mind (as stated before), that users of a Jolla 1 and some community ports (Onda tablet & Oneplus X have already been named) do not have any choice: No newer SailfishOS releases exist for these devices, hence they cannot upgrade.

#13

The measure of omitting any SailfishOS release creates a general, structural and hence generic problem, not one which only affects Storeman, as I tried to point out. Thus discussing any specific release target(s) to omit does not make much sense, IMO.

This is why I suggested to investigate if the many point releases of a specific SailfishOS release x.y.z can be mapped to its latest point release, because this would structurally address this, cause no loss for anyone and keep the number of build targets lower for good; if the many build targets are really a problem.

Ultimately I am really interested what motivation is, because “slow” is not an issue IMO. Ships are slow too, but the idea of transporting thousands of cargo containers by plane is also not an appropriate measure to counter that.

#14

Ok, thanks for the clarification. I think that besides the issue of processing time/power there is the issue of storage.

As @nephros pointed out, it certainly makes sense to disable point releases, or greater, for developers who know exactly where they stand (cases where I have decided to, at least for now, support only the new webviews > 4.2).

So, I’ll contract my list:

Would be my recomendation + 4.4.0.64 & 4.4.0.68 depending on how @piggz responds

#15

And yes, I agree with this. It imposes a burden currently but certainly a justifiable one.

#16

I cannot believe that disabling a couple of build targets will make a significant difference:

  1. I see the SailfishOS-OBS regularly idling. Sometimes there is quite some “bursty” activity, but many times almost nothing. See Build Status Monitor - SailfishOS Open Build Service
  2. Storage space for apps, which are between a few KBytes and a Megabyte large, in times where a single storage medium (HDD or SSD) provides some Gigabytes, cannot be a serious issue IMO. The by far largest projects are SailfishOS ports, but these are just a few and they already have very specific targets (arch & SFOS release(s)).

As @nephros pointed out, it certainly makes sense to disable point releases, or greater, for developers who know exactly where they stand.

Yes, I expect everyone building software at the SailfishOS-OBS not to let it build for releases on which a specific piece of software does not run. It may make sense to communicate this guidance clearly on the SailfishOS-OBS front-page.
For SailfishOS:Chum GUI application, the SailfishOS:Chum repo config RPM(s) and Storeman, plus the SailfishOS:Chum GUI Installer and Stoireman Installer this is an empty set, because it is their very purpose to support all SailfishOS releases ≥ 3.1.0. And these five packages are all I seriously use the SailfishOS-OBS for.

#17

Redmi 5 Plus port is stuck on 4.4.0.64 (there is update to 4.4.0.68 but with broken videoplayback).

#18

We don’t have stats on OBS usage, unfortunately. Ideally, unless those point releases are merged, would be nice to have Chum stats per each release and then close a release if there are no downloads from it for several months or so. I wonder whether we have such idle releases among the ones that we support. But that would require someone from Jolla looking through the logs and making stats.

#19

It does go further than this though.

Obviously in the sailfishos:chum project, all targets and archs should be enabled for each package (with exceptions in packages for releases where it does not build or run).

In sailfishos:chum:testing, this can be reduced already - although with Chum-GUI letting users switch freely around, perhaps they should match the sailfishos:chum setup just out of fairness. (Also the Gatekeepers of sailfishos:chum should not need to check each submit request for text which specifies which releases to enable or disable).

Now. What follows is this: thou shalt not CI build/debug/personal test builds on sailfishos:chum:testing. I.e. do not do stuff which repeatedly builds software as you step by step get closer to a “release” type situation.
This is doubly true for packages which have dependentees, as those get rebuilt as well. (It’s also impolite for users of the testing repo, as they will get many updates which are likely uninteresting and possibly broken for them).

Instead, either have some subprojects in your home, or use the OBS branch feature to do development builds. And in those, disable as many repos as is feasible.
Other features, like using _link files or collecting other repos in one single repo in the meta configuration offer lots of flexibility for those devel spaces.

2 Likes
#20

Yes, I fully concur with these statements, which would be really relevant guidance and might help to alleviate the perceived issue. IMO addressing this at the social level is a much better and suitable approach than limiting possibilities and erasing stuff at the technical level. The current technical suggestion appears to me a bit as a “solution looking for a problem” with a couple of drawbacks. Actually switching off the ability to use webhooks, so the SailfishOS-OBS cannot be used as a CI machinery might be more effective than disabling some DoD repositories. But again, I would rather see developers being advised to use this feature responsibly, instead of it being switched off.

And there is much to take into account. For example, the content of this paragraph was absolutely new to me (i.e., I do not know these features):

P.S.: Ultimately I answer the real question “Which DOD releases should the SailfishOS-OBS support?” with “all ≥ 3.1.0” (which is the current state) and the original question “Which DOD releases should the SailfishOS:Chum community repository support?” with the same (i.e., add 3.2.0). Still technical measures to build less, but keeping the current feature set intact, are sure fine and make sense.