/[MITgcm]/mitgcm.org/cvspolicy.html
ViewVC logotype

Annotation of /mitgcm.org/cvspolicy.html

Parent Directory Parent Directory | Revision Log Revision Log | View Revision Graph Revision Graph


Revision 1.10 - (hide annotations) (download) (as text)
Sat Feb 17 17:08:40 2001 UTC (23 years, 1 month ago) by jmc
Branch: MAIN
Changes since 1.9: +4 -4 lines
File MIME type: text/html
*** empty log message ***

1 adcroft 1.7 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
2 cnh 1.2 <html>
3     <head>
4 adcroft 1.7 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
5 jmc 1.9 <meta name="GENERATOR" content="Mozilla/4.76 [en] (X11; U; Linux 2.4.1 i686) [Netscape]">
6 adcroft 1.8 <meta name="Author" content="Chris Hill">
7     <title>MITgcm CVS policy</title>
8 cnh 1.2 </head>
9 adcroft 1.8 <body text="#000000" bgcolor="#FF99FF" link="#0000EF" vlink="#51188E" alink="#FF0000">
10    
11     <center>
12     <h1>
13 jmc 1.9 MITgcm CVS policy</h1></center>
14 cnh 1.1
15 adcroft 1.7 <h2>
16     Introduction</h2>
17     This note describes policies that apply to the MITGCM CVS repository.
18     <h2>
19     Why have a policy?</h2>
20     CVS itself is a liberal free-for-all product that can be used in a variety
21     of ways. It is designed to provide a system for storing arbitrary files
22     in a way that allows the change history of the individual files to be tracked.
23     If CVS is used without any other policy the result can be a collection
24 jmc 1.9 of files each of which has complex, multiply branched set of inter-related
25 adcroft 1.7 versions. This sort of CVS repository can be come like a library where
26     books are simply stored in a huge heap. Although nothing is actually lost,
27     the task of finding a coherent collection of material soon becomes impossible.
28 jmc 1.9 <p>The policies we employ address tree areas
29 adcroft 1.7 <ol>
30     <li>
31     Maintaining an orderly and easily identifiable, coherent set of evolving
32     "products".</li>
33    
34     <li>
35     Allowing concurrent, on-going development of product components.</li>
36 jmc 1.9
37     <li>
38     Making the integration&nbsp; of achieved developments easy, rapid, organized
39     and clear.</li>
40 adcroft 1.7 </ol>
41    
42     <h2>
43     Development trees and checkpoint trees</h2>
44     A directory within the MITGCM repository resides under either the development
45     branch or the checkpoint branch. Files within each branch follow different
46     policies.
47     <h2>
48     Development tree policies</h2>
49     Development trees are intended to be flexible areas where arbitrary files
50     can be stored with multiple versions, many branches supporting multiple
51     ongoing streams of development. Development trees have no policies in place
52     to control complexity. Development trees might be associated with a particular
53     person, a certain project or a particular special piece of work. These
54     trees are intended to be useful areas for storing current work and for
55     archiving partially finished work so that it doesn't get mislaid and so
56     that some record of the development history can be easily maintained. The
57     only policy that applies to development trees is that this style of tree
58     is not intended to be used for providing a "checkpoint" distribution. Tagged
59     configurations of tools built from this style of tree can be distributed,
60 jmc 1.9 but because these trees do not have any policies regarding testing of functionality,
61 adcroft 1.7 platform coverage or documentation these trees are not allowed to form
62 jmc 1.9 the basis of "checkpoint" distributions or formal "releases". Other policies
63 adcroft 1.7 can be defined by individuals users of these trees but there are no further
64 jmc 1.9 global policies. The MITGCM repository development_tree/ sub-directory
65     is reserved for holding development trees. Development trees also serve
66     as experimental areas for exploring new code management policies.
67 adcroft 1.7 <h2>
68     Checkpoint tree policies</h2>
69     Checkpoint trees are intended to provide structured storage areas for holding
70     code that is intended for open distribution and is to be readily downloaded.
71     There are policies governing the operation of these trees which are designed
72     to ensure that distributed codes are early identified and meet certain
73     levels of quality.
74     <ol>
75     <li>
76     Check-out</li>
77    
78     <br>Just do it! Two mechanisms are available. cvsanon for read only access
79     and regular cvs co .... for read/write access.
80     <li>
81     Check-in</li>
82    
83     <br>The code check in procedure for a "checkpoint" tree is as follows
84     <ol>
85     <li>
86     Check out the latest main branch revision.</li>
87    
88     <li>
89     Merge your changes into that revision.</li>
90    
91     <li>
92     Build and validate new code.</li>
93    
94     <li>
95     Check that there have been no further changes to the repository. Repeat
96     from 2.1 if repository has changed.</li>
97    
98     <li>
99     Get clearance from other developers to check in your changes.</li>
100    
101     <li>
102     Check in your changed main branch.</li>
103    
104     <li>
105     Build and validate the new changes.</li>
106    
107     <li>
108     Tag code as "checkpointNN". Add records to docs/tag-index.</li>
109    
110     <li>
111     Build and validate test cases (see testing).</li>
112    
113     <li>
114     Create and install checkpointNN.tar.gz</li>
115     </ol>
116    
117     <li>
118     Testing</li>
119    
120     <br>Things in a checkpoint tree require a test case that can be used to
121     validate the component.
122     <li>
123     Checkpoint tagging</li>
124    
125 jmc 1.9 <br>No code should be left in limbo (un-tagged) for extended periods. On
126     the other hand it's unnecessary to create a checkpoint tag for every little
127     change. Checkpoint tags should be made after a particularly significant
128     code modification or otherwise on a regular basis, say bi-weekly. Very
129     often we set a list of goals to be reached by the next checkpoint which
130     sometimes takes more than two weeks to achieve. Obviously, in this case
131     a bi-weekly checkpoint would not be useful.
132 adcroft 1.7 <li>
133     Release tagging</li>
134    
135     <br>Releases are only based on checkpoint tree code. Maintenance fixes
136     to releases are also maintained within the checkpoint tree. Files within
137     a release must have accompanying documentation. The form of this documentation
138     depends on the file type.
139     <li>
140     Branches</li>
141    
142 jmc 1.9 <br>Branches are a useful tool for making changes prior to checkpoints
143     without breaking other working versions but it must be understood that
144     branches are short-lived and that releases and checkpoints not be made
145     from a branch. Branches are especially useful for adding totally
146     <br>new features. bug-fixes to checkpoints are introduced by moving checkpoint
147     levels forward. The only historical code maintenance that s employed is
148     for fixes and patches to formal releases - not checkpoints.</ol>
149    
150 jmc 1.10 <h2>
151     Someone checked-in broken code so not my code doesn't work?</h2>
152 jmc 1.9 You have several options:
153     <ol>
154     <li>
155     Politely email everyone at support@mitgcm.org asking what&nbsp; has happened
156     and that it be fixed?</li>
157    
158     <li>
159     Figure out why the new code is broken, fix it, check it in and proudly
160     send a message to support@mitgcm.org to show how constructive you are.</li>
161    
162     <li>
163     Complain that the quality of work is too low and then do nothing to fix
164     the code.<br>
165     <BR></li>
166    
167     <br>We advise you to only use the third option if you are confident that
168     your own contributions to the code are bug-free, well written, documented
169     and fool proof.&nbsp; :)</ol>
170 adcroft 1.7
171     <h2>
172     These policies are causing me a big problem, what can I do?</h2>
173     The policies are not enforced by any mechanism other than mutual agreement!
174     If you think the policies are not appropriate then let us know and we can
175     discuss changing them. However, if you simply ignore the policies regarding
176     the checkpoint_release trees then your code may be removed and/or your
177     access revoked.
178     <h2>
179     What about bitkeeper</h2>
180     We are looking at bitkeeper (www.bitkeeper.com). It looks cool, but policies
181     are still important. Any experience, suggestions let us know. Watch this
182     space!
183     <p>Questions, comments e-mail: code.czars@mitgcm.org
184     <br>
185     <hr WIDTH="100%">
186     <table CELLSPACING=0 CELLPADDING=0 WIDTH="100%" NOSAVE >
187     <tr NOSAVE>
188 jmc 1.10 <td><font size=-1>Last modified on $Date: 2001/02/17 16:54:29 $</font></td>
189 adcroft 1.7
190     <td>
191 adcroft 1.8 <div align=right><font size=-1>CVS: $Source: /u/gcmpack/mitgcm.org/../cvspolicy.html,v
192 jmc 1.10 $Revision: 1.9 $</font></div>
193 adcroft 1.7 </td>
194     </tr>
195     </table>
196 cnh 1.1
197 cnh 1.2 </body>
198     </html>

  ViewVC Help
Powered by ViewVC 1.1.22