Re: Final Criterion for working built-in mediacheck

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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?
-- 
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test



[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux