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.
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. |
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:
Minor releases of ACE+TAO+CIAO 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+CIAO 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+CIAO users can download and test our latest work in progress. ACE+TAO+CIAO 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 one of the companies that provides commercial support for ACE+TAO.
The first beta following a major/minor release is called a bug-fix-only (BFO) beta. As the name implies this beta will have only fixes for the major or minor releases just made. Types of fixes and checkins that are allowed to go in for the BFO include, bug fixes in the implementation, fixes to the build systems like Makefiles, project files, and MPC files, adding new tests and examples, fixes to the documentation etc. Fixes that are definitely not allowed include, changes to the public interface, refactoring implementations, removing files from the repository, adding new files into the repository etc. The idea is to allow commercial support vendors to stabilize the major or minor release for their product offerings.
Last modified
.