Comment 6 for bug 1995606

Ok. So, sorry about all the back and forth. Partially this is because I'm more familiar with thermald than others on the SRU team, and so don't necessarily make things explicit that should be.

At a high level, what the SRU team (in general, so that *I* don't have to be the single point of failure) is looking for is:

*) What is the scope of potential regressions - what hardware *could* this effect, what possible effects could it have
  - The answer to “what hardware” is: the list of CPUIDs in tdh_engine.cpp:id_table. This is SandyBridge onwards
  - The answer to “what effects” is: temperature throttling problems - either reduced performance of CPU (and GPU?) due to unnecessary throttling, or instability due to not controlling temperatures <FEEL FREE TO EXPAND HERE>

*) What is the scope of *upstream* support - what systems do *they* test on, and expect to continue to work.
  - Relatedly: what testing does upstream do
  - What do we do if upstream doesn't test on hardware that we support (ie: *we* care about all the hardware)

*) What is the process we are going to use to verify that upstream doesn't drop support for systems?
  - Upstream doesn't seem to make it very easy to identify this
  - eg: the current SRU includes dropping the MSR poking support. What process do we/will we have to catch such cases?

*) What is the process for testing that an upload does not regress
  - The [Test Case] above is good for systems with KBL or newer processors
  - thermald also supports systems from SandyBridge onwards - how are we testing these? These are still supported by Ubuntu; we need a testing system more than “maybe users will report regressions”, particularly since it's not necessarily going to be clear to users that “my system got slower” is related to the thermald update.

Most of those questions are covered above, I think, but some could do with your input.

Particularly the SandyBridge+ question is an important one to answer.