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.
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
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.
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.
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.
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.
I can only concur with @nephros and @olf. There is still a question for me whether or not the build defines () always make it from testing to chum proper. I’ve experienced that I’ve limited it in testing, but it’s all-inclusive in chum proper. Maybe ‘old news, fixed’. But, I’m entirely for voluntary self control. If I am able. I’ll try.
OTOH, as I expect GitHub to still exist in 15 years, another approach would be to map the current use of the SailfishOS-OBS for the SailfishOS:Chum community repository to GitHub. I started to think about that when evaluating how to map Patchmanager’s Web Catalog to GitHub and I think this is feasible for both and not really hard. With a bit of pondering and planning this might turn out to be technically elegant approach, given that most of the sources are already hosted there. For example, webhooks would become obsolete, as one can use GitHub-internal triggers in GitHub actions instead. But to implement that properly will take time. The biggest drawback I see here is a political one: If GitHub ever decides to switch off CI runs, GitHub actions or severely limit the resources used for these in the “free tier / plan”, this becomes infeasible (currently it is “just slow”, but the limits are almost impossible to hit). But in the past, GitHub has been consistently heading in exactly the opposite direction to stay the biggest hoster of FLOSS and proprietary (in “private projects”) software sources.
As a fallback, I’ve begun implementing builds using actions (so far only tooter) with @coderus excellent docker images. Which brings up the point that there are two dependencies, github and docker. I had initially planned on firing a webhook upon successful completion of a build on github but put that idea on hold until I have more experience with actions.
Not quite related but there is also gitlab, which offers a similar (but different) CI engine, can also run coderus’ images.
And with gitlab-runner, you can run the coderus docker engines on your development machine, using (almost) the same CI config and same .spec file setup.
Does anyone know if an OBS instance that builds SFOS ports can be independently hosted?
I know there are some services that I havent’ seen in e.g. Opensuse and the other way around (e.g. tar_scm vs tar_git) and that there are some repositories that provide prebuilt packages for ports.
Is there any thing that would make this unobtainable?
It is not necessary something that is argued in bad faith but in the intend that the support for older releases runs out.
If a user deliberately choose to stay on an old Sailfish OS version than after some time apps might not be compatible anymore, it is not bad faith to stop supporting older versions.
Not building an app using a target for each specific version isn’t necessarily an issue packages from older releases will still install but migration to updated OpenSSL versions or package compressions have to be taken into account.
Packages from 4.x should safely install on 4.4.x or 4.5.x, it is important to check stop releases for breaking issues.
It is important to provide good ssu configuration besides good obs project configuration.
I can’t talk with the OBS maintainers hat on as I’m not involved on that side but I think the points that have been brought up such as merging point releases seem like a good idea.
Privately for my own use I wrote this package to provide better SSU configs for the community OBS:
It is possible to extend it further to add repositories such as chum.
Hi @olf, I cant seem to be able to PM you so I’ll ask here. So if I understood correctly, we would need a Github premium account and a volunteer to integrate the webhooks/CI and triggers ? As an association we can benefit from the Github discount.
So if I understood correctly, we would need a Github premium account
I don’t see why and wrote the opposite:
… the “free tier / plan”, [is] currently … “just slow”, but the limits are almost impossible to hit.
and BTW
webhooks would become obsolete,
and a volunteer to integrate the webhooks/CI and triggers ?
That is quite some work, requires very good understanding of “GitHub actions” and Coderus’ SDK builder, plus how to properly design efficient CI pipelines and a meta-infrastructure which mimics rsp. maps the basic features of OBS to GitHub’s infrastructure. Note that I wrote that I believe all required pieces are there, but I only have a vague idea how to design something which does the job (which would be the first thing to evaluate: What exactly is “the job”?).
A single “volunteer” is very likely insufficient to develop and document this, plus to maintain it in then long run, because as soon as people start to rely on this, (s)he will be on vacation, ill, … (any other reason to be unavailable) when this direly requires maintenance. Note that this job can become quite stressful each time a new SailfishOS version is released.
Thus IMO this requires a team of at least three committed volunteers or somebody paid and equally committed.
although I agree in principle, the Github actions can be made into a template shared on Github itself which makes that part very simple with @coderus images. Making that available as repositories is not much more than creating the requisite directories and filling them with rpms which could be accomplished with a simple webhook. I realize I’m simplifying, but for the sake of argument, the repository is nothing more than a web server with a service that collects rpms. I think I’ll do a proof of concept.
Having at least 2 volunteers in the loop does make sense, but we should be able to find more!
