diff options
| author | William R. Otte <wotte@dre.vanderbilt.edu> | 2008-03-04 13:56:48 +0000 |
|---|---|---|
| committer | William R. Otte <wotte@dre.vanderbilt.edu> | 2008-03-04 13:56:48 +0000 |
| commit | c4078c377d74290ebe4e66da0b4975da91732376 (patch) | |
| tree | 1816ef391e42a07929304908ac0e21f4c2f6cb7b /ACE/docs/ACE-development-process.html | |
| parent | 700d1c1a6be348c6c70a2085e559baeb8f4a62ea (diff) | |
| download | ATCD-c4078c377d74290ebe4e66da0b4975da91732376.tar.gz | |
swap in externals for ACE and TAO
Diffstat (limited to 'ACE/docs/ACE-development-process.html')
| -rw-r--r-- | ACE/docs/ACE-development-process.html | 207 |
1 files changed, 0 insertions, 207 deletions
diff --git a/ACE/docs/ACE-development-process.html b/ACE/docs/ACE-development-process.html deleted file mode 100644 index 5c4717c199c..00000000000 --- a/ACE/docs/ACE-development-process.html +++ /dev/null @@ -1,207 +0,0 @@ -<!-- $Id$ --> - -<html> - <head> - <title>ACE+TAO Development and Release 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+TAO Development and Release Process</h3> - -To improve the quality of our software and minimize development -effort, we try to follow the structured development and release -process 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 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.<p> - -<hr> -<h3>The ACE+TAO+CIAO Development Process</h3> - -The ACE+TAO+CIAO 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. - <li><a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">Create a -bug report</a>. - <li>Accept the bug report if you are going to implement the change. - <li>Implement the change in your workspace(s). - <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+TAO tests on at least two - platforms. - Or as complicated as rebuilding and test all of ACE+TAO on - all platforms that we have. - <li>Create an appropriate ChangeLog entry. - <li>Commit the change using a ChangeLogTag commit message only when - you are available the next 3 days to resolve any issues. - If you aren't available, hold your commit until you are available - <li>Respond to the requester of the change, if any. Please do this - <em>after</em> committing your change. - <li>Make sure that the requester is listed in the THANKS file. - <li>Update the bug report to indicate resolution. - <li>Monitor the next round of build/tests for problems with your change. - Because there are slow systems it can take up to 4 days to get all builds done. - <li>Respond immediately to reports of problems with your changes. -</ol> - -<p><hr> -<H3>Bug Lifecycles</H3> -<P> - -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> -<H3>The Role of the Build Czar</H3> -<P> - -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, <em>i.e.</em>, it builds and runs cleanly on all -platforms. The status of all ACE+TAO builds is tracked automatically -<A HREF="http://tao.doc.wustl.edu/scoreboard/"</A>online</A>.<p> - -A comprehensive summary of the build czar's role is available <A HREF="bczar/bczar.html">here</A>. -This role is briefly summarized below:<p> -<ul> - <li>Remind people to check build logs. Developers are still - responsible for verifying that their changes are clean. - <li>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. - <li>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. - <li>Verifies that the final round of builds/tests are clean. - <li>Creates the kits. - <li>Unfreezes the CVS repository. - <li>Sends email to appropriate news groups announcing the new kits. - <li>Passes the mantle on to the next build czar.<p> -</ul> - -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.<p> - -<p><hr> -<H3>The ACE+TAO+CIAO Release Process</H3> -<P> - -Minor releases of ACE+TAO+CIAO occur periodically, typically twice a -year. Minor releases have two-digit numbers, <EM>e.g.,</EM> 5.3. -Major releases are released infrequently, typically once a year. -Major releases are 1-digit numbers, <EM>e.g.,</EM>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. <P> - -Between major/minor releases, we release betas periodically, -<EM>e.g.,</EM> 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, <EM>e.g.,</EM> 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 <A -HREF="http://www.cs.wustl.edu/~schmidt/commercial-support.html"> -commercial support</A> for ACE+TAO.<P> - -The first beta following a major/minor release is called a -<EM>bug-fix-only</EM> (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. <p> - -<p><hr> -<H3>Contributions from the Open-Source Community</H3> -<P> - -Over the years, ACE+TAO+CIAO have benefitted significantly from -contributions by <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE-members.html">thousands</A> -of deveopers in the open-source community. To avoid fragmentation of -the code base, by submitting comments, suggestions, code, code -snippets, techniques (including that of usage) and algorithms -(collectively ``Submissions''), submitters acknowledge that they have -the right to do so, that any such Submissions are given freely and -unreservedly, and that they waive any claims to copyright or -ownership. In addition, submitters acknowledge that any such -Submission might become part of the copyright maintained on the -overall body of code that comprises the open-source DOC Group -software. By making a Submission, submitter agree to these terms. -Moreover, submitters acknowledge that the incorporation or -modification of such Submissions is entirely at the discretion of the -moderators of the open-source DOC software projects or their -designees. - -<hr><p> - <font size=-1> - Last modified -<!--#echo var="LAST_MODIFIED" -->.<p> - </font><hr> - -Back to <A HREF="index.html">ACE Documentation Home</A>. - -</body> -</html> |