[Mitgcm-support] Re: CVS Policy

[mitgcm-support at dev.mitgcm.org]

Where is this document kept? I remember talking about it last year
but I've never actually seen it before! Reading it, it looks like
it was written since Chris and I last argued about branches.

It's not under ./doc and if it's not under CVS already you should put
it in /u/gcmpack/mitgcm.org/  where the web pages are being
put under CVS for versioning.  A $Header$ would be useful too.


>   4. Checkpoint tagging
> 
>      No code should be left in limbo. Checking in code and then
>      leaving it in the repository untagged is bad. When you check
>      in code you are creating a new checkpoint. That means you don't
>      check in some code which you "know" works 100% and then go away 
>      for two weeks. When you start checking in code you make sure
>      you have time to do the process end-to-end as described in section
>      2.

  4. Checkpoint tagging

     No code should be left in limbo (un-tagged) for extended periods.
     On the otherhand it's unnecessary to create a checkpoint tag for
     every little change. checkpoint tags should be made after
     a particularly significant code modification or otherwise on a
     regular basis, say bi-weekly. Very often we set a list of goals
     to be reached by the next checkpoint which sometimes takes more
     than two weeks to acheive. Obviously, in this case a bi-weekly
     checkpoint would not be useful.

>   6. Branches
> 
>      Branches are to be used for bug-fixes and code patches to releases 
>      only. All other changes e.g. totally new features, bug-fixes to 
>      checkpoints are introduced by moving checkpoint levels forward. The 
>      only historical code maintenance that is employed is for fixes and 
>      patches to formal releases - not checkpoints.

  6. Branches

     Branches are a useful tool for making changes prior to checkpoints
     without breaking other working versions but it must be understood that
     branches are short-lived and that releases and checkpoints not be
     made from a branch. Branches are especially useful for adding totally
     new features. bug-fixes to checkpoints are introduced by moving
     checkpoint levels forward. The only historical code maintenance that
     is employed is for fixes and patches to formal releases - not
     checkpoints. Of course, this is a mute point if we never make a
     formal release.  :)


o Someone checked-in broken code so now my code doesn't work?
  You have several options:
    1) Politely email everyone at support at mitgcm.org asking what has
       happened and that it be fixed?
    2) Figure out why the new code is broken, fix it, check it in
       and proudly send a message to support at mitgcm.org to show how
       constructive you are.
    3) Complain that the quality of work is too low and then do nothing
       to fix the code.
  We advise you to only use the third option if you are confident that
  your own contributions to the code are bug-free, well written, documented
  and fool proof.  :)