Open Source (was Don't you just wish Rev would do this?)

[Bob Warren]

Chipp wrote:

>Updating Rev each time a bug fix is made, could be a dicey proposition, as
typcially after a bug is fixed, there still should be unit testing, then
more inside testing, then beta testing, then rc testing, etc. to make sure
fixing the bug didn't break other stuff. I think Rev has taken the position
to do all this in the same cycle, which for a company with limited
resources, is a good way (IMO) to go.

The existing architecture of course could do just as you suggest. But my
biggest fear with a system like this would be we would never end up with a
fairly stable release. The complexity of Rev could create unforseen problems
when fixing one bug only to see a ripple effect of it creating many more.

----------------------------------------------------------
Chipp,

I am just as concerned about stability as you are. But to help explain the basis of my suggestion better, imagine the following situation:

You go to a restaurant, sit down, and order your meal. After what seems to be an eternity, the waiter comes to you and says, "Well sir, your dinner is ready, but the chef has made such an awful mess in the kitchen that you need to help clean it up for an hour before you can sit down to eat."

I imagine your reply would not be very polite! Although it is not an exact parallel, there is something of the essence of this situation in what happens at Rev. The Rev production procedures generate too many bugs, and this needs to be corrected as much as possible.

What I have suggested does not subtract from the current production procedures, but I am not sure that it adds to them. However, you are quite right to point out the economic considerations. Apart from the normal procedures of production, testing and final release, I have suggested a post-release cleanup, hopefully to be completed before the next release is due. But don't Rev have to do this anyway? As far as I can see it, you can either prevent bugs, or you can cure them. At the moment, Rev seems to prefer to cure them. I am now suggesting greater prevention, that's all.

What also gets in the way is Rev's insistence on exaggerated secrecy about the exact contents of their plans. I appreciate the considerations, but such exaggeration also prevents open user participation in the production process. Your are probably tired of my plugging Ubuntu, but Rev could well take a leaf out of their book. This is what they do, and it works very well:

1. Their exact plans for the next release are published.
2. Work begins on the next release, and a certain amount of work is achieved.
3. As work progresses, they produce a series of "alpha" releases: "alpha 1", "alpha 2", "alpha 3", and so on. These are completely free for the public to download and test. When members of the public find bugs, they are reported through the normal channels.
4. Finally, they get to the beta stage, where all the additional procedures of global testing are applied. Normally, a single version is all that is necessary.
5. When they are satisfied, the new release is unleashed.

There is no "signing on" or forms to fill in/out to be granted the "privilege" of participation in alpha or beta testing. All are immediately welcome. The public's participation in alpha releases, beta releases and post-production debugging is identical, and non-beaurocratic.

In sum, I would suggest that the best way of offsetting the costs incurred by really adequate bug prevention is to involve the users in the production process.

Finally, I would also suggest that no really new ideas are necessary in order to improve things at Rev. You just have to look at what other people do and adapt the good ideas out there to your own needs.

Bob