@rainemak Do you think it might be useful to write emails to appropriate Sony department that we want to see more timely cooperation with Jolla?
4 Likes
According to what @rainemak said, Jolla intended to use the existing Android 14 binaries (which have been available since early June, i.e. for almost 3 months), just with temporarily disabled camera service. Then when at one point new fixed Android 14 binaries come out, they said they’d release an update to re-enable the camera. So it doesn’t look like it is Sony to blame for the continued delays, because it’s not lack of Sony binaries what still prevents Jolla from releasing the promised initial 10 IV / V support.
1 Like
AFAIK that was the initial plan, but they changed their mind and decided that having a totally non-functional camera was a non-starter. Lets hope Sony can get that fixed binary out the door soon.
But then again it’s on Sony’s side, because with their binaries camera isn’t working
Ain’t there also issues with the new telephony stack - or do these only relate to the C2?
Kindly point us to where it was ever stated so by anyone from Jolla.
The very last information from Jolla regarding 10 IV / V support that can be found on this forum is this:
We asked from you, Sailfish Community, an opinion on how would you prefer this and seems that preferred approach is to release the free version quickly rather than waiting for the new vendor blobs. This means that the first version comes with disabled camera service. Reason for disabling is that broken camera service prevents suspend causing battery draining. Once we have the new Android 14 vendor blobs containing needed changes to fix the camera service, we do a minor Sailfish OS update to re-enable camera and provide instructions on how to flash the vendor blobs.
It was posted by @rainemak on August 1st, i.e. 4 weeks ago. Since then, no single update was ever posted.
Or, as I said, if you know any statement newer than the above, please kindly point us to it.
The 10 IV / V uses SFOS 4.6 (rather than 5 as the C2), i.e. the exact same as current Xperia models, e.g. the 10 III, and hence the same “old” telephony stack as them. Meaning that this issue does not affect Sailfish X for the Xperias.
Sure. But it still doesn’t have connection with Jolla not releasing the first version with disabled camera, as announced by @rainemak.
Anyway, as you’ve probably noticed, rainemak was quite active on the forums today and posted multiple comments, mostly regarding the C2, but he also greeted newcomers. Sadly, he didn’t find time to post any update regarding the 10 IV / V support.
1 Like
As pointed out in this thread, an official statement like this is not easy to find.
I’d say it’s an easy assumption, or something one’s brain might trick into thinking, when there’s extended radio silence.
It would be a bit sad if the goalposts got shifted, and now we’re waiting for a working camera, when so many people would be willing and happy beta-testers without camera.
Rather than ‘not easy to find’, I would say that it is simply not existing.
To sum up how it’s been looking so far:
-
First we waited several months for the decision whether they would support the 10 IV / V or not. It took them from February until May before they eventually confirmed that they would. At this point I shelled out some 350 euros on what since then has been catching dust in my drawer.
-
In May we’ve heard that it would come out “in 1-2 months”
-
Then not a word until end of July, i.e. ~ 2.5 months
-
Then we were told that rather than using Android 13 blobs, they will use Android 14
-
On August 1 we were told that due to an issue with camera in current Android 14 blobs, they won’t keep us waiting until fix is provided by Sony but instead they will release the first version with camera disabled, which they will then re-enable at some point when fixed binaries come out.
-
And that was the last time we’ve heard anything, a month ago.
It’s not only that. It’s also a matter of either being men of their word, respecting those who keep waiting and relying on what they say, or not.
2 Likes
Yeah, all of that. My gut told me at the time, some of those times, even, that maybe the community should start doing a port despite the missing features.
I didn’t make too much noise about the idea, because usually the community by and large won’t have the time or skills or whatever.
Then it felt like a futile effort because the release is coming.
And to top it off, I don’t know how much of a change the Android 14 switch would have been.
For me (“personally”) it would also have really helped if it was known that a community build could change its repos once Jolla makes the release and make the transition seamlessly.
In retrospect it seems that maybe all of that should have happened anyway 
I’ve also had my 10iv since forever and this is trying my patience as well.
Too bad I really hate every Android ui I’ve seen, because what’ll end up happening is @rainemak or someone releases the thing, I’ll be content with it, and once all functionality is in place, I won’t remember much except that “some business reasons like that phone and that AI/ML toy” made this take an insane time.
If there was a Sailfish skin for Android, right now, I’d seriously consider jumping ship.
The anger and frustration will blow over, but for all I care now, even releasing the build system so we can do this ourselves would feel like a boon.
3 Likes
Following this discussion makes me think that we should have a separate category for the releasing and releases. I think Announcement is good for different kind one-off announcements but it’s a bit difficult to spot the right topics. At last week’s community IRC meeting @flypig asked which topics should be followed regarding different updates. To me this further emphasize that there’s something to adapt / adjust / fix / improve.
We have Announcement, Platform Development, Hardware Adaptation, Bug Reports and Devices that are all good for a dedicated topic like this topic. However, building a complete picture requires kind of combining various topics. Support for a hardware requires adaptation work which is integrated to a release. A release in turn has different features/bug fixes/etc that would link to Platform Development and Bug Reports (or even Feature Requests). When a release is published we do an announcement. I’d like to see these different angles discussed and communicated in one place so that we all could easily find them. Does this make sense to you? Are you following my thinking?
Maybe @jovirkku has an idea as well?
5 Likes
Thing is, if we wouldn’t love this OS for so many reasons probably none of us would be still here- but even that has it’s limits imho.
I’d try to make a Android13 build, but I couldn’t get through the docs in my limited time so far to have a working platform, quite some stuff seems outdated or refer to cyanogen or lineage, some commands plain do not work when following the docs here: Sailfish X Xperia Android 13 Build and Flash | Sailfish OS Documentation
, then there is this sdk installer which appears to work and placed some VM’s in my VirtualBox, but then I do not know where to continue from this point, etc. etc.
Might be because I am old fart already with decreasing brain capacity, it’s really confusing.
1 Like
I think even a single “WIP” topic for each the different devices would be already sufficient.
2 Likes
I don’t have a good answer to this. Maybe one thread per phone release with all the updates and more-or-less official comms, no matter the aspect.
What I do know is that I have enough respect for @jovirkku - and his decades of experience - to take whatever he’d propose seriously when it comes to flushing a release pipeline.
Maybe the reason this is now rough to think about is that it feels a bit like bike-shedding.
Whatever the solution for communication ends up being, it would be dope if it came soon and with something tangible
2 Likes
I must congratulate you on noticing and articulating the systemic issue plaguing the Jolla’s communications.
Here is my proposition how to do better:
-
Set up a process, where once a week Jolla reports what has been done in the last seven days. The report would be a list of officially supported devices, where each device would have bullet points explaining work done, ideally with links to commits and other evidence. The various device variants should be combined to prevent unnecessary work duplication.
-
The report contents should be written immediately upon conclusion of the described work, to avoid issues with deadlines and unexpected situations. I suggest to publish the report early in a week to be ready for unexpected community reactions, or other community engagement.
-
If nothing has been done with a device, do not omit it from the report. Instead, state that “nothing was done”. It is important, because having this entry forces you to continuously acknowledge that you support the device, until it is removed from the official support. On the reader’s side, it shows that you do track the work done on the specific device.
-
Similarly to the hardware report, it would be very nice to have a system report with developments regarding the operating system in general. It is also a great opportunity to engage the community more deeply than the current state of “are we there yet”?
1 Like
I bought a device two months ago. The last dead line was July. I will accept the beta version without a camera but this version is not available now too. So, could we be sure that our devices will get an image this year? I like this os but I’m a little bit sad that my 10V will be not used and is in my drawer 
4 Likes
While every point is formally correct, the chosen language is too harsh IMO. Please take into account where Jolla and its company “culture” is coming from: Never telling anything about content, structure, decision making and planned timelines of their releases. In the past, what Jolla released when was basically their only communication about SailfishOS releases (i.e. zero information was provided in advance), a fact which I often and strongly criticised, especially for the negative, disruptive effects that has for software developers (“hey a surprise for you, we just broke your apps, again”).
In the past few years Jolla improved significantly in this regard and still seems to be on that trajectory (i.e. @rainemak participating in general discussion threads as this one, @jovirkku in many more technical discussions and other sailors when a discussion touches their work, e.g. @pvuorela): Thank you all for doing that despite some backslash), hence criticism should account for that, even though communication is still not fully satisfactory (e.g. compared to other Linux distributors, as RedHat for Fedora or SUSE for OpenSUSE).
P.S.: After all, this is still software development with scarce resources and some external dependencies (e.g. to Sony’s firmwares and software binaries, to many upstream FOSS projects etc.), hence recurring delays are to be expected.
16 Likes
@Obikawa, are you aware how much of the available resources will go into writing these reports? Furthermore, this is something developers really hate (including me): Instead of progressing with the piles of work ahead, writing reports about the few things one achieved (within a week it will never be much).
Are you aware that most of the work you want to be informed of is happening in the open? You can simply take a look!
Hence I rather wish that Jolla performs even more work directly in the open, instead of staging stuff in their internal source code repositories.
Ultimately, the SCM changelogs @dcaliste gathers already cover most of what you ask for and Jolla provides their biweekly community news: These do provide the regular progress information you are asking for.
16 Likes
This is something I am currently experiencing, by pushing myself to do increasingly more work with Emacs, Org Roam and setting up workflows and infrastructure for future Literate Programming, on my to-be-built website. This particular problem is a problem of preparation.
However, my intention was a bit different — the previous post is a bag of seeds, thrown with hope of at least one sprouting properly. It is an inspirational idea, an image to think about. The best solutions are those combining many different base concepts — take the A* algorithm for example: it combines two ineffective approaches to routing in order to provide truly efficient results.
Each time I take a look at Sailfish Github, I find myself lost within hundreds of forks and subprojects. This is a very opaque approach to open development. It is a difficult, cultural issue and I am not prepared to argue with it. It takes active consideration each day to balance clarity of a monolithic foundation against versatility of a modular foundation.
Personally, I am not able to comprehend the workspace of Sailfish development, which effectively renders the process closed to me. All I have are the Community News and miscellaneous forum threads I decide to follow.
Maybe. But it’s a result of more than half a year of waiting, not even for the product itself, but actually for any reliable information. I’ve been waiting since February or so, and I still can’t know even just if it is going to take one more week or rather another half a year.
And therefore it’s not about pushing them to release the product (I don’t think one can find any comment of mine demanding that) but merely to inform us with some reasonable frequency.
2 Likes
Sigh, I have been waiting 10 years for Jolla to provide a release of SailfishOS, I would not clearly define as a beta release.
“And I still can’t know even just if it is going to take one more week or rather another half a year” or multiple years or a another decade or if Jolla will go bankrupt before that without being saved (as it fortunately happened at least twice, i.e. “being saved” in the last minute).
Go use UB ports (ex Ubuntu mobile), PostmarketOS or any other “mobile Linux distribution” (which open source Android distros (AOSP forks) are not): I am pretty sure you will gladly return after a while, despite all shortcomings of SailfishOS and Jolla.
14 Likes