ACE+TAO Development and Release Process

The ACE+TAO Development and Release Process

To improve the quality of our software and minimize development effort, we try to follow the structured development and release process described below.

An important concept to keep in mind is risk. Before you commit any change to ACE+TAO, please consider the effects that it will have. Could it possibly cause a build failure, on any platform? Could it possibly cause different run-time behavior? And so on. If so, it is your responsibility to adequately build and test with the change, in order to verify that it has no unintended effects.

Please keep in mind the cost of committing a mistake. It may take you only a few seconds to fix, but its cost to the group may be much larger. With our large group, workspace updates and builds are likely to happen at any time. If one break, it can take hours to rebuild it. And each developer that was waiting for a successful build would be blocked for the duration of the broken build, the fix, and the rebuild.

The ACE+TAO Development Process

The ACE+TAO development process looks like:

Every change to ACE+TAO must have a bug report. Change includes fixes, enhancements, updates, and so on.
Create a bug report.
Accept the bug report if you are going to implement the change.
Implement the change in your workspace(s).
Test the change sufficiently to demonstrate that it both does what is intended, and doesn't break anything. The test may be as simple as building and running the ACE+TAO tests on one platform. Or as complicated as rebuilding and test all of ACE+TAO on all platforms that we have.
Create an appropriate ChangeLog entry.
Commit the change using a ChangeLogTag commit message.
Respond to the requester of the change, if any. Please do this after committing your change.
Make sure that the requester is listed in the THANKS file.
Update the bug report to indicate resolution.
Monitor the next round of build/tests for problems with your change.
Respond immediately to reports of problems with your changes.

Bug Lifecycles

A bug should typically follow this life cycle:

Submitter:	Enters problem
Bugmaster:	Assigns
Owner:	Accepts
Owner:	Reproduces problem - if it needs a new test, write it and put it in the regression tests. If it can't be reproduced, set to Resolved/CANT_FIND. If it's a duplicate, set it to Resolved/DUPLICATE. Fix code, commit changes, set to Resolved.
Submitter:	Tests it again; set to Verified (pass) or Reopened (fail)
Owner:	After next release is done, re-test; sets to Closed or Reopened.

The Role of the Build Czar

At all times, we'll have a build czar. The role may be shared by multiple people. The build czar is responsible for ensuring that the next kits are clean, i.e., it builds and runs cleanly on all platforms. The status of all ACE+TAO builds is tracked automatically online.

A comprehensive summary of the build czar's role is available online. This role is briefly summarized below:

Remind people to check build logs. Developers are still responsible for verifying that their changes are clean.
Fix minor problems caused by compilation errors. More complex problems should be fixed by the developers who caused them. The build czar should help track down the guilty parties.
Freeze the CVS repository when it's decided to no more non-critical changes will be accepted for the next kits. The build czar has the final say over when the freeze is implemented. The tendency to implement a freeze sooner than later is intentional, desirable, beneficial, and the "Right Thing"[TM] to do.
Verifies that the final round of builds/tests are clean.
Creates the kits.
Unfreezes the CVS repository.
Sends email to appropriate news groups announcing the new kits.
Passes the mantle on to the next build czar.

If another developer interferes with the build czar's duties, the build czar has the unilateral authority to pass the mantle to the violator. This is also intentional, desirable, beneficial, and the Right Thing[TM] to do.

The ACE+TAO Release Process

Minor releases of ACE+TAO occur periodically, typically twice a year. Minor releases have two-digit numbers, e.g., 5.3. Major releases are released infrequently, typically once a year. Major releases are 1-digit numbers, e.g.,5, that include substantially new functionality. Both major and minor releases are carefully tested on all platforms the ACE+TAO run on. In particular, we do not put out major or minor releases of ACE+TAO until all the compilations and regression tests work successful on all the platform we support.

Between major/minor releases, we release betas periodically, e.g., once a month, so that ACE+TAO users can download and test our latest work in progress. ACE+TAO beta kits have three-digit numbers, e.g., 5.3.1. Betas are often not as stable as the major or minor releases, but they often contain important fixes that aren't in the official releases. Although we try to ensure the quality of betas, they may not compile cleanly on all platforms, nor will they necessarily pass all of the tests on all platforms. They will, however, compile cleanly and pass most tests on most platforms. As usual, we endeavor to fix any problems that arise as quickly as possible. Naturally, if you require 100% predictable stability and support, please contact OCI for TAO commercial support or Riverace for ACE commercial support.

Last modified .

Back to ACE Documentation Home.