diff options
| author | levine <levine@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 1999-07-12 17:15:47 +0000 |
|---|---|---|
| committer | levine <levine@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 1999-07-12 17:15:47 +0000 |
| commit | 2e24add3cfd252b67d82b78b0de02f9d525b9f08 (patch) | |
| tree | 8bfc5334b14267e002f74d85f08fd411aee44a2e /docs/ACE-development-process.html | |
| parent | 05c026cdbd99ce11b922e9ee43d3cc01aecdc5d0 (diff) | |
| download | ATCD-2e24add3cfd252b67d82b78b0de02f9d525b9f08.tar.gz | |
ChangeLogTag: Mon Jul 12 12:14:45 1999 David L. Levine <levine@cs.wustl.edu>
Diffstat (limited to 'docs/ACE-development-process.html')
| -rw-r--r-- | docs/ACE-development-process.html | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/docs/ACE-development-process.html b/docs/ACE-development-process.html new file mode 100644 index 00000000000..e6b0fc52503 --- /dev/null +++ b/docs/ACE-development-process.html @@ -0,0 +1,124 @@ +<!-- $Id$ --> + +<html> + <head> + <title>ACE Development Process</title> + <link rev=made href="mailto:levine@cs.wustl.edu"> + </head> + +<body text = "#000000" +link="#000fff" +vlink="#ff0f0f" +bgcolor="#ffffff"> + +<hr> +<h3>The ACE Development Process</h3> + +<hr><p> + <font size=-1> + Last modified <!--#echo var="LAST_MODIFIED" -->.<p> + </font> + +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.<p> + +An important concept to keep in mind is <em>risk</em>. Before you +commit <em>any</em> 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.<p> + +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.<p> + +A good development process looks like:<p> +<ol> + <li>Every change to ACE+TAO must have a bug report. <em>Change</em> + includes fixes, enhancements, updates, and so on.<p> + <!-- The link to bugzilla is intentionally local. --> + <li><a href="http://ace/bugzilla">Create a bug report</a>.<p> + <li>Accept the bug report if you are going to implement the change.<p> + <li>Implement the change in your workspace(s).<p> + <li>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 plaform. + Or as complicated as rebuilding and test all of ACE and TAO on + all platforms that we have.<p> + <li>Create an appropriate ChangeLog entry.<p> + <li>Commit the change using a ChangeLogTag commit message.<p> + <li>Respond to the requestor of the change, if any. Please do this + <em>after</em> committing your change.<p> + <li>Make sure that the requestor is listed in the THANKS file.<p> + <li>Update the bug report to indicate resolution.<p> + <li>Monitor the next round of build/tests for problems with your change.<p> + <li>Respond immediately to reports of problems with your changes.<p> +</ol> + +<p><hr> + +A bug should typically follow this life cycle:<p> +<center><table cellpadding=5 border=0> +<tr> + <td>Submitter:</td> + <td>Enters problem</td> +<tr> + <td>Bugmaster:</td> + <td>Assigns</td> +<tr> + <td>Owner:</td> + <td>Accepts</td> +<tr> + <td>Owner:</td> + <td>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.<br> + If it's a duplicate, set it to Resolved/DUPLICATE. + Fix code, commit changes, set to Resolved.</td> +<tr> + <td>Submitter:</td> + <td>Tests it again; set to Verified (pass) or Reopened (fail)</td> +<tr> + <td>Owner:</td> + <td>After next release is done, re-test; sets to Closed or Reopened.</td> +</table></center> + + +<p><hr> + +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, <em>i.e.</em>, it builds and runs cleanly on +all platforms.<p> + +The build master:<p> +<ul> + <li>Reminds people to check build logs. Developers are still + responsible for verifying that their changes are clean.<p> + <li>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.<p> + <li>Verifies that the final round of builds/tests are clean.<p> + <li>Creates the kits.<p> + <li>Unfreezes the CVS repository.<p> + <li>Sends email to appropriate news groups announcing the new kits.<p> + <li>Passes the mantle on to the next build master.<p> +</ul> + +If another developer interferes with the build master's duties, +the build master has the unilateral authority to pass the mantle +to the violater. This is intentional, desirable, beneficial, and +the right thing to do.<p> + +</body> +</html> |