Changes between Version 4 and Version 5 of SourceControlPolicy

Timestamp:

Nov 12, 2014 1:33:18 PM (10 years ago)

Author:

sklower

Comment:

--

SourceControlPolicy

@@ -8 +8 @@
 
  Master::
-  The most recent official stable DETER sources.  ''(A link to the most recent release branch??? What is the semantics of this branch now??? -- tvf)''
+  The most recent official stable DETER sources.  ''(A link to the most recent release branch??? What is the semantics of this branch now??? -- tvf)'' \\ ''( I think lower-case *master* is a git artifact -- kls)''
+
+======================== \\ ''Keith proposes additionally''
+
+ Production::
+  This represents what is actually running on boss.isi.deterlab.net
+
+''/Keith''\\
+========================
 
  Development::
@@ -55 +63 @@
                4. declare victory
 
-        '''PRIVAT'''[[BR]]
+        '''PRIVAT'''[[BR]]  ''(Are you objecting to Ted's term **Nonce**?  And did you possibly mean **Private** instead of **Privat** -- kls)''
 
         Developers may also create nonce branches to carry out development tasks, performance evaluations, or other common tasks. 
@@ -67 +75 @@
         Committing changes from NON-ISI owned branches back to the Dev Trunk can only be done ISI team, upon request ,after detailed review and after OPS group approval.[[BR]]
 
-        Procedure to prepare these branches for checkin should be
+        Procedure to prepare these branches for check-in should be
                1. pull all changes from DEV branch
                2. retest and fix 
-               3. Do the documentation, then create request to checkin into dev 
+               3. Do the documentation, then create request to check-in into dev 
                4. If ISI branch push the changes to dev, if not then OPS group will handle ...
 
@@ -78 +86 @@
         As a bare minimum fixes would need to be tracked against release versions along with what and how they were tested.[[BR]]
 
-        Again, we should only support few branches and obsolete older ones.
+        Again, we should only support few branches and obsolete older ones.  ''(Does Goran intend *releases* instead of *branches*?  Should we be discouraging Nonce branches?  -- kls)''
 
         '''Definition of "accepted" change or satisfactory testing'''''''''[[BR]]
@@ -95 +103 @@
         
 ====== END ================
+
+==========================
+ ''Keith's rationale''
+
+There MUST be a repository that corresponds closely to what we are
+running in production.   Bitter experience from our past shows
+that when we run things for more than a short while without
+entering them into a repository, changes are lost, or files
+not included.
+
+The amount of time something should be tested in production before
+entering into that repository depends on the nature of the change
+or addition.
+
+Whether or not a new feature or change should even be run or tested
+in production also depends on the nature of the change; how big
+it is, how thoroughly it has been tested outside of production.
+
+I think it is terribly unwise to transcribe into quasi-force-of-law
+fixed terms, and consequently the phrase \\
+"run in the full ISI DETERLab environment for at least 1 week" \\ and \\
+"This testing regimen implies that the code in development may
+lag the code running in DETERLab itself."
+makes my blood run cold.
+
+The ops team meets once a week; we can review at each meeting what we think should be pushed from
+**Production** to **Development**.  The ops team consists of experienced professionals; if a member
+of the team discovers a highly critical fix needs to be issued to both **Development** and possible
+release branches, he or she should have the freedom to do so providing that notification is made to
+the other members of the team.
+
+
+''/Keith's rationale''\\
+========================
+
 TO BE REVIEWED: