Comment 4 for bug 1670481

Hi,
thank you for your report - and being upstream queued for qemu 2.9 already I think we can take that as backport into zesty without too much discussion.

But this "argument" is already a thin line and it will get thinner when it would come to SRUs.
By the Argument I mean "This behaviour change is not actually a bug since no assumptions should be
made on DT ordering. [...] It is expected to make things easier when porting existing applications to power.".

I read through the thread and I totally understand the need why this got "reverted" now.
But trivializing this - either it is:
- not an important behavior change (then this fix would not exist)
- an important behavior change (then it is not really SRUable)

The latter means that everybody on Xenial/Yakkety where the current reversed order is released have already adapted their setups, guests, device names, ...
If they went with device labels and such due to the initial error they won't see a change, but e.g. naming of network devices might change if they are not running with persistent device naming (Note Ubuntu does so for net it would be e.g. enp0s1 no matter what, but I think e.g. disk device names would change order).

That said SRUing this would break all those then right?

TL;DR: "either it is not important to SRU or it is, but then it would be a non SRUable behavior change".
Open for discussion, but these are the thoughts going through my mind at the moment.

For Zesty I think we are fine, the next Qemu release would change it just the same.
But please discuss with me what and why we should exactly do with Xenial/Yakkety.

A zesty fix is currently building for testing and verification in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2543
It would be great if you could confirm that achieves what you want with a test from your side.