[...]
Hardware Compatibility Lists/ Databases already exist, for driver
subsystems, for distributions...
Some issues with those databases are:
- Users typically can only test one specific combination of a
hardware collection and software collection, at one or a few points
in time.
- Users have difficulties or don't have the means to identify chip
revisions, used protocols etc.
- The databases are typically not conceived to serve additional
purposes like bidirectional contact between developer and user.
These issues notwithstanding, these databases are already highly useful
both for endusers and for developers. That's why they exist.
As has been mentioned elsewhere in the thread,
- bug---hardware associations are sometimes difficult or impossible
to make. For example, the x86-64 platform maintainers are bothered
with "x86-64 bugs" which turn out to be driver bugs on all
platforms.
(We want details descriptions of the hardware environment in a bug
report, but this means we must be able to handle the flood of
false positives in bug---hardware associations, i.e. successively
narrow down which parts of the hardware/software combo are actually
affected, and what other combinations could be affected too.)
- Patch---hardware associations, especially for preemptive regression
tests, are virtually impossible to make. Murphy says that the
regression will hit hardware which the patch submitter or forwarder
thought could never be affected by the patch.
Of course, /sensible/ patch---hardware associations are (1) to try out
fixes for known issues with a specific hardware, (2) to test that a
cleanup patch or refactoring patch or API changing patch to a driver of
very specific hardware ( = a single type or few types with little
variance) does not introduce regressions for this hardware.
--
Stefan Richter
-=====-=-=== -==- =--==
http://arcgraph.de/sr/
-
