home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!think.com!spool.mu.edu!olivea!apple!applelink.apple.com
- From: JOLICOEUR.B@AppleLink.Apple.COM (Jolicoeur, Bernadette)
- Newsgroups: comp.sys.mac.oop.macapp3
- Subject: Re: Takeover
- Message-ID: <725574109.4228004@AppleLink.Apple.COM>
- Date: 28 Dec 92 20:08:00 GMT
- Sender: daemon@Apple.COM
- Organization: AppleLink Gateway
- Lines: 26
-
- Hello all,
-
- I feel the need to shed some "light of reality" on the takeover discussion.
- Many people have put forth their ideas as to how a bug fix might be made to the
- MacApp 3.0.1 code base by an external developer. More than one person has
- suggested that these fixes could be easy and relatively localized for "easy
- testing". Within the last day or two somebody has actually recommended a "by
- sight" verification of bug fixes.
-
- Now let me speak from a point of experience. We (the MacApp SQA team) learned
- something very important during the MacApp development process: changing any
- MacApp code can have some unexpected side effects. We did let an alpha release
- of MacApp go to our internal source code management group (the last stop before
- sending a release out) *once* with a last minute "by sight" bug fix in it.
- Three engineers looked at the fix and "ok'd" it. That fix resulted in a new
- crashing bug that developers would have found rather quickly. The lesson
- learned - we always did a full testing cycle for each release of MacApp after
- *every* bug fix was in. A full testing cycle is an 8 person-week job.
-
- I say all of this not in the attempt to derail or undermine the takeover
- discussion but to let people know just what is involved in a "simple" or not so
- simple bug fix to MacApp.
-
- Bernadette Jolicoeur
- ex-MacApp SQA team member
-
-