-
I would suggest having a look at openSUSE instead of debian. In fact, I’m hoping that SailfishOS will transform into rolling releases the way Tumbleweed and Slowroll gives users the choice of just how bleeding edge the user wants to be. OpenSUSE also uses RPM packages handled by zypper. …and I think at least some SailfishOS packages are built on openSUSE’s Open Build Service already.
-
A phone based desktop system could be something in between a mobile and a stationary, imho. The hardware more or less demands a light-weight desktop environment and it would only need a subset of the applications and those would be adapted for the environment. Basically it is a matter of seeing how far SailfishOS can be stretched towards the desktop and not how far the desktop can be shrunk into the phone. I’ve been thinking for years about such a desktop light as it would be a perfect match for my future (off grid) home.
This is easy - just do testing branch and stable selectable in software updates in settings.
The hard part would be the whole rest of system, so handling 2 branches.
Yes, having two “speeds” for the OS releases is pretty simple. The real problems occur when going from versioned (numbered?) releases to rolling ones. Most users are accustomed to having a “stable” base system that maybe only changes with a few updates here and there until the next “stable” version of the OS (finally) is released. The main advantage of having a rolling release instead is that it allows smaller upgrades to be made in shorter cycles than a traditional versioned release. Developers can focus on improving smaller sections of the OS and publish those improvements sooner.
A second, more moderate, rolling release could then allow for more testing of the software packages before release and would also require less updates.
As a comparison, my main computers (I run two Arm-based ones in parallel) are currently running openSUSE Tumbleweed because the development of device drivers (such as for the GPU) has been very volatile. Now that most of my system has fully functional drivers I could very well change from Tumbleweed to the other rolling release – Slowroll. Changing to Slowroll would minimise some of the risks of being on the cutting edge and also keep changes small for me, both as downloads and in daily use.
Similarly Jolla could have two operating systems to use with their phones…
- Sailfish - A rolling release with a shorter release cycle than today.
- Bonito - A more moderate and polished rolling release.
(I suggested Bonito because it means “beautiful”, it is the sixth fastest fish and a main ingredient in miso soup, one of my favourite dishes.)
Well… I’m not sure that It should look just like this. I would rather prefer for them to have a release schedule similar to Fedora for normal people & specific testing branch will all the new stuff, but really for testing. Actually I think that they have this, but I don’t have access to it - it’s really only for developers.
Fedora’s development channel is called Rawhide and yes, it is not for normal users. …unless they like adventures.
Having a specific release schedule? A Sailfish release simply isn’t advertised in advance. We always have to speculate until it is released, whenever that is. So personally I would prefer to have the small but frequent upgrades of a rolling release. …especially when combined with automated quality assessment tools.
The dev channel of Sailfish has been kept behind Jolla’s locked doors but now the source code is slowly becoming open. On top of that there’s a debate on how to improve the integration of the “other” repositories (OpenRepos and Chum). Those things together suggest that we’re moving to a dev model closer to openSUSE’s Tumbleweed than that of Fedora’s Rawhide.
Versioned releases have one problem that rolling ones don’t have and that is that most users have no fear with updating their systems but shy away from version upgrades. A rolling release removes that perceived threshold. …and by the way… Users don’t like to wait for stability. They’ll take whatever they can get right now. Take a look at how web browsers are treated, as just one example. If people really want new things delivered yesterday then a rolling release seems like the best way to give them that.
A second rolling release, like the fictitious Bonito mentioned in my earlier reply, would still be fresh but add a wider safety buffer to the dangers of the development frontier. If Jolla’s operating systems are adopted by bigger organisations, companies and institutes then it is quite possible that their tech support staff would prefer the slower release cycle.
Well. I still wouldn’t just push some big changes ,on the Friday evening”. As a user of Fedora Silverblue I can only tell, that I had maybe few small issues with things going slower than for example Arch, but it was stable and feature up to date enough for me, that I don’t really care anymore. Maybe that’s because of apps being Flatpaks, so they just update whenever they need.
Running not super early release has a plus - you have more time to track issues and repair them. Of course LTS would have less problems (ideally) and then you only do security updates, but going the whole other direction I would consider a wrong choice for a mobile OS. Breaking changes introduced just tomorrow is a wrong idea (for example QT6 right now, when most of the apps are not gonna end up ported to it in a moment, right? Or I’m just dumb? 
)
I split this in it’s own thread as it is an interesting topic and we have have been thinking about it at Jolla.
For the “normal” users we will stay with the versioned releases. It is just easier for testing and investigating issues when the OS version guarantees a certain set of package versions. Committing to specific release schedule on that is currently not feasible, due to our limited resources.
But a public rolling-release developer channel is something we have been considering. Specially now that we are opening more of the components for contributions, it would be important that contributors can build and test their changes against the “live” development branch of the OS. And it would also be a benefit when we update low level things, like gcc, glibc, etc., that all the community maintained things can be built, tested, and adapted to those well in advance before the public release to the normal users.
If and how and when this will happen is still very unclear (I have a feeling we will be quite busy in the coming months 
), but would love to hear broader opinions and ideas around this subject.
Personally, rather than a real rolling release model (which is kind of a cult / fanboy thing popularized by Arch but of course has existed before Arch), I’d prefer a ‘fixes’ release channel based on the released version. This is for ‘end user devices’/production.
This could mitigate the issue that smaller bugfixes often take rather long to see the light of day due to proper releases being a bit far apart.
For development however, I think a ‘preview’ (bleeding edge) and a ‘next’ (next release branch) environment would be helpful.
Once the dev channel is a rolling release the choice to switch the user channel to a rolling release would be fairly easy.
- Sailfish would continue to be a versioned release for a while.
- A new rolling release for development and testing would be adopted.
- Sailfish would become a slowrolling release.
But… The sailfish is the fastest fish in the sea. What would you call the development channel? It would be faster than a Sailfish, after all.
That is what a typical versioned Linux distribution would call an updates repository.
Barracuda. But I think that’s my ego talking (at the urging of my deeper id).
I would welcome something like debian unstable … It’s been a while, but for years I ran rolling release / unstable and actually found it beneficial.
Bacaruda is too hard to say. (Babararacucudada, if you’ve heard the ad.)
I always feel the need to interject at statements like these. A real rolling release is far less error prone than the haters make it sound, but also not as cutting edge as the lovers like to think.
In fact, it has very little to do with always having the newest software - after all, Arch devs could be testing software for months before releasing it into the main repos. And they do test it, but usually not for long. It’s just a different way of upgrading the OS, and with a few simple rules (like “partial upgrades are not supported”) it can be pretty stable.
But I have no opinion about this wrt SFOS, just wanted to get rid of my “ackshuly”.
just having the ‘next’ target available earlier in sfdk (and obs) would simplify things like gecko or compositor development a lot already and should not be much effort?
I just wrote 700 words. Thought about it. Erased it. I’d like some compromise between gentoo overlays, ephemeral containers and debian unstable (or suse unstable, or redhat unstable). So, probably suse unstable.
I should add one thing. The rolling release model / unstable, doesn’t really help me if the point of departure is far in the past. One thing I would like to accomplish is related to
ffmpeg. We are woefully behind. Even if I move to libav (ie.python hacks to c++) away from abusing the binary, we’re still WAY behind. Does our rolling release in anyway get us close to modern (say, version 7 off ffmpeg / libav?) If I can contribute (ie. a few compilation flags to get some much needed bits active) I’d be pleased. But, a lot of what I do cannot be ‘backported’.
Is the old cbeta program still around? Could it be made into some kind of cumulative live version of the developement for the next release until it’s time to lock it down to RC, and then start over, when the new version is released to everyone?
Don’t know the ad reference, so all I can hear in my mind is the song by the band Heart
Exactly what I was going for It does show my age ….
Just a stupid car ad, nothing to be hanging on a heart attack for. But the J2 to be J3 would be heartwarming (sorry for the very strained album reference).