A Proposal To Update Ubuntu's Kernel/Mesa/GNOME Components On A Monthly Basis

[pq1930562]

Artful-proposed (and xenial-proposed!) has had mesa-17.2.4 since November 22nd, but getting real people to actually verify the bugs it should fix is hard and time consuming. Since the paperwork takes ages, I don't even try to chase after every point release, so the unwritten "policy" regarding Mesa is that the last point release will be SRU'd. In this case I couldn't wait that long, and because 17.3.0 was delayed it means that 17.2.x is still not closed yet (AIUI). Besides, point releases can still regress something.

Still disappointed that you tjaalton refused to add a xserver-xorg-hwe-16.04-edge package to Ubuntu:

https://lists.ubuntu.com/archives/ub...-May/date.html

[tjaalton]

Still disappointed that you tjaalton refused to add a xserver-xorg-hwe-16.04-edge package to Ubuntu:

https://lists.ubuntu.com/archives/ub...-May/date.html

This was already discussed to death back then. I won't repeat it all here.

The xserver (stack, including drivers) backport is not like the kernel, which is a fairly straightforward backport of N+1 kernel.

[slacka]

As someone who ran Arch on several machines for several years, every troublesome upgrade was a kernel bug or a driver bug. Some can be very serious, for example the kernel upgrade that bricked the BIOS on some Lenovo laptops. For my use case, I think the kernel and drivers should be the most well tested and slowest to upgrade. For kernel and drivers, the hardware enablement (HWE) is as aggressive as I'd ever want to see in Ubuntu.

What I would like to see upgraded more frequently are the applications. When applications have bugs, it's trivial to downgrade and much less problematic. For my use case, I miss the Arch model for applications. For exmple, recently I went to download a youtube stream, only to find out that the youtube-dl was over a year out of date and didn't work anymore. Another example of an app that I needed to switch to a ppa was LibreOffice to fix a bug in the outdated version shipped with LTS.

[pq1930562]

This was already discussed to death back then. I won't repeat it all here.

The xserver (stack, including drivers) backport is not like the kernel, which is a fairly straightforward backport of N+1 kernel.

I still fail to understand why there is linux-generic-hwe-16.04 and linux-generic-hwe-16.04-edge but only xserver-xorg-hwe-16.04 and no server-xorg-hwe-16.04-edge.

As someone who ran Arch on several machines for several years, every troublesome upgrade was a kernel bug or a driver bug. Some can be very serious, for example the kernel upgrade that bricked the BIOS on some Lenovo laptops. For my use case, I think the kernel and drivers should be the most well tested and slowest to upgrade. For kernel and drivers, the hardware enablement (HWE) is as aggressive as I'd ever want to see in Ubuntu.

You just failed to name a specific example where Arch brought you some trouble with kernel and driver upgrades. Instead, you named an issue that happened on Ubuntu, which even occured because of an experimental/unfinished option being enabled (i.e. should not have been enabled in the first place).

What I would like to see upgraded more frequently are the applications. When applications have bugs, it's trivial to downgrade and much less problematic. For my use case, I miss the Arch model for applications. For exmple, recently I went to download a youtube stream, only to find out that the youtube-dl was over a year out of date and didn't work anymore. Another example of an app that I needed to switch to a ppa was LibreOffice to fix a bug in the outdated version shipped with LTS.

This +1000. It's absolutely ridiculous how outdated some apps are on Ubuntu (and several other Linux distros).

That being said: Now that Canonical has introduced Snap, the actual app developers/package maintainers are to be blame. If app developers would package, distribute and update their apps using Snap packages directly from upstream, that issue would be non-existent.

So no excuse for app developers. All this fragmented packaging needs to stop and everything should be delivered via Snap packages. Problem solved (just like on MS Windows).

That being said:

Another example of an app that I needed to switch to a ppa was LibreOffice to fix a bug in the outdated version shipped with LTS.

Use the Snap package:

https://www.libreoffice.org/download/snap/

[tjaalton]

I still fail to understand why there is linux-generic-hwe-16.04 and linux-generic-hwe-16.04-edge but only xserver-xorg-hwe-16.04 and no server-xorg-hwe-16.04-edge.

Because it's not just the xserver but drivers too. So you'd need dozens of -edge packages of the drivers, including nvidia (but most likely no support for AMDGPU-Pro). Not going to happen.

[theghost]

Artful-proposed (and xenial-proposed!) has had mesa-17.2.4 since November 22nd, but getting real people to actually verify the bugs it should fix is hard and time consuming. Since the paperwork takes ages, I don't even try to chase after every point release, so the unwritten "policy" regarding Mesa is that the last point release will be SRU'd. In this case I couldn't wait that long, and because 17.3.0 was delayed it means that 17.2.x is still not closed yet (AIUI). Besides, point releases can still regress something.

Regarding that intel-spi thing; the upstream patch(es?) that eventually got backported was/were not marked for stable, so how on earth would that've been caught at the time?

Well, thanks for the honest explanation. I know that resources are limited, especially on the Desktop and on the non-LTS-releases.
Maybe we can hope in future for more automated minor releases with zero paperwork. The buildsystem can build it, release it to proposed and when no bugs appear, automatically bring it on. People who don't respond to bug reports have to revalidate their bug against the new version.

Luckily I am not in the situation where I don't have to recompile Mesa for every minor version but in the past that was the case for my Sandybridge on Ubuntu.
That drove me away from Ubuntu. Because I had no use for a broken stable version.