The ACE Development Process
Last modified Wednesday, 06-Nov-2002 19:52:00 EST.
In order to improve the quality of our software and minimize
development effort, we'll try to follow a more structured development
process. It is 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 this large a 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 good 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 tests on one platform.
Or as complicated as rebuilding and test all of ACE and 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.
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 master. (The role may be shared by
multiple people.) The build master is responsible for ensuring that
the next kits are clean, i.e., it builds and runs cleanly on
all platforms.
The build master:
- Reminds people to check build logs. Developers are still
responsible for verifying that their changes are clean.
- Freezes the CVS repository when it's decided to no more
non-critical changes will be accepted for the next kits.
The build master 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
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 master.
If another developer interferes with the build master's duties,
the build master has the unilateral authority to pass the mantle
to the violator. This is intentional, desirable, beneficial, and
the right thing to do.