I would like to know if all or some of the performance fixes developed to newer Gnome versions will be backported to Bionic, as I understand was done for the Cosmic cycle. For example, in mutter, I can see a lot of them are present in both branches:
Yeah, I’m completely aware of the SRU process and all that. I know no new versions of Gnome will be backported to Bionic, but I was asking for the specific case of performance fixes, to know if Canonical plans to backport some of those to 3.28.x, as people like @3v1n0 and @vanvugt are doing a lot of work (upstream and for Ubuntu) in this field:
I wonder if we will see some of @vanvugt 's performance fixes as cherry-picks in Ubuntu 18.10?
I think that mutter!171, mutter!117 and mutter!189 are the most interesting ones (especially!171).
We are one month away from the release. If they are going to add some cherry-picks, they should be added soon to get some more widespread testing.
As far as I know some other fixes are waiting for mutter!171 to finally land and some widespread regression testing could probably speed up the adoption upstream as well.
I think it is unlikely that Ubuntu would backport these fixes because said fixes are not security vulnerabilities, so would not be updated in 18.04 as an Ubuntu- or Debian-specific patch, and presumably said fixes are not included in upstream 3.28.x releases, so they can’t be SRU’d as upstream minor updates either.
Unless you can find an area in the SRU or Backports Wikis that a backport would qualify under then there’s no procedure for it to happen.
I very strongly recommend upgrading to Ubuntu 18.10 (when it’s out) if you would like major fixes that can’t (due to procedure) be backported to 18.04. You’ll get all of the other improvements in GNOME 3.30 as well (aside from Files 3.30).
It doesn’t have to be a security fix or GNOME micro-release release to be eligible for an SRU. Security fixes have a separate process than SRUs. GNOME micro-release updates have an exception where we don’t need to verify every single fix or code change.
So GNOME 3.30 performance fixes could (in theory) be SRU’d into Ubuntu 18.04’s GNOME 3.28? But presumably someone would need to volunteer to do the work? Or what’s the reasoning against doing so? That it’s bad practice (because of the maintenance required as well as possible impacts on stability, dependencies etc) and people should be upgrading Ubuntu if they want performance improvements?
I think that @vanvugt explicitely stated in an upstream bug that he was going to backport one or two fixes. But give it time. Some fixes will wait to be approved upstream, some will be cherry-picks. Some will be SRUed to Bionic if they prove to work well in Cosmic.
Note that GNOME 3.30 is no longer the target since most of the performance fixes have not landed yet. So it is now GNOME 3.32 onward. But yes, fixes do exist that can be backported to 3.30 and 3.28. I don’t know the status of the backporting as I just returned from vacation.
Because performance is a multi-cycle exercise with lots of different issues, I am tracking them in three categories here:
I can see why you might think that none of the fixes will reach 18.10. However that’s only the upstream-first path that is now closed. We have another path whereby we can patch fixes in at any time, if they are important, stable and properly documented. Those criteria are what we recently discussed in Brussels so I hope that a couple more new fixes will reach 18.10 yet.
If I had to choose one performance fix that is complete, stable, small and has a noticeable impact to usability then it would be the input latency fix.
