xorg driver point-release MRE, vulkan MRE, mesa backport policy

[Timo Aaltonen]

	Hi

  I know the next meeting is on the 17th, but 16.04.2 release is
scheduled for 19th so these need to be discussed here. I have three things:

1)
Xorg driver point-release MRE

Just like the xserver, xorg drivers should be granted MRE so that for
instance -ati and -amdgpu drivers from 16.10 could be backported to
16.04 (-ati 7.7.0 -> 7.7.1, -amdgpu 1.1.0 -> 1.1.2). Since the xserver
version in xenial is already at 1.18.4, there's no point in renaming the
yakkety packages as lts-hwe for 16.04.2 because the diff is so small,
but backporting bugfix release via SRU is still desired.

2)
Vulkan MRE

vulkan source package builds a loader library for vulkan drivers. Xenial
shipped with 1.0.8.0, yakkety has 1.0.21.0, zesty has 1.0.37.0. Vulkan
apps need features that the old version doesn't have. So, (lib)vulkan
should be considered to be on the same boat as libdrm, which has a
standing MRE to allow backports from interim releases to the LTS.

3)
Mesa backport policy

For past LTS point-releases mesa has been backported as a renamed source
that builds a subset of it's binaries. This creates problems when, say,
an OEM needs a newer release because backporting features to the old
version is impractical, fragile or just impossible.

I propose that mesa is allowed to roll forward with a set of rules:
- mesa from LTS+n is backported unrenamed
- the version used is the la(te)st point-release of the series, which
should have a minimal risk of regressions
- this can be kept in -proposed for a longer time with cert-team and
wider community testing encouraged, which would verify it's quality

As for regression testing, I know that at least Intel validates new
major upstream versions on all their HW, so vXX.0.0 is already a "good"
release, and following bugfix releases sort out the minor issues left in it.

Unrenamed mesa backport in -updates allows an even newer version in
-backports. It wouldn't be possible with lts-hwe, because handling
various upgrade paths would be horrible. There are plans to push mesa
from the devel series to -backports so that enthusiasts can use the
latest mesa release for better driver performance in games, OpenCL apps
etc. This also makes them the front line in testing for regressions way
before it hits -proposed.

Mesa has some reverse dependencies which get bumped for new major
releases. Libdrm already has a MRE, and new LLVM releases have been
backported in the past too. Newer dependencies are vulkan (see above)
and libclc (for OpenCL), latter of which likely needs a new backport too
because it also needs to work with the new LLVM version.

I've discussed this proposal with the release manager over the past
couple of months, but after the holidays it hit me that the TB is who
should approve this.. even with the risk of delaying 16.04.2 a bit (Jan
19th is early!). Since this release is special in that the time to test
is short, mesa 12.0.5 has already been tested by the cert-team on select
Intel/AMD systems and no new issues have been found. I've also blogged
about the test packages*, but the SRU bug just has crickets so it's
unclear how many have actually tried the backport. FWIW, I've been using
it myself on intel hw for two months without trouble.


*
https://tjaalton.wordpress.com/2016/12/03/mesa-12-0-4-backport-available-for-testing/


-- 
t