home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / oop / macapp3 / 347 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  2.5 KB
  1. Path: sparky!uunet!spool.mu.edu!olivea!apple!applelink.apple.com
  2. From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re2: Takeover - QA
  5. Message-ID: <726183898.0288319@AppleLink.Apple.COM>
  6. Date: 4 Jan 93 21:40:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 50
  10.  
  11. Jesse --
  12.  
  13. I appreciate your points, and agree with your general approach toward QA.
  14. However, I am trying to address some very specific issues with current MacApp
  15. maintenance, faced as we are with the existing situation of many shipping or
  16. soon-to-be-shipping apps and very minimal ongoing Apple support.
  17.  
  18. > You discuss a bug-fix and use phrases like "guaranteed" and "cannot possibly
  19. > cause..." Don't tempt fate.
  20.  
  21. Ah, but to refrain from tempting fate is to refrain from living life itself!
  22. <end of poetical interlude>
  23.  
  24. > Without discussing this particular bug,...
  25.  
  26. This is a specific example. Discussing this particular bug is precisely the
  27. point.
  28.  
  29. > E.g., pushing the size of a code segment up by a few bytes - just enough
  30. > to cause overflows in an application that links user code into that segment.
  31.  
  32. This would happen to the hapless user even after Apple did eight person-weeks
  33. of MacApp QA testing. This is not a QA problem.
  34.  
  35. > We apply bug fixes if we need them (and we usually can do them in subclasses
  36. > of our own)
  37.  
  38. As long as you can do them in subclasses you are reasonably safe. Some do
  39. require modifying the source code, though. (E.g., they affect global
  40. procedures.) In those cases, you have to reapply each fix each time you load an
  41. updated officially-sanctioned release of MacApp. If Apple can put out the fix
  42. in its official Bug Doc, why can't it apply the fixes itself?
  43.  
  44. And if the answer to that is that Apple won't apply the fix until it can do its
  45. eight person-weeks of QA, but Apple _is_ willing to list the fix in its Bug Doc
  46. in the interim, then how dare you apply the bug fix yourself, without your own
  47. eight person-week QA cycle?
  48.  
  49. > "[why do all of these discussions insist that all bug work and QA needs to be
  50. > done in a vacuum???]". The answer is because the greater the degree of
  51. > separation between the coder and the tester, the more likely the
  52. > testing is to be thorough.
  53.  
  54. No, I meant "why do all of these discussions insist that all bug fixes have to
  55. be worked out by Apple (or MADA, or whomever), applied by Apple, tested by
  56. Apple, and officially released by Apple, without recognizing the collective
  57. genius and testing facilities of all the developers on MacAppTech$???"
  58.  
  59. -- Dave
  60.  
  61.