doc/policies.txt

   1 Policy Guide
   2 ============
   3
   4 Following are some guidelines we want to follow:
   5
   6 - We will try to make regular releases. Each release will be in the
   7 tags directory and should not be changed, unless a bug is critical and
   8 makes the release unusable!
   9
  10 - New features and bug fixes get only added to trunk. The commit
  11 message of new features should be marked by a specific keyword (e.g.
  12 "feature: "), the one for bug fixes with "bugfix:". This way we can
  13 make an easy changelog for each release by parsing the log messages.
  14
  15 - If we have a couple of new features and bug fixes in the trunk, then we
  16 are ready for a new release :)
  17
  18 - If you make major changes on the system, branch it. This should be
  19 used for anything which will take longer than, let's say a week. Once
  20 the development is done, merge your branch back into trunk and rename
  21 the branch (i.e. use `svn mv`) to "xy-FINISHED" to prevent further commits.
  22
  23 - Each developer can have its own branch, if he/she so desires. This can
  24 help his/her research by preventing other people changing files he/she is
  25 not aware of but not loosing the capabilities of logging his/her changes on
  26 the code.
  27
  28 - We should start using the bug tracking system of Savane to track
  29 bugs
  30 (link:https://projects.nesl.ucla.edu/bugs/?group=sos-2x[https://projects.nesl.ucla.edu/bugs/?group=sos-2x]).
  31 The same counts for bigger tasks we want to assign to someone
  32 (link:https://projects.nesl.ucla.edu/task/?group=sos-2x[https://projects.nesl.ucla.edu/task/?group=sos-2x])
  33