@alan_g said in No more "Mir EGL" on 1804LTS (Bionic):

After the debacle of "Mir 1.0" last year I don't predict what the release will be called if I don't have to.

OK, fair enough.

This is the only pointer I have:

https://github.com/ubports/mir/commit/a8cd1fcc1eb15c45297b2181fc93a3503aa69150

It does need to be updated for Mir changes since then.

I confess I'm finding the upstream/ubports relationship a bit difficult to follow from the existing repo (and not only for mir). There doesn't seem to be a very rigorous maintenance of the boundaries between local patches and upstream.

It would be really, really helpful if there would be a stronger distinction between well-defined master- or major-version branches (whether tracking an upstream or not), versus branches dedicated to specific distro packages.

I have had some discussions with @mariogrip about this code: It deserves to be split out as a separate "platform" in the same way that the "android" platform has been.

That's something I would again be happy to help out with, but I am currently finding the project a bit opaque in terms of actually getting engagement on tasks and priorities

@alan_g said in No more "Mir EGL" on 1804LTS (Bionic):

I expect the next release of Mir to address this shortfall before 18.04 is released.

"Next release" means 0.31.0 ... ?

@mariogrip has done some work on a Wayland "Mir platform" that would allow one Mir server to "Nest" on another.

This is something I would be happy to help out with if anyone can offer a few starting pointers or simpler tasks to get my feet wet with.

@alan_g I'll reach out to @mariogrip directly w.r.t. all things UBPorts.

You've been more than generous with your time, but is it OK to still ping you about Mir(AL)-related issues w.r.t. the USC refactoring? No worries if not.

On a slightly bigger note:

I would really, really urge everyone involved in UBPorts to take on the key advice here:

everyone (not just devs, or an "in crowd") must be able to see the the workflow (and status of work items).

Right now if I go to ubports.com and click on "Community" or "Join us", I get a lot of pages about stuff like the different steering committees and whatever, but (despite clicking on multiple different links), there's NOTHING about easy ways to start taking useful action.

If anything it's even more offputting because pretty much the first thing one sees on the "Get Involved" page is the link to become a member ... which jumps straight into statutes, 6-month commitment, etc. etc. etc. Most people would like to have a way to dip their toes in the water first before thinking about jumping in that deep!

It would be far better to have an easy way for people to just start doing small things, get engaged through doing stuff, and learn by experience whose commitment is up to the standard expected of full members.

Hi @alan_g -- good to see that there is a renewed push in this direction. Recent times have been a bit busy but I'll try to reawaken the USC-on-MirAL work soon. IIRC it's a bit in need of feedback/advice now.

In the short term, would it be convenient to try to rework that as a GitHub PR against UBPorts repos?

I've recently updated a machine of mine to the latest Ubuntu daily releases (18.04 to be) and added the UBPorts Unity 8 PPA. What's striking about that is that it seems much less stable/reliable right now than the Yunit PPA on top of xenial. The latter seemed pretty stable when apps running directly on Mir were being used (only XMir-using apps seemed problematic), but the new UBPorts packages seem to have some quite unpleasant getting-locked-up/crash-y behaviour even when only using the native apps (e.g. the ubuntu terminal app).

Obviously xenial is a much more stable base but still, it would be good to understand what is making the difference there.

I also note that the yunit PPA seems to be missing lots of the Unity8 native apps (e.g. the browser). Is that intentional, an oversight, or something on the to-do list?

@Flohack I would give it time. I don't know about other people, but personally I'm not placing any expectations on UBPorts or Yunit for quick results -- I'd much rather everyone just took some time to patiently explore the codebases that exist, than have anyone feel pressured to get things done straight away.

@Flohack said in A vision of where to go after Ubuntu Touch's death:

They could have get us some last minute contacts to organize the takeover. But we are more or less alone, and our network to former employees is not that huge.

Bear in mind that it might not be legal for them to pass on (former or current) employees' contact details to you without those people's explicit permission. And since those people are probably quite busy sending out CVs and suchlike at the moment, they may not be very responsive in the short term even if they want to get involved with Yunit/UBPorts.

@Mitu said in A vision of where to go after Ubuntu Touch's death:

And what I would suggest for the start of the development

You've made a very nice summary of ideas here, but for the start of development it may be important to distinguish much more clearly between what's genuinely needed versus what might be helpful at some point in the future.

Probably the most valuable thing that can be done as a starting step is just to look at what are the minimum set of changes needed to complete Unity 8 on its own terms (and "complete" in this sense probably means finalizing a viable desktop). No major re-architecting or trying to replace important bits of the stack -- just try to follow through on the final touches of the project as it exists, the kind of stuff that Canonical's team would have been doing if the project had carried through.

The reason to do that is because, by trying first to understand and complete the project on its own terms (i.e. the convergent OS where the same codebase can serve mobile, tablet and desktop), everyone involved will learn a good deal about the actual issues of the project, and about why its developers made the choices they did.

From that vantage point, everyone will be much better placed to make informed decisions about what really needs to change in the long run -- whether it's what to do with Mir (it may not need to be replaced at all given Canonical's ongoing plans for it in IoT projects), whether a new app store is necessary (it may be possible to continue to use the existing snap store just fine), or any of the other considerations that might come up.

@jsalatas said in Collaboration between ubports and yunit projects.:

In any case can we stick to the collaboration between yunit and UBPorts in this topic? And maybe have a different one to discus the mir vs wayland think?

Yes, fair enough. FWIW I wasn't trying to launch a mir-vs.-wayland discussion per se. My concern was more that in creating the yunit/UBPorts collaboration, it's important to have a clear picture of what's genuinely needed for things to work.

I want this collaboration to be a big success, and with that in mind I think it matters to very rigorously ask the question, "What's the minimum amount of work we need to do to get this codebase ready for a working desktop?"

@jsalatas said in Collaboration between ubports and yunit projects.:

Thinking out loud: will that be a good idea to continue relying on canonical? Maybe they will decide to drop it and move to something else after a year or so.

Well, what I'd suggest to you is that this is an argument from theory and speculation. The simplest thing is probably to actually talk to the folks at Canonical and ask to what extent you can engage on this. If they say, "No, definitely go with Wayland", there's your answer. But if they are interested in having you continue to use mir, and are prepared to take patches from you in support of your work, then that potentially takes a whole body of effort out of your hands for the foreseeable future.

If in a year or two you find yourself having to transition after all, then you'll be facing that challenge from the point of view of having a lot more experience of the collective codebase and how it all works. But in the meantime, why create work for yourselves until you know you have to do that work?

@jsalatas said in Collaboration between ubports and yunit projects.:

@WebDrake It doesn't mention something about mir there

Yes it does. I said the thread, not the post

The particular comment in question (it's some way down in the discussion, I should have mentioned that) was highlighted in a later Reddit thread:
https://www.reddit.com/r/linux/comments/646mv8/mark_shuttleworth_i_came_to_be_disgusted_with_the/

Specifically, Mark Shuttleworth writes:

we have lots of IoT projects using Mir as a compositor so that code continues to receive investment. I agree, it's a very fast, clean and powerful graphics composition engine, and smart people love it for that.

@jsalatas said in Collaboration between ubports and yunit projects.:

Based on preliminary discussions we had we both agree that moving from mir to wayland is the direction we need to follow.

Out of curiosity, why?

According to the thread here, there is going to be ongoing investment in mir:
https://plus.google.com/+MarkShuttleworthCanonical/posts/7LYubpaHUHH

... so why attempt to move away from this piece of the stack unless it's provably necessary? It could allow for some interesting points of collaboration with Canonical's ongoing IoT efforts.