I've been thinking about how the Harvesting Process and the BFAV can be used
more effectively to get bugs fixed. I am aware that the Harvesting Process
and the BFAV are being used for more than just bug fixes, but I'm
concentrating on that right now.

The BFAV is a wonderful tool and it has great potential to support a really
effective and efficient Harvesting Process. The Harvesting Process itself
also seems well thought out, and it should be able to work really well
without requiring any major modifications.

Now, about the bug fixes, the thing I'm most concerned about at this point.

First, why am I most concerned about bug fixes? Bugs are a type of problem
that hurts a lot for acceptance and getting involvement from a community. So
they are important to fix. With features, it is a matter of taste whether
you want them this way or that way. With bugs it is different; nobody wants
them. So there is no reason not to try and fix them as quickly as possible.

Second, what is a bug? We need to know if we even contemplate optimizing the
process for getting them fixed. I think the Harvesting Process and the BFAV
could provide a clearer concept of what a bug is. I've studied entries
marked [BUG] and [FIX] in the BFAV, and there is no standard way to find out
what the perceived bug is exactly and why the proposed fix is considered to
be an improvement.

It seems to me that tests are a natural mechanism to work on this. It's
pretty convenient, because an automated testing tool in the form of SUnit is
already integrated with the Squeak system, so running tests is an auomatable
process.

If you think you have identified a bug and a fix for it, you should be able
to write at least one test that, before applying the fix, should pass, but
that fails, right? These tests demonstrate the presence of the bug.

If your proposed fix is correct, the tests that demonstrated the bug should
pass after the fix has been installed, right? In addition, no other tests
should regress.

All these criteria can be automatically verified from a menu choice of the
BFAV.

What remains, after that verification has been completed successfully, is to
assess the validity of the tests themselves, and the non-functional
characteristics of the proposed fix (such as the coding style and the
performance of the new code). This is the manual work that remains for
reviewers.

It the fix is accepted, the supporting tests get added to the regression
test suite.

To know which the relevant regression tests are, there has to be a way of
knowing which tests apply to which parts of the image. The base image tests
are the easiest to identify, so adapting the process to require test cases
with [BUG][FIX] to be accompanied by 2 change sets, one with the tests that
demonstrate the bug in the base image, and one with the proposed fix seems
like a doable first step.

Does this seem like a workable scenario for improving the throughput of at
least the process for fixing bugs in the base image? If the plan has some
validity, how can it be improved?

Regards,

Peter van Rooijen
Amsterdam