## mark a section (Learn more)

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

This paste will be private.