diff options
| author | schmidt <douglascraigschmidt@users.noreply.github.com> | 2001-03-26 21:47:34 +0000 |
|---|---|---|
| committer | schmidt <douglascraigschmidt@users.noreply.github.com> | 2001-03-26 21:47:34 +0000 |
| commit | 22839019d64f6412b4352b3b7a97dc9a07856464 (patch) | |
| tree | b6ab5b168c823169bdec7b1ac3bb71ea90db67af /docs | |
| parent | dc7b47e328ac184eed767b8287f918a46eb5d68e (diff) | |
| download | ATCD-22839019d64f6412b4352b3b7a97dc9a07856464.tar.gz | |
ChangeLogTag:Mon Mar 26 13:00:37 2001 Carlos O'Ryan <coryan@uci.edu>
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ACE-development-process.html | 104 | ||||
| -rw-r--r-- | docs/index.html | 9 |
2 files changed, 75 insertions, 38 deletions
diff --git a/docs/ACE-development-process.html b/docs/ACE-development-process.html index fed922fecf6..6b17c6feb15 100644 --- a/docs/ACE-development-process.html +++ b/docs/ACE-development-process.html @@ -2,7 +2,7 @@ <html> <head> - <title>ACE Development Process</title> + <title>ACE+TAO Development and Release Process</title> <link rev=made href="mailto:levine@cs.wustl.edu"> </head> @@ -12,16 +12,11 @@ vlink="#ff0f0f" bgcolor="#ffffff"> <hr> -<h3>The ACE Development Process</h3> +<h3>The ACE+TAO Development and Release 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> +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 @@ -33,13 +28,16 @@ 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> +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> -A good development process looks like:<p> +<hr> +<h3>The ACE+TAO Development Process</h3> + +The ACE+TAO 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> @@ -49,8 +47,8 @@ A good development process looks like:<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 platform. - Or as complicated as rebuilding and test all of ACE and TAO on + as simple as building and running the ACE+TAO tests on one platform. + Or as complicated as rebuilding and test all of ACE+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> @@ -63,6 +61,8 @@ A good development process looks like:<p> </ol> <p><hr> +<H3>Bug Lifecycles</H3> +<P> A bug should typically follow this life cycle:<p> <center><table cellpadding=5 border=0> @@ -90,37 +90,73 @@ A bug should typically follow this life cycle:<p> <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 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> +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://ringil.ece.uci.edu/scoreboard/"</A>online</A>.<p> -The build master:<p> +The build czar's role is to:<p> <ul> - <li>Reminds people to check build logs. Developers are still + <li>Remind 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 + <li>Freeze 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 + 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 + later is intentional, desirable, beneficial, and the "Right Thing"[TM] 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> + <li>Passes the mantle on to the next build czar.<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 violator. This is intentional, desirable, beneficial, and -the right thing to do.<p> +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 Release Process</H3> +<P> + +Minor releases of ACE+TAO occur periodically, typically twice a year. +Minor releases have two-digit numbers, <EM>e.g.</EM>, 5.1. 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 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 users can download and +test our latest work in progress. ACE+TAO beta kits have three-digit +numbers, <EM>e.g.,</EM>5.1.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 <A HREF="http://www.theaceorb.com/">OCI</A> +for TAO commercial support or <A +HREF="http://www.riverace.com/">Riverace</A> for ACE commercial +support. <P> + +<hr><p> + <font size=-1> + Last modified <!--#echo var="LAST_MODIFIED" -->.<p> + </font><hr> -<hr> Back to <A HREF="index.html">ACE Documentation Home</A>. </body> diff --git a/docs/index.html b/docs/index.html index 183fe2f6bb0..f3cb339e2e1 100644 --- a/docs/index.html +++ b/docs/index.html @@ -11,7 +11,8 @@ <h1>ACE Documentation Home</h1> -Things you wanted to know about ACE, but were afraid to ask. +Everything you've always wanted to know about ACE, but were afraid to +ask. <P> <hr> @@ -60,11 +61,11 @@ Things you wanted to know about ACE, but were afraid to ask. <hr> -<h2>ACE development</h2> +<h2>ACE Development</h2> <ul> - <li><a href="ACE-development-process.html">Development Process</a> - The process we use - to develop the ACE library. + <li><a href="ACE-development-process.html">Development and Release Process</a> - The process we use + to develop and release the ACE library. <li><a href="ACE-guidelines.html">Style Guide</a> - How to write compliant ACE code. <li><a href="ACE-porting.html">Porting</a> - What to do to port to a new platform. <li><a href="exceptions.html">Exception Macros</a> - How to properly use the ACE TRY |