diff options
Diffstat (limited to 'docs/ACE-development-process.html')
| -rw-r--r-- | docs/ACE-development-process.html | 124 |
1 files changed, 0 insertions, 124 deletions
diff --git a/docs/ACE-development-process.html b/docs/ACE-development-process.html deleted file mode 100644 index e6b0fc52503..00000000000 --- a/docs/ACE-development-process.html +++ /dev/null @@ -1,124 +0,0 @@ -<!-- $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> |