Ubuntu
intel-microcode package

  1. Bug #1700373
  2. Comment #10

Comment 10 for bug 1700373

Revision history for this message
Robie Basak (racb) wrote : Re: Please update microcode to version 20170511 on all supported platforms

Some discussion on the approach to take in backporting here:

https://irclogs.ubuntu.com/2017/06/26/%23ubuntu-release.html#t15:46

It seems to me that there are two approaches:

A) Backport only the binary blobs, leaving everything else the same. This was the approach taken in the previous intel-microcode updates in 14.04, and what I was expecting when I began my review.

B) Backport the latest intel-microcode package wholesale. This is what xnox has uploaded for review.

I currently favour A, for reasons debated in the IRC discussion linked above. In short, I think that given that the packaging primarily carries the delivery mechanism, and the delivery mechanism necessarily interacts with other components such as the kernel, unnecessarily updating the delivery mechanism means unnecessarily introducing additional regression risk. I don't think I've been given any counter-example where approach A introduces a regression risk that approach B does not.

I'm declining to accept these uploads into -proposed for now, since I'm not convinced that this approach carries minimal regression risk.

I do agree that given the nature of the update we should probably go with an extra-long aging period in -proposed and slow phasing if possible regardless of approach. It would be nice to give users an opt-in to this update soon, however.

Nothing in my opinion rules out a longer term view on intel-microcode with more frequent updates to keep up with upstream on an ongoing basis to all stable releases. We could choose to do that now, with this update being the first one of those. If so, we should work out a fully documented procedure and exception (under the hardware enablement/environmental rationale). But we don't have that currently. Before accepting this set of backports I'd like to have that agreed so that we don't end up maintaining some exception that we don't want to keep.

I would be happy to follow approach A for now, and work out a full process for ongoing updates for next time. Or we can continue discussion and agree on a different approach.

Opinions welcome. Am I the only one on the SRU team with this view?