According to an article posted on xda-developers.com, developer Erfan Abdi, has "successfully created a GSI-esque, platform-agnostic Ubuntu Touch image that can be installed on any Project Treble compliant device."

Would you please talk briefly about the UBports Generic System Image (GSI) project and what the project may mean for the future of UT on modern (Android 9+) Android devices?

Not a question, but I just want to say...

Congratulations on your progress toward completing OTA-12! Amazing work!!

@nexus5 said in future ubuntu touch:

Please do 3 versions of Ubuntu touch: lite, normal, maximum.

To be direct, I do NOT support your proposals. Even so, I want to THANK YOU for taking time to express your thoughts here. Again, THANK YOU!!

Also, I’m very SORRY to see that a few have “down-voted” your post, especially given that “down-votes” are anonymous on this site. Please don’t let them deter you from expressing you thoughts here.

As for those of you who (anonymously) down-voted this post, WTF? If you don’t like a post, take a few minutes to explain what you don’t like.

As an aside, I think this site should rethink allowing anonymous down-votes. Either show who down-votes, or eliminate the option to down-vote. Just my opinion, for which I suspect that I’ll receive at least at few anonymous down-votes for expressing.

I suggest waiting a few months (preferably at least six months) to gauge whether GitHub will change for the worse in any way. If you notice changes for the worse, then plan an orderly exit at that time. But if you don’t notice any changes for the worse, no need to divert precious time from development.

Mir 0.32 release candidate discussed here. Note the logind support is nearly complete.

@rik said in Ubuntu Touch Q&A 86 Saturday 10th Of October AT 19:00 UTC:

Is there any consideration in having a separate build that is not a read-only filesystem, e.g. more of a standard Ubuntu install? If there were something like that, I would think it could stand as the main development branch that would allow faster upgrade to 20.04 / wayland / systemd / etc. Then it could be a testing ground that new releases of the "stable" or "consumer" read-only system would come from.

It would also not frustrate any potential developers who want "standard Linux on a phone" (mobian, manjaro, fedora, etc.).

In summary, I understand a lot of the reasons behind the read-only system for stability, for security, for end users, etc. but I fear it keeps away possible developer interest that would benefit Ubuntu Touch in the long run if it were more "traditional Ubuntu" on a phone?

Based on the reactions to comments that I recently posted in the "The road(map) explained" thread, what you (and I) suggested doesn't seem likely, or at least not likely in the near future. However, Manjaro Lomiri may fit your needs.

Would you please talk a little about the goals of the Waylandify project? In particular, is a complete migration away from the mirclient API among the goals of the Waylandify project, or will some of that migration work require a separate future project?

I'm not at all clear what Canonical is planning for their "Anbox Cloud" project. But if the project aims to offer a way to run some Android apps in the cloud (rather than directly on a Linux device), the project seems like a good thing for Ubuntu Touch.

Your initial thoughts on "Anbox Cloud" project?

@erlend said in Ubuntu Touch Q&A 67 Saturday 11th Of January At 19:00 UTC:

I hear last time that.. Mir is going to be replaced with Wayland....

The devs can clear this up better than I can, and so I defer to the devs for a more complete explanation.

But in the meantime, suffice to say that it's not quite correct to say that "Mir is going to be replaced with Wayland." (Mir is a display server, and Wayland is a protocol.) Rather, UBports is replacing the "old" Mir display server with the "new" Mir display server.

The "old" MIr display server used its own (non-Wayland compliant) protocol, while the "new" Mir display server is now Wayland compliant. As of about Mir 1.6, in addition to being Wayland compliant, "new" also supports the legacy protocol that was used by the "old" Mir display server. However, that legacy support will eventually be removed from Mir (probably starting from about Mir 1.7), hence the need to "Waylandify" Ubuntu Touch.

Questions for Q&A: Regarding your efforts to "Waylandify" Ubuntu Touch, have you had a chance to experiment much with moving libertine to use xwayland? And if so, what are your initial impressions regarding the difficulty of the project?

Not a question, but I just want to say...

Congratulations on completing and marking closed the Unity8+Mir upgrade project!

@rik said in Ubuntu Touch Q&A 86 Saturday 10th Of October AT 19:00 UTC:

Is there any consideration in having a separate build that is not a read-only filesystem, e.g. more of a standard Ubuntu install? If there were something like that, I would think it could stand as the main development branch that would allow faster upgrade to 20.04 / wayland / systemd / etc. Then it could be a testing ground that new releases of the "stable" or "consumer" read-only system would come from.

It would also not frustrate any potential developers who want "standard Linux on a phone" (mobian, manjaro, fedora, etc.).

In summary, I understand a lot of the reasons behind the read-only system for stability, for security, for end users, etc. but I fear it keeps away possible developer interest that would benefit Ubuntu Touch in the long run if it were more "traditional Ubuntu" on a phone?

Based on the reactions to comments that I recently posted in the "The road(map) explained" thread, what you (and I) suggested doesn't seem likely, or at least not likely in the near future. However, Manjaro Lomiri may fit your needs.

@Flohack,

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

@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:

1. 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

2. 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.

@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.

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.

@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:

1. Creating such an "extra-edgy" build based on nearly stock Ubuntu 20.04 would necessitate (and hopefully facilitate) a move from upstart to systemd.

2. Once the move to systemd is complete, snapd could be supported.

3. 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.

4. 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.

I'm itching to purchase the latest PinePhone Community Edition w/ Manjaro preinstalled

But if given the choice, I'd prefer to purchase a next generation PinePhone Community Edition w/ UBports UT preinstalled, especially if it were to ship with the full Yumi mascot printed on the back cover and some (maybe about $10) of the proceeds were to benefit UBports.

Question: Can you share any info regarding if/when a next generation PinePhone Community Edition w/ UBports UT preinstalled will be available for purchase?

@UBportsNews said in Ubuntu Touch Q&A 85 This Saturday 26th Of Sept At 19:00 UTC:

Leave that with us to think on, It's a nice idea will let you know.You can also can already subscribe to the UBports News Channel https://t.me/ubports_news (plug, plug) to get all Q&A and other news and update items as they are announced.

Thanks much for the reply. Yep, I know that I have other options (including adding a recurring reminder to my Thunderbird calendar). But as for Telegram, although I'm sure it's a great app and a great service, here in the North American colonies, Telegram isn't widely used.

edit: Why not just mark the News thread on the Forum as Watching to get notifications on new items in Recent.

Well, I could. But I suspect that if I did, I'd receive more notifications than I want.

To be candid, as you may have noticed, I don't lose track of the Q&A dates very often. But I've lost track of Q&A dates on a few occasions, so I can relate to @wsha1's frustration. And that's why I posted my proposal.

@wsha1 said in Ubuntu Touch Q&A 85 This Saturday 26th Of Sept At 19:00 UTC:

one bit of feedback on the Q&A -- there have been several times when I have thought of a question to post but it was outside of the window between when this post goes up and when the Q&A takes place. Then I forget until the window has opened and closed again.

@wsha1 A new "announcement" thread inviting questions is usually posted about 5 days before the Q&A. And then a follow-up "reminder" thread (like the one linked here) is usually posted a little closer to the date of the Q&A. But, yes, like you, I often lose track of which weeks are Q&A weeks, probably because the Q&As occur in alternating weeks. Maybe what I propose below to @UBportsNews would help us both?

@UBportsNews I like the way that the initial announcement threads (like this thread) are posted (a) about 5 days before the Q&A, and (b) as a new thread for each Q&A. But with regard to the follow-up "reminder" threads (like the one linked here), I hope that you'll instead use an approach that's more compatible with the "watching" function. For example, instead of (or perhaps in addition to) posting each "reminder" into newly created threads, how about creating one "UBports Q&A Reminder" thread (a) to which only admins could post, and (b) that's always "pinned" to the top of the News section? That way, those with a poor memory (such as me) could mark the pinned "UBports Q&A Reminder" thread as "watching" so that we're more likely to see the "reminder" update before each Q&A.

Not a question, but I just want to express my excitement and gratitude to see progress being made in the "Upgrade your Qt" project.

Also, I'm amazed by the huge volume of CI jobs related to Qt 5.12 that have been submitted. Awesome work!