-
I get this question a lot, why focus on making Lomiri compatible with upstream components and why are you helping getting Lomiri into different distros? Why not focus on Ubuntu Touch? Why focus on making UbuntuTouch better? Why not make device X better right now!
And for many this choice of development direction might sound weird, and I get that, it's hard to know this if you’re not a developer working on these components. So i’ll try to explain why this is the best way for us to keep going.
The fact is that, focus on making Lomiri compatible with upstream components and making it possible for Lomiri to enter more distros will make Ubuntu Touch better, and much much better in the long run. This is a long term plan to make the Lomiri stack much better.
Doing upstream work greatly improves the support to all the components we heavenly depend on, so for us to upgrade our stack (like Bluez, NetworkManager, ofono and MANY others) we really need to make our source both buildable, usable and comparable with upstream non ubuntu patched components, as we cant maintain components like canonical did, so we really need to depend on upstream fixes. and to be honest this is better then what canonical did, as you can see what state we are in due to that. A great example is bluez, we are way behind upstream here, this is mostly due to the xenial base that again is due to our stack depending on xenial specific patches that makes it impossible to just upgrade base or even bluez without doing heavy porting.
Yes there will be a period where fixes for devices won't be prioritized, but for us to fix those now and later need to fix them all over again because we just made our own little fork is a sure death for us. We need to make a sustainable road head of us and not keep working on our little buble. This has been an issue with ubuntu touch from the beginning, it was only canonical doing the work with no outside contributors, this is something we really want to avoid. We need to make Lomiri a Linux desktop environment not only a Ubuntu Touch one.
Yes devices will be prioritized, but we need to follow upstream and get up to speed with all the great fixes we simply can't use.
Once this work is done, we don't need to worry about it anymore, as keeping up with upstream will be so much easier. Most of the work is to replace the ubuntu only patches that really do not solve anything other than making it much harder for us to upgrade our base to for example 20.04 or even pull in never fixes that will fix many of our issues.
But most important of all, when we are fully compatible, we will get more distro supported, this in turn will have many more developers looking and trying out Lomiri. This will greatly improve the system as we will get more contributions! An example for this is Luca from pmOS, he has done amazing work that we all enjoy today. And we need more developers like Luca to make Lomiri more awesome! We need to get out of our little Ubuntu Touch bubble and work with the huge Linux community, this will make Ubuntu Touch SHINE
-
@mariogrip Perhaps this could be (part of) a sticky for those who don't visit the forum often? I had already read about your upstream work and the advantages it brings elsewhere on the forum. But for those who didn't, it helps in understanding the choices made and the goals behind it.
Regular user, UT since 2020, Now: Volla Phone (20.04 Stable)
-
@mariogrip
True, "alone in the dark" is not a good path ^^ -
And I would like to add this related discussion/rant to it:
https://forums.ubports.com/topic/4648/what-do-you-think-use-only-lomiri-as-poweruser -
Thank you very much @mariogrip for taking the time to write this. I am one of those users who are still fighting with daily bugs years after the official support of the Fairphone 2, and I tend to be critical about why aren't them getting fixed (god damn it!
).But I fully agree with everything you say here, and to see it written black on white help me to be more patient. Thanks again.
/me go back improving Axolotl, as the whole UT ecosystem needs to be pushed forward.
-
@Alter
Thanks for your suggestion.
We decided the "General" category will be good so it won't get lost.It's a done thing (copied and pinned).
-
@mariogrip said in The road(map) explained:
We need to make Lomiri a Linux desktop environment not only a Ubuntu Touch one.
I am not a developer but I acually didn't get that before. Why working with 3 people on the environment and the distribution. To me it makes much more sense - considering the work capacity Ubports has - to concentrate on Lomiri and leaving the "other work" to Debian, Manjaro, Fedora etc...
In addition to that bringing Lomiri to Manjaro, Debian etc... will open a new pool of user and developer for Ubports. That will improve the ecosystem as a whole - more natives apps etc...
-
@AppLee Thanks for pinning the item!
-
@makeixo said in The road(map) explained:
To me it makes much more sense - considering the work capacity Ubports has - to concentrate on Lomiri and leaving the "other work" to Debian, Manjaro, Fedora etc...
uTouch is particular in its maner to handle apps and data, it's a sandboxed GNU/Linux by design, created for phones in its beginning.
-
@poVoq said in The road(map) explained:
And I would like to add this related discussion/rant to it:
https://forums.ubports.com/topic/4648/what-do-you-think-use-only-lomiri-as-poweruser@mariogrip and/or @UniSuperBox and/or @dobey and/or @Flohack and/or @NeoTheThird (and/or others):
I fully support UT and appreciate the many benefits that it brings. Even so, I'd like to propose that the UBports devs consider an approach similar to what @poVoq proposes, namely:
Please consider offering a highly experimental (extra-edgy?) "Ubuntu Lomiri" build for the PinePhone that's based on nearly stock Ubuntu 20.04, but otherwise highly similar to "Manjaro Lomiri" build.
Although I agree with @poVoq's notion that many "power users" would appreciate such a build, that's not among my top reasons for requesting one. Rather, my top reasons reasons for requesting such a build for the PinePhone include the following:
-
Creating such an "extra-edgy" build based on nearly stock Ubuntu 20.04 would necessitate (and hopefully facilitate) a move from upstart to systemd.
-
Once the move to systemd is complete, snapd could be supported.
-
Having official snapd support for a PinePhone build would benefit those who wish to repackage clicks as snaps, and then test those snaps on a PinePhone, thereby likely accelerating efforts to repackage clicks for future “cross-platform” use.
-
Being based on nearly stock Ubuntu 20.04, such an "extra-edgy" build could be used as a platform onto which various aspects of UT (including aspects that must change before upgrading to Mir 2.1) could be tested individually (before being tested on a full "edge" build), which could be helpful when attempting to "walk up the stairs" associated with rebasing the full UT stack to 20.04.
-
-
@GizmoChicken said in The road(map) explained:
Creating such an "extra-edgy" build based on nearly stock Ubuntu 20.04 would necessitate (and hopefully facilitate) a move from upstart to systemd.
I think you are answering your own question: There are a lot of pieces to rework, and somebody needs to do each of them. And there are other unrelated tasks that need to happen.
Once the move to systemd is complete, snapd could be supported.
That's a second, not insignificant, piece of work. And, as you say, will be easier after a move to systemd.
Having official snapd support for a PinePhone build would benefit those who wish to repackage clicks as snaps, and then test those snaps on a PinePhone, thereby likely accelerating efforts to repackage clicks for future “cross-platform” use.
There's a lot more to "cross-platform" than a common packaging format. Most apps packaged as snaps expect an X11 desktop: These won't "play nice" on phones.
Being based on nearly stock Ubuntu 20.04, such an "extra-edgy" build could be used as a platform onto which various aspects of UT (including aspects that must change before upgrading to Mir 2.1) could be tested individually (before being tested on a full "edge" build), which could be helpful when attempting to "walk up the stairs" associated with rebasing the full UT stack to 20.04.
This is mostly separate from the above pieces of work.
There's really only one aspects of UT that's needed for a Mir 2.x transition: A component called QtMir needs to "play nice" with MirAL. I've recently had a good discussion with @mariogrip and @UniSuperBox about how we can make that happen.
But even if we look to a time when that is done (which won't be a couple of weeks) that doesn't give a fully working Lomiri environment. There are features the mirclient API provided that need to be redeveloped for the Wayland based stack.
The good thing about is this work doesn't need a phone for development, or even Ubuntu, willing hands could contribute to this development using any Linux distro.
Maybe someone reading this thread could help?
-
Hi @alan_g,
Thanks much for the reply. Much appreciated!
What prompted me to post the above was that, given the recent Manjaro Lomiri builds for the PinePhone (with significant input from @mariogrip), perhaps a similar approach could be applied to create an Ubuntu Lomiri build (based on Ubuntu 20.04) for the PinePhone.
That is, I hoped that developing Manjaro Lomiri and Ubuntu Lomiri in parallel could speed the process of bringing Ubuntu 20.04 to the PinePhone. Then, once the kinks had been worked out of the Ubuntu Lomiri build for the PinePhone, the remaining Touch components could be added back.
But from your reply, I'm guessing that's not such a good idea.
-
@GizmoChicken said in The road(map) explained:
But from your reply, I'm guessing that's not such a good idea.
I work in software development, but I'm sure it happens in many other fields too that there are frequently more good ideas than resources to put them into practice.
-
@alan_g said in The road(map) explained:
I work in software development, but I'm sure it happens in many other fields too that there are frequently more good ideas than resources to put them into practice.
Yep, although I don't work in software development, my field also suffers from similarly limited resources.
But in all seriousness, I had hoped that I was proposing an easier/faster approach that would require less work, at least up front. But as I mentioned, I don't work in software development. So I'll defer to the experts.
-
@GizmoChicken If we bring Lomiri to 20.04 base it must also work for the Android devices. We are not going to maintain 2 distributions. So its far more work than just getting Pinephone adaptions in, we also must make 20.04 customized with a ton of stuff that enables Android devices.
-
@GizmoChicken said in The road(map) explained:
What prompted me to post the above was that, given the recent Manjaro Lomiri builds for the PinePhone (with significant input from @mariogrip), perhaps a similar approach could be applied to create an Ubuntu Lomiri build (based on Ubuntu 20.04) for the PinePhone.
The thing about Manjaro, postmarketOS, Mobian, etc… is that there are people other than Marius doing the work on those. There are others doing the majority of the work, and not core UT developers. This is not the case when talking about Ubuntu 20.04 migration for UT itself. This is something we must do ourselves, and is a significant amount of work, which is why we've broken it up in smaller chunks that can be done without wholesale migration to 20.04, such as upgrading Qt 5.12, solving systemd config issues, etc… Having people working to get Lomiri on other distros also helps with these efforts.
-
While this is true for stock Ubuntu, what @GizmoChicken proposes could also be build on Mobian (mobile/PinePhone edition of Debian). This could be used to turn "uTouch" into a polished Lomiri flavour of Mobian in the medium term, which is IMHO the best way forward.
-
@Flohack said in The road(map) explained:
If we bring Lomiri to 20.04 base it must also work for the Android devices. We are not going to maintain 2 distributions. So its far more work than just getting Pinephone adaptions in, we also must make 20.04 customized with a ton of stuff that enables Android devices.
Understood. And, yep, developing two distributions (at least initially) is exactly what I was proposing, namely developing one distro for the PinePhone and one distro for Halium-based devices That is, I was proposing:
-
For the next several months, developing Manjaro Lomiri and Ubuntu Lomiri in parallel, which I hoped would speed the process of bringing Ubuntu 20.04 (and other upstream goodies, like systemd, etc) to the PinePhone, and which I hoped would also lay the groundwork for adding back Touch at a later time (probably in a several months); and
-
Continuing on with your current Halium-based builds for Android.
But to be candid, with regards to your efforts on Halium-based devices (and I realize that I'm risking receiving some anonymous
s for this statement), if asked (which I haven't been ) I'd suggest bringing your Halium-based builds to a "good enough" state on a few core device as soon as practicable, and then redirecting the majority of your resources to PinePhone development for the next few months. By the time the PinePhone is in better shape, maybe (if lucky) the "GSI-esque" approach will be in better shape, potentially obviating the need for much the work that otherwise would have been done between now and then. But again, I realize that this last bit of my proposal (related to near-term efforts for Halium-based devices) will not be well received by most of the community. @dobey said in The road(map) explained:
There are others doing the majority of the work, and not core UT developers. This is not the case when talking about Ubuntu 20.04 migration for UT itself.
Yep, that's pretty much what I understood the case to be. And that's also pretty much why I figured "that developing Manjaro Lomiri and Ubuntu Lomiri in parallel [with those bringing Lomiri to Manjaro] could speed the process of bringing Ubuntu 20.04 to the PinePhone. Then, once the kinks had been worked out of the Ubuntu Lomiri build for the PinePhone, the remaining Touch components could be added back [by core UT developers]."
But let me reiterate: I don't work in software development. So I'll defer to the experts.
If what I'm proposing is a bad idea (and most who are actually working on the project seem to feel that my idea is a bad idea), please feel free to ignore me. No hard feelings from me. And whatever path you choose, I'll remain a fan of your work and will continue wishing for your continued success.
-
-
@GizmoChicken said in The road(map) explained:
I'd suggest bringing your Halium-based builds to a "good enough" state on a few core device as soon as practicable, and then redirecting the majority of your resources to PinePhone development for the next few months.
The majority of work happening on Ubuntu Touch is not device specific. If we were to have to maintain two distributions, it basically doubles the amount of work we have to do for each fix. The goal is to bring the Pine and Halium builds closer together, not to stretch them further apart and our time even thinner.
20.04 will happen when the time is right. Simply jumping onto it right now, even just for Pine devices, would make things worse there, not better. On the other hand, even staying on 16.04 is not a huge problem for now, because there are things happening and that still can happen, which will bring all the devices closer to each other, and will make transitioning to a newer version of Ubuntu much easier when the time does come for it.
-
I believe Lomiri is also coming to Debian so I guess you don't really need to wait for an Ubuntu 20.04 flavor once that works like Manjaro.
