#
#   "SystemImager"
#
#   Copyright (C) 1999-2004 Brian Elliott Finley
#
#   $Id: DEVELOPER_GUIDELINES,v 1.10 2004/07/01 16:40:29 brianfinley Exp $
#

--------------------------------------------------------------------------------
CODING
--------------------------------------------------------------------------------
o   For perl code, read "man perlstyle", it's not very long, but is very 
    insightful.  I just read it recently myself, but it turns out that it
    describes the style I prefer almost to a tee (I wonder where that 
    saying came from).  Except for this one bit:

        [Semicolon omitted in "short" one-line BLOCK.]
    
    You can ignore that bit.  -Brian

o   Try to mimick the style of the code that you are working in, unless
    it's perl and it conflicts with the perlstyle man page.  Not all of 
    the existing perl code was written accordingly.  This will 
    significantly improve your chances of it being accepted.

o   Include a usage statement with every function/subroutine, no matter how
    simple and self-explanatory that function is.  Example:

        # Usage:
        # my $partition_tool = which_partition_tool();
        sub which_partition_tool {
            [... code here ...]
        }

o   When you close a bug or feature request, add an appropriate line to the 
    CHANGE.LOG that includes the bug or feature number and who you are.

o   Documentation:  Developers may make changes to the documentation source, but
    must contact Denise Walters for approval prior to making any structural 
    changes.  Denise may be contacted at: <denise.walters@hp.com>

o   Always give people credit in the CREDITS file.

o   Have fun!


--------------------------------------------------------------------------------
CVS
--------------------------------------------------------------------------------
o   The current development branch is always tagged "HEAD".  It is
    intended for feature additions and funky stuff.  Unless you're just
    fixing a bug, or updating the stable documentation, this is what you
    want.

o   The stable branch is only to be used for fixing bugs.

o   Only Brian Finley or Dann Frazier will modify CVS tags of any kind, 
    such as for versioning releases or creating development branches.

o   Always get approval from Brian Finley prior to adding any new
    directories to CVS.

o   Reference Material

    o   http://www.loria.fr/~molli/cvs/doc/cvs_toc.html
    o   http://cvsbook.red-bean.com/cvsbook.html
    o   http://www.cvshome.org/

o   Checkout Steps for Developers
    (You should be able to just copy and paste commands 2-5)

    1) Set your username:
        MY_CVS_USERNAME=your_cvs_user_name
    
    2) Tell cvs to operate over ssh:
        CVS_RSH=ssh
    
    3) Set BRANCH_OPTS to choose your branch.
    
        For the development branch (HEAD), cut and paste this:
            BRANCH="HEAD"; BRANCH_OPTS=""
    
        For the current stable branch, cut and paste this:
            BRANCH="v3_2_x"; BRANCH_OPTS="-r$BRANCH"
    
    4) Checkout the code:
        cvs -z3 -d:ext:$MY_CVS_USERNAME@cvs.sourceforge.net:/cvsroot/systemimager co $BRANCH_OPTS systemimager
    
    5) Rename the checked out source tree:
        mv systemimager systemimager.$BRANCH


--------------------------------------------------------------------------------
Versioning
--------------------------------------------------------------------------------
o   SystemImager uses kernel style versioning (X.Y.Z):

    X = major architectural change
    Y = feature release
        o   An odd number indicates a development release (leading up
            to an even numbered stable release).
        o   An even number indicates a stable release.
    Z = bug fix release
        o   (no new features)

o   Development releases may be made available unofficially.


