🚀 go-pugleaf

Dave,
 
I beg to differ with your approach to QA. Bernadette is right in that a full
set of QA is needed for every bug fix (or set thereof).
 
You discuss a bug-fix and use phrases like "guaranteed" and "cannot possibly
cause..." Don't tempt fate.
 
Without discussing this particular bug, I can easily conjure up a number of
scenarios where this type of bug fix could cause problems. E.g., pushing the
size of a code segment up by a few bytes - just enough to cause overflows in an
application that links user code into that segment.
 
I participated in a "harmless bug fix" that inserted an extra blank in a title
string in order to correct a slight off-centering. Because the gods of software
were playful that day, this insertion of ONE BLANK (" ") in the format string
led directly to the total collapse of the major financial data entry system at
a very sensitive institution. Data entry workers who should have started keying
at 8 AM started at 2:30 PM.
 
I periodicially look at the official bug list, and -- as most people do -- I
file away MacApp.Tech$ links that look as if they may touch on bugs/solutions
that we may need in the future. We apply bug fixes if we need them (and we
usually can do them in subclasses of our own) and rely on MacApp which has been
thoroughly QA'd to remain imperfect but stable.
 
Finally, you write, "[why do all of these discussions insist that all bug work
and QA needs to be done in a vacuum???]". The answer is because the greater the
degree of separation between the coder and the tester, the more likely the
testing is to be thorough. I know of one case in which the testing staff isn't
even told what specific bug fixes are to be tested: they are to insure the
complete integrity of the new code; on a second pass, they test the specific
fixes.
 
Jesse