I've reviewed the SRU upload to Xenial in the Unapproved queue.
SRU policy requires fixes to be in Bionic first. I understand the spirit of this to be not just to both to stop users regressing upon future upgrade, but also for us to gain some confidence in quality in the development release to mitigate SRU regression risk before backporting. Bug 1758428 concerns me. We don't know if it's fixed in Bionic, which suggests to me that we don't have a well-defined test case. I understand that in this case the nature of the fix is that it can easily be applied to Bionic, and the reason for not doing so is because other factors have changed such that it may be unnecessary. Nevertheless, I think this should be settled in Bionic first both to avoid user regressions and to ensure quality in Bionic prior to complicating things by SRUing. And besides, Bionic will be the next LTS so we should presumably have this settled well in Bionic anyway.
SRU policy also requires that for feature backports to LTSs, intermediary releases are also updated: "To avoid regressions on upgrade, any such feature must then also be added to any newer supported Ubuntu release". Note that one severe class of regression is that failure to do this will make any future security updates for this package in Artful invisible to users who have upgraded, so I believe this to be an important requirement. I'm also not sure that the SRU team has the remit to make an exception here. Finally, my opinion is that if an exception is warranted in this case, the implications are large enough that we should be making a general policy statement for the project so users can be clear on the consequences (eg. "cloud instance release upgrades to non-LTS releases are no longer supported").
I haven't reviewed the diff itself, since I'd want to do it again before accepting a future upload anyway. Based on the changelog entries, the backport itself looks reasonable in principle though.
A couple of minor points which don't necessarily block upload, but would be useful to fix in future uploads. These caused me some confusion to follow what was going on:
2:10.2.0-3ubuntu0.16.04.1 has never been published, so 2:10.2.0-3ubuntu0.16.04.2 is unnecessary and could be squashed into 2:10.2.0-3ubuntu0.16.04.1.
2:10.2.0-3ubuntu0.16.04.1 is based on 2:10.2.0-3 which has been superseded in Bionic. That it has been superseded since the SRU was prepared is fine. But at that time, an upgrade from Xenial to Bionic wouldn't work as expected because 2:10.2.0-3 is lower than 2:10.2.0-3ubuntu0.16.04.1. Since Bionic has moved on, this won't cause a problem now, assuming that Artful will be updated the same as Xenial. I suggest using a pattern like 2:10.2.0-3~ubuntu0.16.04.1 in the future.
I've reviewed the SRU upload to Xenial in the Unapproved queue.
SRU policy requires fixes to be in Bionic first. I understand the spirit of this to be not just to both to stop users regressing upon future upgrade, but also for us to gain some confidence in quality in the development release to mitigate SRU regression risk before backporting. Bug 1758428 concerns me. We don't know if it's fixed in Bionic, which suggests to me that we don't have a well-defined test case. I understand that in this case the nature of the fix is that it can easily be applied to Bionic, and the reason for not doing so is because other factors have changed such that it may be unnecessary. Nevertheless, I think this should be settled in Bionic first both to avoid user regressions and to ensure quality in Bionic prior to complicating things by SRUing. And besides, Bionic will be the next LTS so we should presumably have this settled well in Bionic anyway.
SRU policy also requires that for feature backports to LTSs, intermediary releases are also updated: "To avoid regressions on upgrade, any such feature must then also be added to any newer supported Ubuntu release". Note that one severe class of regression is that failure to do this will make any future security updates for this package in Artful invisible to users who have upgraded, so I believe this to be an important requirement. I'm also not sure that the SRU team has the remit to make an exception here. Finally, my opinion is that if an exception is warranted in this case, the implications are large enough that we should be making a general policy statement for the project so users can be clear on the consequences (eg. "cloud instance release upgrades to non-LTS releases are no longer supported").
I haven't reviewed the diff itself, since I'd want to do it again before accepting a future upload anyway. Based on the changelog entries, the backport itself looks reasonable in principle though.
A couple of minor points which don't necessarily block upload, but would be useful to fix in future uploads. These caused me some confusion to follow what was going on:
2:10.2. 0-3ubuntu0. 16.04.1 has never been published, so 2:10.2. 0-3ubuntu0. 16.04.2 is unnecessary and could be squashed into 2:10.2. 0-3ubuntu0. 16.04.1.
2:10.2. 0-3ubuntu0. 16.04.1 is based on 2:10.2.0-3 which has been superseded in Bionic. That it has been superseded since the SRU was prepared is fine. But at that time, an upgrade from Xenial to Bionic wouldn't work as expected because 2:10.2.0-3 is lower than 2:10.2. 0-3ubuntu0. 16.04.1. Since Bionic has moved on, this won't cause a problem now, assuming that Artful will be updated the same as Xenial. I suggest using a pattern like 2:10.2. 0-3~ubuntu0. 16.04.1 in the future.