No new stuff for xenial, but what about old new stuff?

jezek

Hello, I read somewhere, that there will be no new stuff in next OTA for xenial. Just bug fixes. New stuff will be only for focal.

I understand and I think it is okay for new features, because there is not enough ubports people to maintain both branches.

But what about features for xenial that are ready for merge for a long time, then the author was asked to port it for focal and it got merged into focal, but not to xenial. Concretely I'm talking about the emblem counter icons, but I think it fits to more merge requests (MRs).

Why am I writing this? Because if it is like told, that the long waiting xenial MRs do not get to next xenial OTA but they get into focal OTA, than it is kind of unfair to the volunteer developers.

Why? Let's look at the thing from my point of view. I, as an volunteer developer for open-source projects, am making features mainly for me, when I want something because I like it and others could like it too. I spent my time to make the features. Than I'm waiting for merge and while waiting, I'm requested to add the features to focal. I'm using my time to bring the feature meant for me, to other devices, which I don't own. Than the MR for focal gets merged in short time, but the MR for xenial, which is there for more than half a year is not merged and I'm reading, that it will probably never merge. The result? The feature I made because I would like to see it my xenial device won't be there, but for other people using newer devices it is there. My device suits my needs and i don't want to buy a new phone for a few years. I would find it very demotivating if a feature I made for my device lands only on devices I don't have and I would heavily reconsider to make something new for the project.

Sorry for my rant. Maybe I'm wrong and I misunderstood the statements for xenial OTAs and you plan to merge the old new features to xenial. In this case ~~ignore this post~~ write about it here. But if I'm right, than I have to appeal to the higher ups to reconsider and let at least the long waiting feature MRs be merged to xenial too.

What is ubports's staff and other community members and volunteers opinion on this?

Thank you.

cliffcoggin

@jezek I sympathise with your predicament, but what else can the UT team do? There is not enough staff to carry out all the work required so something must be sacrificed. Should the roll out of the new base be further delayed to get outstanding requests added to the old base? (Sorry, but the terms xenial and the other one mean little to me.) Should other features be scrapped in order to get yours merged?

No matter how the list of jobs is manipulated it does not alter the fact that there is more work than the existing staff can handle so inevitably some tasks will be dropped. Of course that is unfair, but what else can be done?

kugiigi

@jezek I feel your sentiments. I guess part of the answer will always be that we lack man power and the focal upgrade is such a monumental task. Hopefully they can do something about the open PRs that were already merged in focal but not in xenial.

For now, I guess you can just install your PR via ubports_qa. Personally, I've been a lot more selfish in the past year or so I just directly implement whatever I want on my devices. I don't create PRs anymore, at least for now. This way I don't need to wait for all my ideas and all I want to do

Lakotaubp

@jezek Just out of interest what devices do you have?

domubpkm

Concerning xenial, if there are novelties to bring, the best way is perhaps to do it by the .click app.

lduboeuf

@jezek
i also feel that frustration too even if i'm Focal ready. But would love to see all the previous work to land on thoose who will stay on Xenial as long as their device work.

But in another hand, if we start to push new things on Xenial that do regressions, can they be fixed later ?.

So @Ubports team, please consider merging old PRs if they land in Focal and already tested for a while

Farmer

@kugiigi Just addressing the 'selfish' tones of this post. Not selfish at all. My heartfelt thanks to you all who freely share your knowlege with those of us who can't understand even if you show us.

jezek

@cliffcoggin

Should the roll out of the new base be further delayed to get outstanding requests added to the old base? (Sorry, but the terms xenial and the other one mean little to me.)

xenial - Codename of current working system, based on Ubuntu 16.04 (codename xenial), OTA-24 was just relased for it. Currently runs on many devices (80+).
focal - Codename of Ubuntu 20.04 on which the near future version of Ubuntu touch will be based on. Many of the devices which can run Ubuntu touch now, will not be able to run this version.

Rollout of OTA-24 happened right now, the new rollout (OTA-25) is not scheduled yet. There should be not much delay, because I'm talking about MRs, that were accepted to the focal version/branch and were not accepted to xenial branch. The MRs were build for xenial in the first place (and then ported to focal), so why not relase them to xenial too. If they are good enough to run on focal, so why not run on xenial? It's like @lduboeuf writes in his comment above, it's frustrating to see your tested code, which was accepted to focal, not reach many devices although it was written for them in the first place.

Should other features be scrapped in order to get yours merged?

No, no other features will get scraped or be anyhow harmed. Just there should be some effort made to add all the xenial merge requests which were made before OTA-24 and it's focal counterpart has been accepted. There is enought time to next OTA.

@kugiigi I hope I'll see you implementations somewhere on net too. New public stuff is always better than no stuff.

@Lakotaubp I have an daily driver FP2 and a unused BQ E5 with broken touch.

AppLee

Hi @jezek

Let me oppose another point of view (just for sake of discussion as I do not have a personal opinion on this topic).

You see a little effort to benefit a lot of devices. But have you consider the effort necessary for a change that will be dropped few weeks or a couple of months later?

Imagine it takes 2 weeks to test and validate those MR. But 2 months later most of the devices will move to 20.04, so why bother and why not spend those 2 weeks polishing the first release of 20.04?

I suspect many people will pause moving to 20.04 waiting for it to be "safe", but as much as I emphasize with that idea, I think it will be better to massively adopt 20.04 to avoid having to maintain both 16.04 and 20.04.

If people are not incentivized to update to 20.04 it may result in people sticking on 16.04 by fear and complaining about stuff already fixed or not relevant in 20.04 which would be a nightmare to manage.

IMHO we can wait a bit longer, those MR are not critical and are in focal, so why not embrace the future.
For your particular case @jezek, will the FP2 compatible with focal, I don't know, but hopefully you'll soon be able to enjoy the fruit of your work and many others will too.

I think also most devices will be focal-compatible as the number of old/legacy devices is decreasing due to hardware failures.

Hopefully all will be for the better. But with skeleton crew and few resources, hard choices have to be made and priorities have to be set.

kugiigi

@applee I think his main point is that not all devices will move to focal. Some may totally not at all and some may come later than others. So having them now would be beneficial for those affected by this.

@jezek All my experiments are in the Sapot Browser for Morph and for Lomiri and the keyboard, they're basically all here https://github.com/kugiigi/jerk-packages

Lakotaubp

I have been thinking about this and trying to work it through, however to say I am not involved or have an opinion is not really fair.
Firstly let me say I fully agree with the position that all effort must be put into getting Focal out, running and stable as fast as humanly possible. There has been so much time, effort and expectation put into it and now it is only weeks (not a year or months) away and it is the future of Ubuntu Touch and UBports. All efforts must be put into it.
16.04 will, as it should, be put into a holding position as planned and kept going for as long as possible in that state along the lines already mentioned.
How that is done and by whomever I don't know as yet because as a non developer or porter I have no idea really of the effort and time needed. Whether a seperate team of people can continue and merge, fix and maintain PR's/ MR's for 16.04 I also do not know. I can try and find out and will ask a few questions of those that might know the answers, but for now all efforts and concentration needs to be and should be on 20.04
Saying any of the above does not in anyway mean that we have nothing but the highest admiration and respect for everyone who has helped in anyway keep 16.04 alive and going and fun to use for so long. I can fully appreciate how annoying and frustrating it would be to have requests not yet merged and the delay involved. We all know the main reasons for that and the size of the main team trying to do it.
I cannot promise that there will be an answer to this that keeps everyone happy, probably not but I can ask the question and see what is possible be it more of a community effort rather than the core team or something different.

On the back of this I would again ask device porters and app developers to help get as many devices and apps ready for 20.04 as possible, and as is always the case if you want or can help in anyway develope UT for the future please get in touch.

peat_psuwit

Hello jEzEk,

There are both technical and societal reasons as to why we have decided to not accept new features into the Xenial line of update anymore, even the ones which is developed against Xenial and is near ready.

First, the technical reason: due to a large number of changes involve in making all Ubuntu Touch components works with the new version of Ubuntu, compound with desire to realize the rename in this release, we've decided early on to have a separated branch of code for almost every component we have. Unfortunately, this resulted in a largely separated development between Xenial and Focal, and while one is busy making a component runs on Focal, another proceeds to add new features onto the existing codebase on Xenial. And because we didn't realize this problem early enough, this means now we have quite a backlog to visit. Also, since the code diverged a lot since we start the branches for Focal, sometimes it's not straight forward to port changes to Focal. So, limiting the amount of changes that enters Xenial directly reduces the amount of work needed to make Ubuntu Touch based on Focal a reality.

Now, the societal reason: as mentioned by many people above, we're a small group of people and unfortunately can't do everything at once. In addition to adding the amount of changes we need to carry to Focal, time spent reviewing changes for Xenial is time not spent developing or reviewing changes for Focal. Given that Xenial has been out of support for over a year at this point, it has become our priority to provide our users with the up-to-date base for the security of our users, and that means we need to reduce as much work as possible.

In addition, many people might consider Focal complete when it reaches feature parity to Xenial. However, if more changes keeps being added to Xenial, it becomes harder to realize that objective. Having to chase a moving target is not fun, and personally I already have that feeling when I realized that the contact backend changes will land in OTA-24. Fortunately that didn't happen in the end, but even for smaller features it can easily be unexpectedly hard to bring to Focal.

So, please accept my apology that we cannot accept more changes into Xenial line of update anymore. We want to have an up-to-date and secure operating system, and we cannot have that with an out-of-date base.

On the side of device support, the primary limiting factor at the moment is due to the inevitable change of the init system from Upstart to Systemd. Systemd uses a number of modern features of Linux kernel, and as such requires a (moderately) modern Linux kernel. The version of systemd requires Linux >= 3.13, however the recent version raised that a bit.

It's possible to backport certain changes into an older kernel to make systemd runs, but it's a tedious manual task that has to be done per kernel tree [1]. A rule of thumb is that if the device launches with Android 9 it should be fine, but for older devices one must check the Linux kernel version.

[1] For example, I've done such job on FP2, which allows me to run an old image of Plasma Mobile which uses systemd.