ACE/docs/ACE-development-process.html

   1 <!--  -->
   2
   3 <html>
   4   <head>
   5     <title>ACE+TAO Development and Release Process</title>
   6     <link rev=made href="mailto:levine@cs.wustl.edu">
   7   </head>
   8
   9 <body text = "#000000"
  10 link="#000fff"
  11 vlink="#ff0f0f"
  12 bgcolor="#ffffff">
  13
  14 <hr>
  15 <h3>The ACE+TAO Development and Release Process</h3>
  16
  17 To improve the quality of our software and minimize development
  18 effort, we try to follow the structured development and release
  19 process described below.<p>
  20
  21 An important concept to keep in mind is <em>risk</em>.  Before you
  22 commit <em>any</em> change to ACE+TAO, please consider the effects
  23 that it will have.  Could it possibly cause a build failure, on any
  24 platform?  Could it possibly cause different run-time behavior?  And
  25 so on.  If so, it is your responsibility to adequately build and test
  26 with the change, in order to verify that it has no unintended
  27 effects.<p>
  28
  29 Please keep in mind the cost of committing a mistake.  It may take you
  30 only a few seconds to fix, but its cost to the group may be much
  31 larger.  With our large group, workspace updates and builds are likely
  32 to happen at any time.  If one break, it can take hours to rebuild it.
  33 And each developer that was waiting for a successful build would be
  34 blocked for the duration of the broken build, the fix, and the
  35 rebuild.<p>
  36
  37 <hr>
  38 <h3>The ACE+TAO Development Process</h3>
  39
  40 The ACE+TAO development process looks like:<p>
  41 <ol>
  42   <li>Every change to ACE+TAO must have a bug report.  <em>Change</em>
  43     includes fixes, enhancements, updates, and so on.
  44   <li><a href="https://github.com/DOCGroup/ACE_TAO/issues">Create a
  45 an issue</a>.
  46   <li>Accept the bug report if you are going to implement the change.
  47   <li>Implement the change in your workspace(s) using a branch. Clearly
  48     document each commit because that information is gathered into our
  49     changelog
  50   <li>Test the change sufficiently to demonstrate that it both does
  51     what is intended, and doesn't break anything.  The test may be
  52     as simple as building and running the ACE+TAO tests on at least two
  53     platforms.
  54     Or as complicated as rebuilding and test all of ACE+TAO on
  55     all platforms that we have.
  56   <li>Merge the changes only to master when
  57     you are available the next 3 days to resolve any issues.
  58     If you aren't available, hold your merge until you are available
  59   <li>Respond to the requester of the change, if any.  Please do this
  60     <em>after</em> merging your change.
  61   <li>Make sure that the requester is listed in the THANKS file.
  62   <li>Update the bug report to indicate resolution.
  63   <li>Monitor the next round of build/tests for problems with your change.
  64    Because there are slow systems it can take up to 4 days to get all builds done.
  65   <li>Respond immediately to reports of problems with your changes.
  66 </ol>
  67
  68 <p><hr>
  69 <H3>Bug Lifecycles</H3>
  70 <P>
  71
  72 A bug should typically follow this life cycle:<p>
  73 <center><table cellpadding=5 border=0>
  74 <tr>
  75   <td>Submitter:</td>
  76   <td>Enters problem</td>
  77 <tr>
  78   <td>Bugmaster:</td>
  79   <td>Assigns</td>
  80 <tr>
  81   <td>Owner:</td>
  82   <td>Accepts</td>
  83 <tr>
  84   <td>Owner:</td>
  85   <td>Reproduces problem - if it needs a new test, write it and
  86       put it in the regression tests.
  87       If it can't be reproduced, set to Resolved/CANT_FIND.<br>
  88       If it's a duplicate, set it to Resolved/DUPLICATE.
  89       Fix code, commit changes, set to Resolved.</td>
  90 <tr>
  91   <td>Submitter:</td>
  92   <td>Tests it again; set to Verified (pass) or Reopened (fail)</td>
  93 <tr>
  94   <td>Owner:</td>
  95   <td>After next release is done, re-test; sets to Closed or Reopened.</td>
  96 </table></center>
  97
  98 <p><hr>
  99 <H3>The Role of the Build Czar</H3>
 100 <P>
 101
 102 At all times, we'll have a build czar.  The role may be shared by
 103 multiple people.  The build czar is responsible for ensuring that the
 104 next kits are clean, <em>i.e.</em>, it builds and runs cleanly on all
 105 platforms.  The status of all ACE+TAO builds is tracked automatically
 106 <A HREF="http://www.dre.vanderbilt.edu/scoreboard"</A>online</A>.<p>
 107
 108 A comprehensive summary of the build czar's role is available <A HREF="bczar/bczar.html">here</A>.
 109 This role is briefly summarized below:<p>
 110 <ul>
 111   <li>Remind people to check build logs.  Developers are still
 112     responsible for verifying that their changes are clean.
 113   <li>Trigger other developers to fix problems caused by compilation errors.  All
 114       problems should be fixed by the developers who caused them.  The
 115       build czar should help track down the guilty parties.
 116   <li>Freeze the source repository when it's decided to no more
 117     non-critical changes will be accepted for the next kits.
 118     The build czar has the final say over when the freeze is
 119     implemented.  The tendency to implement a freeze sooner than
 120     later is intentional, desirable, beneficial, and the "Right Thing"[TM]
 121     to do.
 122   <li>Verifies that the final round of builds/tests are clean.
 123   <li>Creates the kits.
 124   <li>Unfreezes the source repository.
 125   <li>Sends email to appropriate news groups announcing the new kits.
 126   <li>Passes the mantle on to the next build czar.<p>
 127 </ul>
 128
 129 If another developer interferes with the build czar's duties, the
 130 build czar has the unilateral authority to pass the mantle to the
 131 violator.  This is also intentional, desirable, beneficial, and the
 132 Right Thing[TM] to do.<p>
 133
 134 <p><hr>
 135 <H3>The ACE+TAO Release Process</H3>
 136 <P>
 137
 138 Minor releases of ACE+TAO occur periodically, typically twice a
 139 year. Minor releases have two-digit numbers, <EM>e.g.,</EM> 5.3.
 140 Major releases are released infrequently, typically once a year.
 141 Major releases are 1-digit numbers, <EM>e.g.,</EM>5, that include
 142 substantially new functionality.  Both major and minor releases are
 143 carefully tested on all platforms the ACE+TAO run on.  In particular,
 144 we do not put out major or minor releases of ACE+TAO until all the
 145 compilations and regression tests work successful on all the platform
 146 we support. <P>
 147
 148 Between major/minor releases, we release micro releases periodically,
 149 <EM>e.g.,</EM> 3-4 times per year, so that ACE+TAO users can
 150 download and test our latest work in progress.  ACE+TAO micro
 151 release kits have three-digit numbers, <EM>e.g.,</EM> 5.3.1.  Micro
 152 releases often contain important fixes that aren't in the major/minor
 153 releases and will compile cleanly and pass most tests on most
 154 platforms.  They are not, however, necessarily concerned with ensuring
 155 API compatibilities between micro releases, <EM>e.g.,</EM> new
 156 features may be changed or removed between the micro releases. <P>
 157
 158 <p><hr>
 159 <H3>Contributions from the Open-Source Community</H3>
 160 <P>
 161
 162 Over the years, ACE+TAO have benefited significantly from
 163 contributions by <A
 164 HREF="http://www.dre.vanderbilt.edu/~schmidt/ACE-members.html">thousands</A>
 165 of developers in the open-source community.  To avoid fragmentation of
 166 the code base, by submitting comments, suggestions, code, code
 167 snippets, techniques (including that of usage) and algorithms
 168 (collectively ``Submissions''), submitters acknowledge that they have
 169 the right to do so, that any such Submissions are given freely and
 170 unreservedly, and that they waive any claims to copyright or
 171 ownership.  In addition, submitters acknowledge that any such
 172 Submission might become part of the copyright maintained on the
 173 overall body of code that comprises the open-source DOC Group
 174 software.  By making a Submission, submitter agree to these terms.
 175 Moreover, submitters acknowledge that the incorporation or
 176 modification of such Submissions is entirely at the discretion of the
 177 moderators of the open-source DOC software projects or their
 178 designees.
 179
 180 <hr><p>
 181   <font size=-1>
 182     Last modified
 183 <!--#echo var="LAST_MODIFIED" -->.<p>
 184   </font><hr>
 185
 186 Back to <A HREF="index.html">ACE Documentation Home</A>.
 187
 188 </body>
 189 </html>