News and Update
UBports Q&A 112 on 20 November 2021.
Dalton and Marius presented this time.
Go to devices.ubuntu-touch.io for info about whether your device is supported. The documentation to help people port devices to UT has been greatly expanded and improved, so make sure to check it out.
Clickable version 7
First off, Clickable version 7 is out for testing. Just to explain, this is the desktop app which handles all aspects of building, uploading, versioning and maintaining for apps made for the Ubuntu Touch OS. Version 7 is a huge step up from version 6. For those who are used to chaining commands together they now have the ability to use ‘Chain’ command explicitly, to avoid confusion with other syntaxes.
If you import libraries to function with your app, you can now use the Clickable build command itself to incorporate those. clickable.json has been removed and you now have clickable.jaml. You could still use .json if you feel you must but .jaml is just much cleaner and easier to read. For new users it will be much simpler to understand and if developers want to ‘borrow’ existing code, that will be much less of a hassle to do. There have been a lot of other changes, notably some improvements to Rust integration. If you are struggling a bit with making the transition from 6 to 7, a tool is available to help you and that has been built in Rust! [Dalton made a joke about Rust and ‘Fanfare’ so obscure that I have no clue what it was about but you get 7 zillion geek points if you get it].
Big thanks to the Clickable team for their amazing efforts on this new version.
To pat ourselves on the back, Clickable is the kind of comprehensive app building environment that you just don’t find with other operating systems. It is a real breath of fresh air and something we can be proud of.
OpenStore new apps
In new apps, we have Simple Reader by Nicolas Colla. Just as it says, it is wildly simple. You just open an ePub file and there it is, including a very cool sepia rendering. Also from Nicolas is Headline, which is an RSS news reader. In addition to those we have a game, Costumemaster Reloaded. Finally there is a de-compressor for compressed files, called UT zipper but actually with the ability to handle a range of formats, not just Zip. This app is by LionelD [the French Lionel :)].
OTA-20 release
OTA-20 is now making its way out of the servers. The rollout should be complete by around Wednesday. As usual, this is something you can do on your phone. Just go to Settings: Updates having made sure all your apps are up-to-date. There was a nasty bug which prevented some users from granting permissions to new applications and there was another which blocked the use of calendar features which relied on LetsEncrypt. Volla had a particular bug which closed both calls if you were already in one and rejected the incoming one. Happily also fixed. A big shout-out to everyone who worked on the update! Just to be clear, OTA-20 is for all UT devices apart from PineTab and PinePhone because their build is fundamentally different.
For the time being, Florian has taken over the job of Release Manager for these updates, to enable Dalton to focus his attention on other tasks. Huge thanks go to him.
20.04 news
In Focal, the headline news is that the Ayatana indicators are now being added to the build. This will have a visual impact much greater than the physical size of the change because at last the interface will start to look complete and familiar. There is still a long way to go but this will be progress you can actually see. Aside from that, we have begun early builds for the Volla phone, which is our chosen test device for Android 9 derived builds. There has been a lot of catching up with ‘technical debt’ where we have made lots of changes just to accommodate a range of quite different builds.
Telephony and ofono modules are beginning to be integrated nicely, forming the basis of traditional ‘phone’ functions.
Just to emphasise, this work is not just about switching Xenial for Focal on a like-for-like basis. At the same time a lot of changes are being made, particularly to ease the path for future upgrades. That applies particularly to merging the changes into Debian.
This week Dalton created a project board as an overview of progress. Epics on Gitlab are great but KanBan provides a great visual representation.
We have a small but great team but there are other elements essential to the mix of things which allow us to progress. What we provide, whether the OS itself, the technical support or the apps cost users absolutely nothing. If that looks too good to be true it probably is too good to be true. Dalton asked users to consider the value they get from all of this, including the cash they save by not spending money on paid apps. To continue, we can’t live just on fresh air. We appeal to users to send some serious money to the Foundation via the usual donation channels, to keep the show on the road. There is no unseen magic supply of money that keeps us afloat without user support. With other OS options you may get stuff for free in money terms but the deal is that you are the product in the transaction. Your profile as a consumer is being bought and sold. We don’t do that.
Remember that apart from UBports and the OS, there are many volunteer app builders and it would be nice to send some donations in their direction too, to show thanks.
Sponsors were thanked. Not all of the individual sponsors are identified to us (for example on Liberapay) but if anyone who has given would like a personal mention on air, just drop Dalton a message and it shall be done.
Questions
The News section of our Forum is the best place to post questions for the Q&A. YouTube live chat,Telegram and Matrix are other places to post a question.
If you didn't know, the Forum questions get priority.
Morph notifications
Nicolas Colla [of above app fame] asked about the possibility of rudimentary web notifications in Morph browser. Could that come to HTML5 applications any time soon? The situation now is that if you have Morph browser open and in the foreground and if there is enough spare memory in your system with the number of tabs open, you will receive notifications from the open tabs. If Morph is suspended or closed or even put in the background that stops. Web applications behave in exactly the same way although as they are effectively ‘one tab’ there would be no point in notifications anyway, if they are in focus.
Extending this basic facility would be possible by making a webpush to the UBports server but there are certainly some people who would be concerned about the privacy implications of doing that. An alternative is to change the notifications architecture of UT so that it becomes based on webpush. It could be done but as always, resources, resources…
Ubuntu Touch 20.04 and device support commitment rules
Recently we have been getting a lot of questions about which devices will or will not be supported when we move to 20.04. Whenever this subject comes up there is push-back because understandably, users want ‘their’ device to continue to get support. Now that we are getting nearer that time, we need some honest and realistic answers, which of course will not keep everyone happy because life isn’t like that.
One small practical example of the type of everyday issue we deal with was a report that the splash screen appears upside down on the PineTab. It is cosmetic. It has no effect on function but even so there is a possible fix. We know how to fix it and it isn’t especially complicated but the bottom line is that while Dalton could do it and knows how to do it, he simply doesn’t have the time to do it. Although that quirk doesn’t matter much, if we don’t even have the practical resources to cover something that simple and trivial, what does it say about the quality of support we can offer for that device? The upshot of the discussion around that and the conclusion that if we can’t support it properly then we shouldn’t support it at all was responses like “but the PineTab is my device and the only one I have that runs UT”. This is very upsetting and it doesn’t feel great letting people down. The bottom line though is that we have to manage our responsibilities in a way that is sustainable and where we are at the moment is not sustainable. Period.
It is a fact that devices which are now very old and don’t have the greatest hardware will not be making it into Focal. Going back to the PineTab example, it is still getting nightly updates but it is getting no attention to the kernel and we cannot do anything about that. Also, if something fundamentally breaks on it, we just do not have the resources needed to fix it.
Recently, Dalton spent around a week doing some partial kernel patching for the Fairphone 2, to try to keep that device in the game. It has basically a heavily patched 3.4 kernel. This was about workarounds just for Xenial. At the end of that process it was very clear that it wasn’t an end at all. The need for more patches will just grow and grow. Keeping it on life support will go on sucking in more and more time, unless we draw a line under it and move on.
The kernel patching for Fairphone 2 was courtesy of Lineage OS and Marius referred to the fact that they are a good example of an organization which operates some strict rules about their support efforts. We can learn from them. They insist on minimum levels of commitment from maintainers before a device will be supported on their infrastructure. If that support wanes, devices are removed. As with other projects, the device will remain in the community list in case someone else wants to step in and take over the maintenance role but there is no sentimentalism because they too have finite resources. They and we cannot do everything.
The move to Focal will not happen automatically for everything on our Devices page. Maintainers will have a big role in making the necessary adjustments and if they don’t do that for their device, it will not get Focal.
We obviously need to spell out what work will be involved in the transition and we also need to start talking transition dates.
The reason for working on the Fairphone at all was that is was the only 32bit device we have that still enjoys any kind of following.
One theoretical approach we could take with Focal would be to dumb it down to the extent that it would get by without major conflicts with the variety of aged devices out there. Of course it would then run pretty horribly on every device we have. Quite simply, that approach would not be responsible or serious.
To be sustainable and have a future, we need guidelines about quality and a mechanism which automatically kicks devices out of our support infrastructure if that quality cannot be met. Each device should be capable of reaching a check mark pass before it proceeds to the next release.
Debian is another organization which manages its resources carefully. In their case, packages rejected for core support are put out for ‘package adoption’ rather than being directly junked.
To be clear, we can’t apply this tight management approach to Xenial. It has too much history and will not be around for much longer anyway. It will be built into the management of Focal though. Things will tighten up for that because they have to.
If UT is run on any device and turns out to be a mess, that impacts the entire reputation of UBports. Switching to a different device would give you a massively better experience but the damage would still have been done, as we are learning with Xenial.
Does anybody out there really want to run a device as daily driver when it has major defects? Well we don’t want that either. If a device goes into the installer, we want it to be a good device. It is a fact that quality criteria will be applied for 20.04 migration but this is the start of a discussion about how exactly that will happen.
See you next time :-)