code change policies

[Matthew Hayes <ma...@gmail.com>]

I'd like to open up a discussion on how we should handle code changes.  I
like the review, then commit model, which appears to be what Crunch follows
as well (according to its bylaws):

Action Description Approval Binding Votes Days   Code Change A change made
to a codebase of the project and committed by a committer. This includes
source code, documentation, website content, etc. Lazy approval (not
counting the vote of the contributor), moving to lazy majority if a -1 is
received Active committers 1

I'd like to know what people's thoughts are on this commit policy.

Also I'd like to discuss how the commit should actually be applied and by
whom.  Here are some thoughts I had:

   1. When a patch is applied, it should be applied as a single commit.
   So, commit history should be squashed.  This squashing can be done by
   either the person submitting the patch or by the person committing the
   patch.
   2. Patches should be committed by someone who is not the submitter.
   3. If the person committing the patch must squash commits, then they
   should use --author to retain the original author.
   4. The person committing the patch should add --signoff to indicate they
   signed off on it in the commit message.

What do people think about this?  Please share any useful learnings from
other projects :)

-Matt