Okay - it's been a valuable discussion about work flow and now I'd like to summarise where I think we are, wrap some rules around that and release it as a draft process.  The below draws heavily on the Linux kernel development process for the rules and guidelines.

I see two types of development:

* Stable/master development which includes new features, bug fixes, tests and the like that are intended to be merged into the current 0.24.x stable branch or the master development branch.

* Non-core development and fixes in developer's private repositories, for example a custom type or function for your site, or a fix specific to you.  Some of these may end up in stable/master but if they do they need to follow that route or potentially be cherry-picked if the branch they are based on hasn't been re-based sufficiently recently.

1.  Puppet stable/master development

a.  First, what are the rules around what a patch/commit is (I'll use patch from now on).  A patch should be:

- It must be correct and tested.
- It must fix only one thing.
- It must clearly articulate what it fixes
- It must fix a real bug (one with a ticket) 
- It can not contain any "trivial" fixes in it (spelling changes, whitespace cleanup, etc.)  Log these as Trac tickets and the maintainer will action them.
- It should contain no MIME, no links, no compression, no attachments.  Just plain text.

b.  All patches require a Trac ticket.  All patches should reference the ticket number in their commit message (this might not be possible with all dev work but Luke generally tries to add at least a broad tickets to cover all new dev activities).

c.  All patches should be circulated to the -dev list using git-send-email.

Here are some brief instructions for doing this:

i. First, we set-up our environment:

$ git config --global user.name "Your Name"
$ git config --global user.email "yourname@yourdomain.com"
$ git config sendemail.signedoffcc false
$ git config sendemail.suppressfrom true

The first two commands configure your name and email.  The next two commands stop Git sending patches to your email address, essentially suppress a CC to you.

ii. Next, we select the commit or commits we want to send and format them as email.  

$ git format-patch -C -C -M -s -n 9decf35a304a444a855a9d16d6d945ca89beb6cc

When specifying revisions you can use any syntax supported by git-rev-parse (see the "Specifying Revisions" section of the git-rev-parse man page - http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html).

This will output one or more patch files, each prefixed with a patch number, named after the commit log entry and suffixed with .patch.  For example, 0001-Removing-extra-debugging.patch.

The git format-patch command line detects changed and renamed files (-C -C -M), adds the "Signed Off by" tag (-s), and keeps count of the patch files being formatted as part of the commit, i.e. [PATCH x/y] (-n).

iii. Once the patches have been created you can email them to the list using the git send-email command:

$ git send-email --no-chain-reply-to --no-signed-off-by-cc --suppress-from --no-thread --to puppet-dev@googlegroups.com 00*.patch

This will send all patches, not threaded, to the mailing list and cc in any other submitters