So, “Where problems could occur” is meant to be a prompt for you, the domain expert, to identify the types of regression that might be possible with this update (and so should inform the test case - we should be checking that those regressions don't occur).
For a hardware support package like this, there are a range of common possibilities: 1. Sometimes, patches are just adding new PCI IDs (or similar) to the driver. In these cases, the only likely failure modes are a misbuild, or the appearance of a new supported device changing system behaviour in unwanted ways (One possible example here would be if a system played video fine without HW acceleration but adding the necessary FW to enable HW decoding exposed driver bugs which caused video playback to crash). * Notably, these type of updates take a device from definitely not working to (hopefully) working. There's virtually no¹ risk of regression on devices which currently work; this is an easy SRU. It's also generally easy for us, in the SRU team, to *see* that this is an easy SRU. 2. Sometimes, patches add both device IDs and a bunch of code that's only executed on the new devices. This is roughly the same case as above. * It might not be obvious to us, in the SRU team, that an update is in this category. You, as the domain expert, can help by identifying it for us :) 3. Sometimes, patches for adding hardware support require changing code that's shared with existing devices. In this case, the scope for problems extends beyond the new device - mistakes or oversights in the changes could break existing, working devices. Here you can help as a domain expert by identifying the set of existing devices that might be affected, how a problem might manifest (is it likely to fail completely? Is it likely to have sub-optimal quality? Is it likely to increase CPU usage but otherwise be invisible?), and how we will test to ensure users with existing, working, devices *don't* experience a regression. In this particular case, I see there's a bunch of data tables being added, some extra enum values, some extra descriptors in a format array; these are all type 1/2 updates. But I also see some changes to common code, and some changes to existing data arrays, what looks like a type 3 change. For these we want to know the scope of the hardware that this might apply to and whether that hardware is *currently* expected to work or not. ¹: Well, very little risk of regression. Misbuilds could break existing working hardware! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2084059 Title: OVTI08F4:00: number of CSI2 data lanes 2 is not supported To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ipu6-drivers/+bug/2084059/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
