Re: [PATCH 17/21] s390x: Fix latent query-cpu-model-FOO error handling bugs

[David Hildenbrand <david@redhat.com>]

[...]

> First search hit.  Here's my second one:
> 
>     Q: What are latent bugs?
> 
>     A: These bugs do not cause problems today. However, they are lurking
>     just waiting to reveal themselves later.  The Ariane 5 rocket
>     failure was caused by a float->int conversion error that lay dormant
>     when previous rockets were slower; but the faster Ariane 5 triggered
>     the problem.  The Millennium bug is another example of a latent bug
>     that came to light when circumstances changed.  Latent bugs are much
>     harder to test using conventional testing techniques, and finding
>     them requires someone with foresight to ask.
> 
> http://www.geekinterview.com/question_details/36689

Google search "latent software BUG"

Hit 1: What I posted


Hit 2:
https://www.quora.com/What-are-some-examples-for-a-latent-defect-in-software-testing

"The problems will not cause the damage currently, but wait to reveal
themselves at a later time. ... E.g. February has 28 days. ... These
defects do not cause damage to the system immediately but wait for a
particular event sometime to cause damage and show their presence."

"Mostly, these types of bugs are unexpected outcome of any corner/edge
case scenarios which was executed with some specific set of test data."


Hit 3: https://sqa.stackexchange.com/questions/9170/what-is-a-latent-bug

"Latent bugs are bugs which exist, but have not yet been discovered.

They are bugs waiting to be found."

"In Software Quality Assurance:

Latent defects are the those which arises in the field, and unknown
until they reported by the field staff."


Hit 4:
https://sqa.stackexchange.com/questions/13980/what-is-the-difference-between-gold-bug-and-latent-bug

"A latent bug is a bug which is present in the system from previous
iterations or release (in your scenario Sprint 1). They are either low
priority bugs, which either went undetected or were not reported."


Same at least for Hit 5, 6, 7 (then I got tired ;) )

https://blog.qatestlab.com/2011/10/21/latent-and-masked-software-bugs-what-is-the-difference/
https://www.testing-whiz.com/blog/3-types-of-unusual-software-defects-you-should-not-miss
https://www.360logica.com/blog/latent-defect-hide-n-seek-defect-software-testing/

Which contain perfect examples and descriptions for latent bugs :)

e.g.,

"Let’s imagine that an application is able to print a document either by
laser printer or by dot matrix printer. To reach this, the application
first searches for the laser printer. In this case if it finds a laser
printer (used by default) it uses this one and prints. In case if it
does not find a laser printer, the application searches for dot matrix
printer. And if the application finds a dot matrix printer, it  gives an
error message. This unleashes a latent defect. Therefore this
application will never search for the dot matrix printer. And the
application never got tested for the dot matrix printer. That means the
accurate conditions were never met for the dot matrix printer. This is
what we call a latent software bug."

[...]

> 
>>> In that light, this change is not a clean up. It is a fix of a latent
>>> bugs, and Markus' aproach to treat it as a bug fix looks right to me. I
>>> would just add a word "latent" or similar, which would even more
>>> distance the patch from "cleanup" meaning.
>>
>> I agree iff there is some way to trigger it. Otherwise, to me it is a
>> cleanup.If it's a BUG, it deserves proper Fixes tags and some
>> description how it can be triggered.
> 
> Yes, a bug that can bite deserves a reproducer and a formal Fixes: tag.

A "BUG that cannot be triggered" is an oxymoron. :)

The code might be "error prone", it might "violate API guidelines", it
might "not obey coding practices". If it can't be triggered, it's - by
definition - not a (latent) BUG.

> 
> The thing we're discussing (however we may want to call it) does not
> have a reproducer, and I think we're in agreement that it doesn't need a
> Fixes: tag.
> 
> However, my patch is not cleaning up something that's dirty, it's fixing
> something that's unequivocally wrong: a violation of a stated interface
> contract.

In general, I don't care about these minor details, but if somebody
literally tells the world for all eternity in a handful of patch
descriptions "David messed up the code by introducing a (latent) BUG
(that cannot be triggered)" I get suspicious. Something nicer (IMHO)
would be "Commit X introduced error prone code, let's rework that to
make it more stable in the future and obey the "error API" guidelines. I
hope you see the difference ;)

> 
> Your point that the commit message should not confuse people looking for
> real bugs is well taken.  I think "latent bug" is clear enough, and also
> concise.  I'm of course open to better phrasings.
> 
>    s390x: Fix currently harmless query-cpu-model-FOO error API violations
> 
> feels no clearer to me than
> 
>    s390x: Fix latent query-cpu-model-FOO error handling bugs
> 
> It's also too long.
> 
> I tried.  Your turn :)


s390x: Fix query-cpu-model-FOO error API violations

s390x: Make query-cpu-model-FOO error handling less error prone

s390x: Cleanup error handling in query-cpu-model-FOO

s390x: Rework error handling in query-cpu-model-FOO

...

but, enough time spent on this, feel free to continue with this however
you want.

-- 
Thanks,

David / dhildenb