├── CONTRIBUTING.md ├── LICENSE ├── README ├── ftdetect └── puppet.vim ├── ftplugin └── puppet.vim ├── indent └── puppet.vim └── syntax └── puppet.vim /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | Checklist (and a short version for the impatient) 2 | ================================================= 3 | 4 | * Commits: 5 | 6 | - Make commits of logical units. 7 | 8 | - Check for unnecessary whitespace with "git diff --check" before 9 | committing. 10 | 11 | - Commit using Unix line endings (check the settings around "crlf" in 12 | git-config(1)). 13 | 14 | - Do not check in commented out code or unneeded files. 15 | 16 | - The first line of the commit message should be a short 17 | description (50 characters is the soft limit, excluding ticket 18 | number(s)), and should skip the full stop. 19 | 20 | - If there is an associated Redmine ticket then the first line 21 | should include the ticket number in the form "(#XXXX) Rest of 22 | message". 23 | 24 | - The body should provide a meaningful commit message, which: 25 | 26 | - uses the imperative, present tense: "change", not "changed" or 27 | "changes". 28 | 29 | - includes motivation for the change, and contrasts its 30 | implementation with the previous behavior. 31 | 32 | - Make sure that you have tests for the bug you are fixing, or 33 | feature you are adding. 34 | 35 | - Make sure the test suite passes after your commit (rake spec unit). 36 | 37 | * Submission: 38 | 39 | * Pre-requisites: 40 | 41 | - Make sure you have a [Redmine account](http://projects.puppetlabs.com) 42 | 43 | - Sign the [Contributor License Agreement](https://projects.puppetlabs.com/contributor_licenses/sign) 44 | 45 | * Preferred method: 46 | 47 | - Fork the repository on GitHub. 48 | 49 | - Push your changes to a topic branch in your fork of the 50 | repository. 51 | 52 | - Submit a pull request to the repository in the puppetlabs 53 | organization. 54 | 55 | * Alternate methods: 56 | 57 | - Mail patches to puppet-dev mailing list using `rake mail_patches`, 58 | or `git-format-patch(1)` & `git-send-email(1)`. 59 | 60 | - Attach patches to Redmine ticket. 61 | 62 | The long version 63 | ================ 64 | 65 | 0. Base your work on the latest `master`. 66 | 67 | 1. Make separate commits for logically separate changes. 68 | 69 | Please break your commits down into logically consistent units 70 | which include new or changed tests relevent to the rest of the 71 | change. The goal of doing this is to make the diff easier to 72 | read for whoever is reviewing your code. In general, the easier 73 | your diff is to read, the more likely someone will be happy to 74 | review it and get it into the code base. 75 | 76 | If you're going to refactor a piece of code, please do so as a 77 | separate commit from your feature or bug fix changes. 78 | 79 | We also really appreciate changes that include tests to make 80 | sure the bug isn't re-introduced, and that the feature isn't 81 | accidentally broken. 82 | 83 | Describe the technical detail of the change(s). If your 84 | description starts to get too long, that's a good sign that you 85 | probably need to split up your commit into more finely grained 86 | pieces. 87 | 88 | Commits which plainly describe the the things which help 89 | reviewers check the patch and future developers understand the 90 | code are much more likely to be merged in with a minimum of 91 | bike-shedding or requested changes. Ideally, the commit message 92 | would include information, and be in a form suitable for 93 | inclusion in the release notes for the version of Puppet that 94 | includes them. 95 | 96 | Please also check that you are not introducing any trailing 97 | whitespaces or other "whitespace errors". You can do this by 98 | running "git diff --check" on your changes before you commit. 99 | 100 | 2. Sign the Contributor License Agreement 101 | 102 | Before we can accept your changes, we do need a signed Puppet 103 | Labs Contributor License Agreement (CLA). 104 | 105 | You can access the CLA via the 106 | [Contributor License Agreement link](https://projects.puppetlabs.com/contributor_licenses/sign) 107 | in the top menu bar of our Redmine instance. Once you've signed 108 | the CLA, a badge will show up next to your name on the 109 | [Puppet Project Overview Page](http://projects.puppetlabs.com/projects/puppet?jump=welcome), 110 | and your name will be listed under "Contributor License Signers" 111 | section. 112 | 113 | If you have any questions about the CLA, please feel free to 114 | contact Puppet Labs via email at cla-submissions@puppetlabs.com. 115 | 116 | 3. Sending your patches 117 | 118 | We accept multiple ways of submitting your changes for 119 | inclusion. They are listed below in order of preference. 120 | 121 | Please keep in mind that any method that involves sending email 122 | to the mailing list directly requires you to be subscribed to 123 | the mailing list, and that your first post to the list will be 124 | held in a moderation queue. 125 | 126 | * GitHub Pull Requests 127 | 128 | To submit your changes via a GitHub pull request, we _highly_ 129 | recommend that you have them on a topic branch, instead of 130 | directly on "master" or one of the release, or RC branches. 131 | It makes things much easier to keep track of, especially if 132 | you decide to work on another thing before your first change 133 | is merged in. 134 | 135 | GitHub has some pretty good 136 | [general documentation](http://help.github.com/) on using 137 | their site. They also have documentation on 138 | [creating pull requests](http://help.github.com/send-pull-requests/). 139 | 140 | In general, after pushing your topic branch up to your 141 | repository on GitHub, you'll switch to the branch in the 142 | GitHub UI and click "Pull Request" towards the top of the page 143 | in order to open a pull request. 144 | 145 | You'll want to make sure that you have the appropriate 146 | destination branch in the repository under the puppetlabs 147 | organization. This should be the same branch that you based 148 | your changes off of. 149 | 150 | * Other pull requests 151 | 152 | If you already have a publicly accessible version of the 153 | repository hosted elsewhere, and don't wish to or cannot use 154 | GitHub, you can submit your change by requesting that we pull 155 | the changes from your repository by sending an email to the 156 | puppet-dev Google Groups mailing list. 157 | 158 | `git-request-pull(1)` provides a handy way to generate the text 159 | for the email requesting that we pull your changes (and does 160 | some helpful sanity checks in the process). 161 | 162 | * Mailing patches to the mailing list 163 | 164 | If neither of the previous methods works for you, then you can 165 | also mail the patches inline to the puppet-dev Google Group 166 | using either `rake mail_patches`, or by using 167 | `git-format-patch(1)`, and `git-send-email(1)` directly. 168 | 169 | `rake mail_patches` handles setting the appropriate flags to 170 | `git-format-patch(1)` and `git-send-email(1)` for you, but 171 | doesn't allow adding any commentary between the '---', and the 172 | diffstat in the resulting email. It also requires that you 173 | have created your topic branch in the form 174 | `//`. 175 | 176 | If you decide to use `git-format-patch(1)` and 177 | `git-send-email(1)` directly, please be sure to use the 178 | following flags for `git-format-patch(1)`: -C -M -s -n 179 | --subject-prefix='PATCH/puppet' 180 | 181 | * Attaching patches to Redmine 182 | 183 | As a method of last resort you can also directly attach the 184 | output of `git-format-patch(1)`, or `git-diff(1)` to a Redmine 185 | ticket. 186 | 187 | If you are generating the diff outside of Git, please be sure 188 | to generate a unified diff. 189 | 190 | 4. Update the related Redmine ticket. 191 | 192 | If there's a Redmine ticket associated with the change you 193 | submitted, then you should update the ticket to include the 194 | location of your branch, and change the status to "In Topic 195 | Branch Pending Merge", along with any other commentary you may 196 | wish to make. 197 | 198 | How to track the status of your change after it's been submitted 199 | ================================================================ 200 | 201 | Shortly after opening a pull request on GitHub, there should be an 202 | automatic message sent to the puppet-dev Google Groups mailing list 203 | notifying people of this. This notification is used to let the Puppet 204 | development community know about your requested change to give them a 205 | chance to review, test, and comment on the change(s). 206 | 207 | If you submitted your change via manually sending a pull request or 208 | mailing the patches, then we keep track of these using 209 | [patchwork](https://patchwork.puppetlabs.com). When code is merged 210 | into the project it is automatically removed from patchwork, and the 211 | Redmine ticket is manually updated with the commit SHA1. In addition, 212 | the ticket status must be updated by the person who merges the topic 213 | branch to a status of "Merged - Pending Release" 214 | 215 | We do our best to comment on or merge submitted changes within a week. 216 | However, if there hasn't been any commentary on the pull request or 217 | mailed patches, and it hasn't been merged in after a week, then feel 218 | free to ask for an update by replying on the mailing list to the 219 | automatic notification or mailed patches. It probably wasn't 220 | intentional, and probably just slipped through the cracks. 221 | 222 | Additional Resources 223 | ==================== 224 | 225 | * [Getting additional help](http://projects.puppetlabs.com/projects/puppet/wiki/Getting_Help) 226 | 227 | * [Writing tests](http://projects.puppetlabs.com/projects/puppet/wiki/Development_Writing_Tests) 228 | 229 | * [Bug tracker (Redmine)](http://projects.puppetlabs.com) 230 | 231 | * [Patchwork](https://patchwork.puppetlabs.com) 232 | 233 | * [Contributor License Agreement](https://projects.puppetlabs.com/contributor_licenses/sign) 234 | 235 | * [General GitHub documentation](http://help.github.com/) 236 | 237 | * [GitHub pull request documentation](http://help.github.com/send-pull-requests/) 238 | 239 | If you have commit access to the repository 240 | =========================================== 241 | 242 | Even if you have commit access to the repository, you'll still need to 243 | go through the process above, and have someone else review and merge 244 | in your changes. The rule is that all changes must be reviewed by a 245 | developer on the project (that didn't write the code) to ensure that 246 | all changes go through a code review process. 247 | 248 | Having someone other than the author of the topic branch recorded as 249 | performing the merge is the record that they performed the code 250 | review. 251 | 252 | * Merging topic branches 253 | 254 | When merging code from a topic branch into the integration branch 255 | (Ex: master), there should always be a merge commit. You can 256 | accomplish this by always providing the `--no-ff` flag to 257 | `git merge`. 258 | 259 | git merge --no-ff --log tickets/master/1234-fix-something-broken 260 | 261 | The reason for always forcing this merge commit is that it 262 | provides a consistent way to look up what changes & commits were 263 | in a topic branch, whether that topic branch had one, or 500 264 | commits. For example, if the merge commit had an abbreviated 265 | SHA-1 of `coffeebad`, then you could use the following `git log` 266 | invocation to show you which commits it brought in: 267 | 268 | git log coffeebad^1..coffeebad^2 269 | 270 | The following would show you which changes were made on the topic 271 | branch: 272 | 273 | git diff coffeebad^1...coffeebad^2 274 | 275 | Because we _always_ merge the topic branch into the integration 276 | branch the first parent (`^1`) of a merge commit will be the most 277 | recent commit on the integration branch from just before we merged 278 | in the topic, and the second parent (`^2`) will always be the most 279 | recent commit that was made in the topic branch. This also serves 280 | as the record of who performed the code review, as mentioned 281 | above. 282 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Puppet - Automating Configuration Management. 2 | 3 | Copyright (C) 2011 Puppet Labs Inc 4 | 5 | Puppet Labs can be contacted at: info@puppetlabs.com 6 | 7 | Licensed under the Apache License, Version 2.0 (the "License"); 8 | you may not use this file except in compliance with the License. 9 | You may obtain a copy of the License at 10 | 11 | http://www.apache.org/licenses/LICENSE-2.0 12 | 13 | Unless required by applicable law or agreed to in writing, software 14 | distributed under the License is distributed on an "AS IS" BASIS, 15 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16 | See the License for the specific language governing permissions and 17 | limitations under the License. 18 | -------------------------------------------------------------------------------- /README: -------------------------------------------------------------------------------- 1 | THIS PLUGIN IS NO LONGER MAINTAINED! 2 | 3 | PLEASE USE @rodjek's PLUGIN FOUND AT https://github.com/rodjek/vim-puppet 4 | 5 | To install these files, copy them into ~/.vim, or the relevant 6 | system-wide location. To use the ftplugin and indenting, you may need 7 | to enable them with "filetype plugin indent on" in your vimrc. 8 | -------------------------------------------------------------------------------- /ftdetect/puppet.vim: -------------------------------------------------------------------------------- 1 | " detect puppet filetype 2 | au BufRead,BufNewFile *.pp set filetype=puppet 3 | -------------------------------------------------------------------------------- /ftplugin/puppet.vim: -------------------------------------------------------------------------------- 1 | " Vim filetype plugin 2 | " Language: Puppet 3 | " Maintainer: Todd Zullinger 4 | " Last Change: 2009 Aug 19 5 | " vim: set sw=4 sts=4: 6 | 7 | if exists("b:did_ftplugin") 8 | finish 9 | endif 10 | let b:did_ftplugin = 1 11 | 12 | if !exists("no_plugin_maps") && !exists("no_puppet_maps") 13 | if !hasmapto("AlignRange") 14 | map = AlignRange 15 | endif 16 | endif 17 | 18 | noremap