At 19:23 15/09/2004 +0900, Curt Sampson wrote:
>On Wed, 15 Sep 2004, Neil Hopcroft wrote:
>
> > During the development phase 24 hour defect turnaround is practical. I
> > would be extremely wary of fixes turned around quicker than that since they
> > plainly haven't been tested properly....
>
>It is not plain that they have not been tested properly. It really
>depends on the nature of the bug and the testing framework that is
>in place. I have been able to do two-hour turnaround on fairly major
>bug fixes in past projects because everything affected by them was
>completely covered by a comprhensive automated test framework. (Note:
>no area of the Linux kernel, as far as I am aware, has any sort of
>comprehensive test coverage.)
>
>On the other hand, there will be nightmare bugs. Take, for example,
>a bug in a driver for a widely-used piece of hardware where the bug
>manifests itself only on certain examples of a particular model of
>phone. You may have to test against hundreds of handsets in order to be
>really certain that you've not broken something else.
How long does it take to build the entire system? If you're not going
through a full integration process the bug fix has not been tested in the
context in which it will be used. Obviously different fixes take different
amounts of testing but any code fix that is quicker than the
build-integrate-release cycle is suspicious (there are a bunch of resource
fixes that can be made without the full cycle, localisation errors, etc).
It is probably true that the fix is known within two hours, but a known fix
is quite different to a released fix - turnaround time comparisons must
include the release cycle. Indeed, both metrics are useful.
Neil
Received on Fri Sep 17 15:18:30 2004