[...] > 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
