Adam Williamson <awilliam <at> redhat.com> writes:
> I think this is a good idea, yeah. Wording the criterion could be a
> little tricky, though - it feels like one of those areas where you
> have
> to be careful and precise about how you encapsulate 'works'. How
> important are false negatives? False positives? Etc. Please do post
> a
> draft, though!
I think they're both important. It definitely shouldn't PASS on a bad
image. And
if it FAILs on a good image, then it's useless since people have to
be told to
avoid mediacheck. So it should PASS if and only if the image is good.
I also believe there must be no false (positive/negative) results. The principle of
checksum is to check it and be _sure_ (let's disregard checksum collisions).
But I'm not sure we want to require that all images have embedded checksums. That
looks more like engineering decision to me. Maybe it's not always technically
possible.
Also, I'm not sure we want to mandate that there is an UI element for running the
check (e.g in syslinux menu). From QA POV, of course it should be there. But I can imagine
some engineers and UX designers might disagree for some reason or another.
Is this too meek?
"If there is an embedded checksum in the image, it must match. If there is a related
UI element displayed after booting the image, it must work and display the correct
result."
We can require more, as mentioned above, but then we should probably start a discussion
also on devel list, just to get other people opinions. What do you think?