
		    So, You Want to Help Hack arch


* legal issues

  These are momentarilly up in the air.  For minor contributions,
  there is no issue -- I'll just accept your changes and try to 
  remember to give you credit in the "=THANKS" file.

  For major contributions, there is an issue.  I plan to ask the FSF
  to accept a copyright assignment for arch.  If they agree, then I'll
  ask you to assign rights to your changes to the FSF.  But this isn't
  done yet -- currently I am the sole copyright holder for arch.  Keep
  that in mind if you plan to contribute major changes.  If you have 
  questions about this issue and want to know the latest status, write
  to me.



* 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.
  
# tag: Tom Lord Wed Jan 30 20:25:27 2002 (=FAQS/contributing)
#
