
                    So, You Want to Help Hack arch


* revision control issues

  Of course, if you are going to contribute to arch, the best way to 
  do it is to set up a publicly readable repository of your own,
  form branches from my `devo' branches, and make your changes there.

  Briefly, you'll want branches from my "devo" branches for changes
  that I agree to eventually merge into "devo", and then personal
  branches from those for your own development and for changes you
  want to propose but that I haven't accepted yet.
  
  Let's call your branches from "devo", "your-devo".  Initially,
  "your-devo" will just track my "devo".  When you propose some change
  that I accept, you'll merge that change into "your-devo", making
  sure it is up-to-date with my "devo".  When everything is
  hunky-dory, I'll merge "your-devo" into my "devo".  While we're
  working out details, you can keep merging my "devo" into "your-devo"
  to keep your changes up-to-date.
  
  It's a good idea to first work out your changes on some branch other
  than "your-devo", reserving "your-devo" for just those changes that
  we both agree eventually belong in my "devo".  That will save you
  the trouble of having to revert changes that I don't agree to
  accept.
  
  Finally, I'd appreciate it if, whenever practical, you commit groups
  of related changes all at once, and avoid mixing two different sets of
  changes in a single commit.  For example, a commit which is a
  "miscellaneous collection of Solaris portability fixes" is fine -- but
  a commit which is a mixture of "Solaris portability fixes" and "the
  cool new feature, XYZZY" is not so good -- XYZZY should have its own
  commit.
  
# Modifications 2002, 2003 Copyright (C) Walter Landry and the Regents of the
#                                        University of California
# tag: Tom Lord Wed Jan 30 20:25:27 2002 (=FAQS/contributing)
#
