-
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.
-
@GizmoChicken given the limited resources how to obtain a Pinephone and the current state of its overall usability we will not abandon Android devices to redirect all forces on Pinephone. As Rodney said, the gap would get wider by that, and we would disappoint a huge userbase, PLUS we are also committing to delivering a usable image for the Vollaphone which is Android 9. And work needs to be done soon for Android 10 etc. So, yes, Pinephone is important to us, but we would do us no favour if we jumped on this train alone, we would never be able up to close tha gap later.
-
I concluded my previous post with the following:
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.
Honestly, I figured that, in view of my overtly conciliatory remarks, our discussions on this topic would have concluded.
Even so, I was not surprised (and was not offended) when another participant directed toward me a few additional arguments in support of his position.
Regarding his additional comments, I did not respond to them because I wanted to give him the last word in the discussion between him and me.
Then you, @Flohack, directed toward me a comment that included the following:
we will not abandon Android devices to redirect all forces on Pinephone.
To be clear, no, I did not suggest that UBports should "abandon Android devices to redirect all forces on Pinephone." Rather, I wrote:
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.
Emphasis added.
I hope the above clarifies the record.
Regarding the remaining comments that you directed toward me, rather than address them, I'm giving you the last word in this discussion between you and me.
Of course, if you want me to address the remaining comments that you directed toward me, please feel free to respond. I'm happy to oblige.
Regards,
GizmoChicken -
I appreciated the pinned topic explaining the road map rational and only have 1 major question. Where do I find the roadmap?
-
I, for one would like to thank the entire team for building, maintaining and developing this software. Without your time talent and treasure, we wouldn't have such nice hard/software.
So a big thank you to all and keep up the good work!
