OBS shut down and next steps

[JoOppen]

The underlying problem appears to be that the community is small and not even growing. At least this my impression, not knowing any figures.

In this situation, Jolla has to decide how to deal with the community. Apparently Jolla is trying to reduce the effort spend for community issues to a minimum - which of course has a negative impact on the community.

@atlochowski has clearly expressed the impression: community does not matter (anymore) to Jolla. Please let me be clear: I mean, this is the impression. Maybe it is not, what Jolla is intending. However, just saying the community is important will not be enough.

At the beginning we all had hopes that Jolla would be successfull in the consumer market (Jolla 1, Tablet, Aquafish were all addressing the consumer market). For reasons I do not know - and despite a good UI, access to at least some Android apps etc. - these hopes did not materialize. Does this mean, Jolla should stop dreaming and cutting ties with the community as a consequence? I do not know, but leting the ties slowly die is even worse.

@rinigus correctly addressed to economic aspect. If Jolla cannot afford to maintain an infrastructure that helps developing apps for Sailfish, then this might be bitter truth and might kill Sailfish X - and even this forum would be obsolete.

The migration to this forum indicates that Jolla has not yet decided against the community. To give Sailfih X a chance, Jolla should make developing apps for SFOS as easy as possible.

So it is not (only) a question of communication, but also (and even more so) a question of mere facts (i.e. tools for devs, for instance)

[vige]

@JoOppen

The migration to this forum indicates that Jolla has not yet decided against the community. To give Sailfih X a chance, Jolla should make developing apps for SFOS as easy as possible.

That’s exactly what we are trying to do. What seems to be forgotten in this discussion is that we have quite a rich set of tools for developing apps: https://sailfishos.org/wiki/Application_Development#Software_Development_Kit

OBS is not used by the majority of app developers, and it can not be considered easy to use, at least if you compare it to our SDK. We have spent quite a lot of effort improving the SDK - during the last two years we have introduced command line tool sfdk, cmake support, docker based build engine for improved performance (while improving also the VirtualBox based build engine). It’s definitely not perfect yet, and we will keep on improving it in the future as well.

[veskuh]

@JoOppen

Apparently Jolla is trying to reduce the effort spend for community issues to a minimum - which of course has a negative impact on the community.

We try to use the efforts in efficient way. Many of the public services we provide need maintenance, improvement and updates: Shop, Jolla Store, jolla.com, sailfishos.org, harbour, this forum and so on. The services all need time and effort from the same team and we haven’t been able to keep up with maintenance needs as well as we would like. That is why we believe that we need to reduce effort on the less used services, so that we can spend more time on maintaining the more popular ones.

[rinigus]

@veskuh

That is why we believe that we need to reduce effort on the less used services, so that we can spend more time on maintaining the more popular ones.

If the maintenance is the main reason, we could look into how to share OBS administration with the community members. We would probably have to look into reduction of admin effort required by OBS, but this is completely different approach when compared to shutting it down. In particular, it would keep ability to build from source to distribution of the packages in one go. As mentioned above, such stack as provided by OBS, allows to work on complex apps, in addition to the well-known ports case.

@vige, the stack for apps development is good, indeed. Especially for regular apps. We are over here talking about more complex cases and ability to distribute the work (ports and apps) through OBS. Surely it is not used by majority of app developers, as there is no need. But it does benefit some apps. As for ports, OBS is something that is highly recommended before publishing the port.

[r0kk3rz]

The fact that everyone here seems focussed solely on apps development shows you’re missing the point.

OBS is useful for developing and extending the sailfish platform itself, with a number of community contributions being developed on there.

There is also nemomobile who use it as their primary package source, with lots of work going into testing with newer Qt, GCC, and full arm 64 builds.

All of this has material benefit for sailfish, and removing OBS as a central workspace will make it harder to build upon the work of others and collaborate on things which benefit sailfish as a whole

[piggz]

So far, rinigus has nicely covered how OBS is useful for managing complex apps with many deps, and r0kk3rz has covered how OBS is used by other parts of our community such as nemo.

Im sure you know the use cases already, but I just want to ensure that whatever you come up with as a replacement also meets the needs of porters.

1. OBS allows us to easily manage development and release builds and promote from one to the other
2. OBS allows us to easily maintain releases for different sailfish versions, and allows users to use this to upgrade between releases
3. OBS provides a common location to host releases. I cannot stress enough that I would not want the hassle of maintaining my own server space for the release repositories. All ports get to share the same format URL and this provides consistency across the platform. As you are concerned about the legal issues of hosting on OBS, im intrigued how this will be managed in the future.
4. OBS provides the community common: and native-common: repos. Will the community continue to be able to feed into these repositories that are common across ports?
5. OBS allows us to quickly update and rebuild mw libraries (usually in the quick but hackish _service edit), and have dependant packages rebuilt automatically. This makes it pretty easy to trigger mass rebuilds. I wouldnt want to do this locally … im sure some porters have server setups, but im running on a 6th gen core i5 laptop, and remote builds are a dream!

Non-porter related:
6. While the SDK is great for most application development, it is not so great for building support/mw libraries. For example, Amazfish uses several KDE libraries which are built on OBS.

I hope that whatever solutions you look into will cover all these requirements for a seamless-as-possible transition.

[veskuh]

@rinigus

If the maintenance is the main reason, we could look into how to share OBS administration with the community members. We would probably have to look into reduction of admin effort required by OBS, but this is completely different approach when compared to shutting it down.

That’s an interesting suggestion worth considering, but we would also need to find some solutions to other concerns.

[rinigus]

Are the other concerns the legal part?

[vknecht]

6.1
When managers hold endless meetings, the programmers write games waste their time. When accountants talk of quarterly profits, the development budget is about to be cut. When senior scientists talk blue sky, the clouds are about to roll in.

Truly, this is not the Tao of Programming.

When managers make commitments, game programs time wasters are ignored. When accountants make long-range plans, harmony and order are about to be restored. When senior scientists address the problems at hand, the problems will soon be solved.

Truly, this is the Tao of Programming.

[tortoisedoc]

It is a fact that Jolla as a company has to act as one;
they also have customers, which pay for the lights to stay on.

Paying customers which are part of the community are just as valuable;
unless the pure business perspective is applied (revenue).
But if it comes down to this, it’s a very bad signal. If not,
Jolla should at least take the effort to reassure the community of it’s interest to work with it;
meaning, perhaps approach the topic in less direct perspectives, by stirring the discussion
from a less unilateral way.

It really comes down to what Jolla wants ( or perhaps has) to do.
They can’t share too much info as they are a company, and do not have legal rights
to talk “just” out of the box (there’s a communication strategy to be followed).
But it’s up to them to make the effort to reassure (again); so I’d expect them to at least make the effort.
Again, if this is not happening (as it unfortunately hasn’t), the bad sign goes +1 to proof (two signs/hints = 1 proof).

It seems clear something is a-miss here; we will have to wait and see.
For myself, I hope SFOS survives a bit further, and since I am optimistic, I hope for good news sun
behind the clouds.

[piggz]

To add to @rinigus argument relating to complex app builds not really being possible on the SDK, and much easier on OBS, my own app Amazfish also relies on OBS, not for the app itself, but for all the libraries it requires. On OBS, I build and package quite a few KDE Frameworks libs which make development of Amazfish possible, it would not be possible (or be quite cumbersome) to package these in the SDK, and is much better suited to building on OBS.

[coderus]

Example of Github Actions CI for building Sailfish OS rpm and upload it to Github Releases: https://github.com/coderus/screencast/actions

Example of Gitlab CI for building Sailfish OS rpm and upload it to Gitlab Releases:

Pipeline · Andrey Kozhevnikov / screencast

[attah]

Wow, this is amazing! (And deserving of its own topic maybe?)

I hope Jolla can start publishing their Docker images so this can be made more official.
Another improvement would be to wrap it in a named action that we can reuse (and not have to keep as much logic in our individual yaml files) https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action

[skvark]

The Docker images @coderus is providing are a very good alternative to OBS and they can be used with pretty much any free CI/CD system out there (Github Actions, Travis etc.). I personally moved away from OBS right away when I found out about them. Of course they do not provide same level of infrastructure as OBS but they are far more modern and easier to use than OBS. I understand why Jolla is closing OBS and it’s okay from my point of view. However, there are devs who have relied on it heavily and therefore maybe some kind of migration guide would be needed.

[KuroNeko]

Yeah, I have personally always used gitlab-ci for my apps, but from what I know, porters benefited from OBS a lot more and for them gitlab-ci/github actions is probably not an option. (You can also simplify the gitlab-ci example a bit more, if you don’t build both architectures in one go, although that may use more CI minutes.)

[rinigus]

As described above by @r0kk3rz, @piggz, and myself: this is not about simpler app (in terms of dependencies) development where Docker or current SDK would work fine. Closing OBS will hit complex projects that

• develop platform further
• ports
• complex apps relying on many libraries

These will not be helped much by Docker as we will be missing tracking of dependencies and publishing all in repos.

[coderus]

one need to create local ci scripts. repos can be added to ssu/zypper via file:// schema from local folder. this adds a lot of hassle, but doable. If you decide to keep sfos development and not give up on this platform

[skvark]

Yes, that is true, complex projects and ports may require some other solution.

Edit: I hope Gitlab package registry will have some day RPM support: https://gitlab.com/gitlab-org/gitlab/-/issues/5932

Same applies to Github package registry: https://github.com/features/packages

[rinigus]

one need to create local ci scripts. repos can be added to ssu/zypper via file:// schema from local folder. this adds a lot of hassle, but doable.

so, in principle, reproducing OBS by those scripts.

If you decide to keep sfos development and not give up on this platform

Time will tell. Right now it does not inspire to invest time into it as an open source developer. So, I prefer now to deal with other projects and see how OBS situation will get resolved.

@skvark: let’s see how that Gitlab RPM repo ‘some day’ will match our needs

[nekron]

To sum up the problem:

1. OBS can be seen as a CI
2. OBS provides a RPM package repository (as CD)
3. building of RPMs is done via RPM SPEC files that optional references dependencies from the custom build RPM repository, re-building a package will trigger all dependencies to rebuild.
4. you can chose different build targets (arm, amd64)
5. you can chose different releases (SFOS 3.3.x, 3.2.x)

Replacing this with an alternative solution would mean to provide two components: CI/CD system and repository service.

RE 1:
There are many CI/CD tools around (Jenkins, Travis, Drone, Concourse-CI). The build-pipeline per package could be scripted into CI files, i.e. downloading coderus docker image, pulling source code from github as ressource, building within docker env and pushing final RPMs into repository ressouce.
However the build job order must be resovled by the developer himself, i.e. root packages first then building child packages and so on.

That being said someone must provide the CI/CD infrastructure to solve this part of the problem.

RE 2:
That part of the story must be provided by some service provider (Github, Gitlab) or setup in the build pipeline, i.e. the creation or update of the required repository meta files will be triggered as a pipeline job on the repository. A basic http or S3 server repository will not solve this problem as “createrepo” command must be triggered locally to build the index files for all provided RPMs. A custom solution with some kind of API must be provided for CD to trigger this repository creation step.

RE 3:
If 1 and 2 are in place this should work (depends on the defined pipelines).

RE 4:
Docker build env provides both targets so arm and amd64 are supported.

RE 5:
CI scripts can define different target pipelines pulling the tagged docker image for the required SFOS release.

Pros:

• Docker-based CI guarantees clean builds
• CI scripts can be hosted inside the git repo (one source of truth also for the source code as you don’t need to clone a local copy into OBS)
• Build process for independant RPMs can be parallized if there are multiple worker nodes
• Pipelines allow dependencies, i.e. some staging job like a testcase fails so the complete pipeline will stop
• Supports different resources for input and output (Github, Gist, S3 …) of source code and builds
• more control for the developer as he defines the pipelines and what should be done
• use a CI/CD tool that fits the job (CI/CD tool maintenance should be much lower than full OBS setup)

Cons:

• more scripting (pipelines, shellscripts) needed
• will take some effort to migrate packages to CI/CD pipeline
• needs an external repository with some createrepo magic that can be triggered via CI/CD or service provider offering this feature
• decentralized (devs will host their own CI/CD + repository)

Verdict:

In the end it comes to the situation that community will have a fragmented build and repository space for non-harbour compliant applications.

Jolla should consider if:

• hosting a community repository with createrepo task / API is feasible
• providing a docker-based CI/CD for automatic build pipelines (much lower maintenance instead of OBS, community has centralized CI/CD and repository for their work). I personally would suggest Concourse-CI here.