Titanium Development Practices and PRCS Usage
---------------------------------------------
Development practices that Titanium developers are expected to follow:

* Titanium uses PRCS for revision control. All developers are responsible for
  familiarizing themselves with the operation of this software by reading 
  the documentation here: http://prcs.sourceforge.net/

* All developers doing commits must be on the titanium-devel@cs email list,
  which receives checkin messages.

* You must include an explanatory prcs log message for any change. It should describe
  the high-level of what you did, and why you did it (e.g. to solve a particular
  bug, etc). Generally larger changes deserve more detailed log messages -
  remember the idea is to keep other developers apprised of changes you've made
  that could affect their work somehow. Checkin messages should reference any
  particular bug PR's that they address.

* After committing a change, you must send an email to titanium-devel@cs with a 
  subject of "tc X.XXX" (for XXX the new version number), and a body containing
  the checkin message and the list of changed files.

* Developers are recommended setup their environment as follows:
   PRCS_REPOSITORY=/project/cs/titanium/a/PRCS
   PRCS_LOGQUERY=1  
  The second one reminds you to include a checkin message.
  You should always run "prcs checkin" with the "-l" option, so you see the list
  of changed files (which you'll need for inclusion in the checkin email). 
  It's also a good way to ensure you're not committing changes to files you 
  didn't intend to commit, or accidentally clobberring changes made by other 
  developers due to copying files around behind prcs's back.

* All Titanium developers should be using the version of prcs in the project directories:
    Linux:   /project/cs/titanium/srs/i686-pc-linux-gnu/bin/prcs
    Solaris: /project/cs/titanium/srs/sparc-sun-solaris2.8/bin/prcs
  These versions are kept in sync with the repo version, have compiled-in
  defaults to use the Titanium PRCS repo, and some default option settings which
  help enforce our source management policies. Do NOT use some random other
  version of prcs to operate on our repo - that could potentially break the repo.
  Developers are highly encouraged to place the above paths early in their PATH,
  to avoid getting other versions of prcs that may be sitting around in
  /usr/sww/bin, etc.

* You should only commit working code - do NOT check in untested or flagrantly
  broken code that could affect system stability. The idea is to ensure the main
  trunk of the repository is mostly-working at all times, so try to make sure
  your commits leave the repository in at least as working a state as you found
  it. We understand that it may not be practical to test a given change on all
  platforms, but you should at least test it throughly on your development
  platform, and any other platforms that you have reason to believe may be
  affected (this is especially true for configure scripts and Makefiles). If you
  wish to checkin intermediate or untested versions of your code, please do so
  on a private branch.

* Developers are REQUIRED to verify that the entire Titanium regression testsuite 
  runs correctly on at least one system BEFORE committing any non-trivial change.
  To run the test suites, run these commands:
   gmake -C ex/ check           - frontend tests
   gmake -C ex/comparable       - Java functionality equivalence tests
   gmake -C ex/TestSuite test   - General runtime tests, sequential and parallel

* Whenever you add ANY files to the PRCS repository, you MUST make sure they also
  get added to the Makefile.am file for the enclosing directory (if there is one)
  otherwise your added file won't be included in the public release.
  Just because your program compiles, doesn't mean you got this right - 
  header files and documentation are very easy to forget and cause endless 
  headaches at release time when files are missing from the distribution.

Whenever you wish to audit changes, one can use "prcs info -l" or the online
email archive here: http://titanium.cs.berkeley.edu/private_html/mailing-lists/
to view the change log. At release time, we collect a summary of the high-level
user-visible changes into a release announcement which goes on the web page and
gets emailed to the group. Prcs also has extensive features for comparing
versions and auditing changes - see "prcs diff -h" and "prcs changes -h".

Titanium Release Procedure
--------------------------
 Titanium release procedures are documented in the srs-release.tex document in the 
 titanium-doc repository.