puppet 2.7.18 → 2.7.19

data/CHANGELOG

@@ -1,3 +1,85 @@
+2.7.19
+===
+85f5543 Ruby 1.9.3 has a different error when `require` fails.
+b2d08a4 (#15291) Add Vendor tag to Puppet spec file
+7611753 Add packaging support for fedora 17
+b540aa0 (#15471) Fix setting mode of last_run_summary
+7c7cffe (#15471) Ensure non-root can read report summary
+a257105 Use Win32 API atomic replace in `replace_file`
+a619bfd Add additional commits to CHANGELOG missed in 2.7.19rc1
+1dd660a (Maint) Remove reference to Patchwork
+a26d1ee Replace "the short version" with outline
+b73d0dd (#15595) Improve message on SSL errors
+9567ec8 (#15595) Clear up tests around ssl errors
+ccca77f use error_message instead of error
+3809b59 updates as requested
+e7b3049 (#15595) Offer better errors for certificate validation errors
+6a43e96 Update CONTRIBUTING.md
+c44973c (Maint) Remove some more ambiguity
+c236001 Use rspec 2.11 compatible block syntax
+b504ab7 Fix buggy resource title tests
+00b563d (Maint) Be more honest about submission methods
+b90c92b (Maint) Clarify that Redmine tickets are mandatory
+62c14bd (Maint) Clarify which branches changes should be based on
+c0a0a45 tidy.rb: Added info about the default value of 'type' to the doc.
+2d994c2 Switch Rakefile off deprecated rake/gempackagetask
+7324f54 Update main readme to have links to contrib and dev docs
+57a74f7 (13070) Mark files as loaded before we load
+a23cf6e (Maint) Don't assume paths are absolute
+dd96d84 Determine packaging version with git describe
+04fbccd Try again to avoid circular dependency in file indirections
+3e23686 Avoid circular requirement in FileMetadata indirection
+125ecec (Maint) Spec test wasn't testing anything
+4c18d08 (#14964) Unlink Tempfiles consistently across different ruby versions
+690c39b (Maint) Require the right file for md5
+44ada58 Extract host validation in store report processor
+91df2f3 Use cross-platform absolute paths in file_serving tests
+c7e4ca7 (#15221) Create /etc/puppet/modules directory for puppet module tool
+c05489b (Maint:) Fix bad doc strings for two settings ("wether")
+33fce73 Try again to avoid circular dependency in file indirections
+b227aa1 Remove useless tests for Envelope
+86ccca4 Clear deprecation warnings between tests
+d7078c3 Avoid circular requirement in FileMetadata indirection
+03d546e (Maint) Document common Windows issues
+761b48f (#11868) Use `Installer` automation interface to query package state
+cc4d8d2 Don't allow resource titles which aren't strings
+37742db Eliminate require calls at runtime.
+be5fcf4 Fix broken TransBucket transformation tests.
+8f99187 Fix broken ability to remove resources from the catalog.
+9bd4fd3 Fix type check when transforming catalog.
+825b80d Fix all trivial "should to must" errors in our tests.
+7a7bea7 Enforce "must not should" on Puppet::Type instances in tests.
+39f0bf4 (#14962) PMT doesn't support setting a relative modulepath
+39f425f (#15078) Document USR2 log rotation signal
+300fce9 (#14909) Update createpackage.sh to resolve permissions issues
+0d5a46a (#14600) Fix cleanup of tempfiles in file_spec
+2141905 (maint) Add --test to puppet run
+ddf8358 Update logrotate config to not restart puppetmasterd
+da771cb (maint) Add symlink stub to gentoo service provider spec
+0e87fe1 Add comment to upstart provider explaining exclusion of 'wait-for-state'
+0219818 (#14531) Change default ensure value from symlink to link
+0cab9ee Upstart code cleanup, init provider improvement
+91628be Add spec test for network-interface-security
+b60ad19 Add basic service resource test to upstart acceptance
+a6245f9 Handle network-interface-security in upstart
+60e37b6 Add exclude list to upstart provider
+2911fec (#15027, #15028, #15029) Fix upstart version parsing
+8efc492 (#13489) Use let to memoize instance variables
+dc5f57c (#13489) Synchronously start and stop services
+3ada851 (#14964) Don't fail if we can't unlink the Tempfile on Windows
+0b01bb3 (#14860) Fix puppet cert exit status on failures
+d7e77eb (#14749) Clear reference to invalid task after saving
+a2d9597  (#13008) Allow scheduled task arguments to be specified
+c6af946 (#13009) Compare scheduled task commands using backslashes
+b572810 (#14599) Handle ENOTDIR in file type
+2fc7191 (#9160) Change logging facility to debug for not supported provider features
+0859364 (#13880) Add openrc spec - service with extreme long name
+af6f7ba (#13880) Add openrc service provider for Gentoo and Funtoo
+5146397 (#13379) Add path of pluginsync'd lenses to Augeas load_path automatically
+087d5ae (#7285) Add spec for Augeas initialisation and file loading
+06eb9a9 Fixes for #10915 and #11200 - user provider for AIX
+ed73845 (#10354) added delete command to fix missing userdel flag in useradd provider
+
 2.7.18
 ===
 d804782 Reject directory traversal in store report processor

data/CONTRIBUTING.md

@@ -1,88 +1,89 @@
-Checklist (and a short version for the impatient)
+Checklist/Outline (The short version)
 =================================================
 
-  * Commits:
-
-    - Make commits of logical units.
-
-    - Check for unnecessary whitespace with "git diff --check" before
-      committing.
-
-    - Commit using Unix line endings (check the settings around "crlf" in
-      git-config(1)).
-
-    - Do not check in commented out code or unneeded files.
-
-    - The first line of the commit message should be a short
-      description (50 characters is the soft limit, excluding ticket
-      number(s)), and should skip the full stop.
-
-    - If there is an associated Redmine ticket then the first line
-      should include the ticket number in the form "(#XXXX) Rest of
-      message".
-
-    - The body should provide a meaningful commit message, which:
-
-      - uses the imperative, present tense: "change", not "changed" or
-        "changes".
-
-      - includes motivation for the change, and contrasts its
-        implementation with the previous behavior.
-
-    - Make sure that you have tests for the bug you are fixing, or
-      feature you are adding.
-
-    - Make sure the test suite passes after your commit (rake spec unit).
-
-  * Submission:
-
-    * Pre-requisites:
-
-      - Make sure you have a [Redmine account](http://projects.puppetlabs.com)
-
-      - Sign the [Contributor License Agreement](https://projects.puppetlabs.com/contributor_licenses/sign)
-
-    * Preferred method:
-
-      - Fork the repository on GitHub.
-
-      - Push your changes to a topic branch in your fork of the
-        repository.
-
-      - Submit a pull request to the repository in the puppetlabs
-        organization.
-
-    * Alternate methods:
-
-      - Mail patches to puppet-dev mailing list using `rake mail_patches`,
-        or `git-format-patch(1)` & `git-send-email(1)`.
-
-      - Attach patches to Redmine ticket.
-
+  * Getting Started: 
+    - Make sure you have a [Redmine account](http://projects.puppetlabs.com)
+    - Submit a ticket for your issue, assuming one does not already exist. 
+    - Decide what to base your work off of 
+      * `2.6.x`: security fixes only
+      * `2.7.x`: bug fixes only
+      * `3.x`: new features that are not breaking changes
+      * `master`: new features that are breaking changes 
+    
+  * Making Changes: 
+     - Make sure you have a [GitHub account](https://github.com/signup/free)
+     - Fork the repository on GitHub
+     - Make commits of logical units.
+     - Check for unnecessary whitespace with "git diff --check" before committing.
+     - Make sure your commit messages are in the proper format 
+     - Make sure you have added the necessary tests for your changes
+     - Run _all_ the tests to assure nothing else was accidentally broken 
+
+  * Submitting Changes: 
+     - Sign the [Contributor License Agreement](https://projects.puppetlabs.com/contributor_licenses/sign)
+     -  Push your changes to a topic branch in your fork of the repository.
+     -  Submit a pull request to the repository in the puppetlabs organization.
+     -  Update your Redmine ticket 
+   
 The long version
 ================
 
-  0.  Decide what to base your work on.
-
-      In general, you should always base your work on the oldest
-      branch that your change is relevant to.
-
-      - A bug fix should be based on the current stable series. If the
-        bug is not present in the current stable release, then base it on
-        `master`.
-
-      - A new feature should be based on `master`.
-
-      - Security fixes should be based on the current maintenance series
-        (that is, the previous stable series).  If the security issue
-        was not present in the maintenance series, then it should be
-        based on the current stable series if it was introduced there,
-        or on `master` if it is not yet present in a stable release.
-
-      The current stable series is 2.7.x, and the current maintenance
-      series is 2.6.x.
-
-  1.  Make separate commits for logically separate changes.
+  0. Create a Redmine ticket for the change you'd like to make.
+     
+	 It's very important that there be a Redmine ticket for the change 
+	 you are making. Considering the number of contributions which are 
+	 submitted, it is crucial that we know we can find the ticket on Redmine.
+	
+	 Before making a ticket however, be sure that one does not already exist.
+	 You can do this by searching Redmine or by trying a Google search which 
+	 includes `sites:projects.puppetlabs.com` in addition to some of the keywords 
+	 related to your issue. 
+	
+	 If you do not find a ticket that that accurately describes the work 
+	 you're going to be doing, go ahead and create one. But be sure to 
+	 look for related tickets and add them to the 'related tickets' section.
+
+  1.  Decide what to base your work on.
+
+	  In general, you should always base your work on the oldest 
+	  branch that your change is relevant to, and it will be 
+	  eventually merged up. Currently, branches will be merged up as 
+	  follows: 
+	    2.6.x => 2.7.x => 3.x => master 
+	
+	  Currently, this is how you should decide where to target your changes: 
+	
+	  The absolute earliest place something should be targeted is at `2.6.x`, 
+	    and these should _only_ be security fixes. Anything else must be
+	    targeted at a later branch.
+	
+	  A bug fix should be based off the the earliest place where it is 
+		relevant. If it first appears in `2.7.x`, then it should be 
+		targeted here and eventually merged up to `3.x` and master. 
+		
+	  New features which are _backwards compatible_ should be targeted 
+	    at the next release, which currently is `3.x`. 
+	
+	  New features that are _breaking changes_ should be targeted at 
+		`master`.
+
+      Part of deciding what to what your work should be based off of includes naming 
+	  your topic branch to reflect this. Your branch name should have the following 
+	  format: 
+	  		`ticket/target_branch/ticket_number_short_description_of_issuee` 
+	
+	  For example, if you are fixing a bug relating to the ssl spec, which has Redmine 
+	  ticket number 12345, then your branch should be named: 
+			`ticket/2.7.x/12345_fix_ssl_spec_tests` 
+			
+	  There is a good chance that if you submit a pull request _from_ master _to_ master, 
+	  Puppet Labs developers will suspect that you're not sure about the process. This is 
+	  why clear naming of branches and basing your work off the right place will be 
+	  extremely helpful in ensuring that your submission is reviewed and merged. Often times
+	  if your change is targeted at the wrong place, we will bounce it back to you and wait 
+	  to review it until it has been retargeted. 
+
+  2.  Make separate commits for logically separate changes.
 
       Please break your commits down into logically consistent units
       which include new or changed tests relevent to the rest of the
@@ -94,7 +95,7 @@ The long version
       If you're going to refactor a piece of code, please do so as a
       separate commit from your feature or bug fix changes.
 
-      We also really appreciate changes that include tests to make
+      It's crucial that your changes include tests to make
       sure the bug isn't re-introduced, and that the feature isn't
       accidentally broken.
 
@@ -115,7 +116,11 @@ The long version
       whitespaces or other "whitespace errors".  You can do this by
       running "git diff --check" on your changes before you commit.
 
-  2.  Sign the Contributor License Agreement
+      When writing commit messages, please be sure they meet 
+	  [these standards](https://github.com/erlang/otp/wiki/Writing-good-commit-messages), and please include the ticket number in your 
+	  short summary. It should look something like this: `(#12345) Fix this issue in Puppet`
+
+  3.  Sign the Contributor License Agreement
 
       Before we can accept your changes, we do need a signed Puppet
       Labs Contributor License Agreement (CLA).
@@ -131,106 +136,46 @@ The long version
       If you have any questions about the CLA, please feel free to
       contact Puppet Labs via email at cla-submissions@puppetlabs.com.
 
-  3.  Sending your patches
-
-      We accept multiple ways of submitting your changes for
-      inclusion.  They are listed below in order of preference.
-
-      Please keep in mind that any method that involves sending email
-      to the mailing list directly requires you to be subscribed to
-      the mailing list, and that your first post to the list will be
-      held in a moderation queue.
-
-      * GitHub Pull Requests
-
-        To submit your changes via a GitHub pull request, we _highly_
-        recommend that you have them on a topic branch, instead of
-        directly on "master" or one of the release, or RC branches.
-        It makes things much easier to keep track of, especially if
-        you decide to work on another thing before your first change
-        is merged in.
+  4.  Sending your patches
 
-        GitHub has some pretty good
-        [general documentation](http://help.github.com/) on using
-        their site.  They also have documentation on
-        [creating pull requests](http://help.github.com/send-pull-requests/).
+      To submit your changes via a GitHub pull request, you must
+      have them on a topic branch, instead of directly on "master" 
+      or one of the release, or RC branches. It makes things much easier 
+      to keep track of, especially if you decide to work on another thing
+      before your first change is merged in.
 
-        In general, after pushing your topic branch up to your
-        repository on GitHub, you'll switch to the branch in the
-        GitHub UI and click "Pull Request" towards the top of the page
-        in order to open a pull request.
+      GitHub has some pretty good
+      [general documentation](http://help.github.com/) on using
+      their site.  They also have documentation on
+      [creating pull requests](http://help.github.com/send-pull-requests/).
 
-        You'll want to make sure that you have the appropriate
-        destination branch in the repository under the puppetlabs
-        organization.  This should be the same branch that you based
-        your changes off of.
+      In general, after pushing your topic branch up to your
+      repository on GitHub, you'll switch to the branch in the
+      GitHub UI and click "Pull Request" towards the top of the page
+      in order to open a pull request.
 
-      * Other pull requests
+      You'll want to make sure that you have the appropriate
+      destination branch in the repository under the puppetlabs
+      organization.  This should be the same branch that you based
+      your changes off of.
 
-        If you already have a publicly accessible version of the
-        repository hosted elsewhere, and don't wish to or cannot use
-        GitHub, you can submit your change by requesting that we pull
-        the changes from your repository by sending an email to the
-        puppet-dev Google Groups mailing list.
+  5.  Update the related Redmine ticket.
 
-        `git-request-pull(1)` provides a handy way to generate the text
-        for the email requesting that we pull your changes (and does
-        some helpful sanity checks in the process).
-
-      * Mailing patches to the mailing list
-
-        If neither of the previous methods works for you, then you can
-        also mail the patches inline to the puppet-dev Google Group
-        using either `rake mail_patches`, or by using
-        `git-format-patch(1)`, and `git-send-email(1)` directly.
-
-        `rake mail_patches` handles setting the appropriate flags to
-        `git-format-patch(1)` and `git-send-email(1)` for you, but
-        doesn't allow adding any commentary between the '---', and the
-        diffstat in the resulting email.  It also requires that you
-        have created your topic branch in the form
-        `<type>/<parent>/<name>`.
-
-        If you decide to use `git-format-patch(1)` and
-        `git-send-email(1)` directly, please be sure to use the
-        following flags for `git-format-patch(1)`: -C -M -s -n
-        --subject-prefix='PATCH/puppet'
-
-      * Attaching patches to Redmine
-
-        As a method of last resort you can also directly attach the
-        output of `git-format-patch(1)`, or `git-diff(1)` to a Redmine
-        ticket.
-
-        If you are generating the diff outside of Git, please be sure
-        to generate a unified diff.
-
-  4.  Update the related Redmine ticket.
-
-      If there's a Redmine ticket associated with the change you
-      submitted, then you should update the ticket to include the
-      location of your branch, and change the status to "In Topic
-      Branch Pending Merge", along with any other commentary you may
-      wish to make.
+      You should update the Redmine ticket associated 
+      with the change you submitted to include the location of your branch
+      on the `branch` field of the ticket, and change the status to 
+      "In Topic Branch Pending Review", along with any other commentary 
+       you may wish to make.
 
 How to track the status of your change after it's been submitted
 ================================================================
 
-Shortly after opening a pull request on GitHub, there should be an
-automatic message sent to the puppet-dev Google Groups mailing list
-notifying people of this.  This notification is used to let the Puppet
+Shortly after opening a pull request, there should be an automatic 
+email sent via GitHub. This notification is used to let the Puppet
 development community know about your requested change to give them a
 chance to review, test, and comment on the change(s).
 
-If you submitted your change via manually sending a pull request or
-mailing the patches, then we keep track of these using
-[patchwork](https://patchwork.puppetlabs.com).  When code is merged
-into the project it is automatically removed from patchwork, and the
-Redmine ticket is manually updated with the commit SHA1.  In addition,
-the ticket status must be updated by the person who merges the topic
-branch to a status of "Merged - Pending Release"
-
-We do our best to comment on or merge submitted changes within a week.
+We do our best to comment on or merge submitted changes within a about week.
 However, if there hasn't been any commentary on the pull request or
 mailed patches, and it hasn't been merged in after a week, then feel
 free to ask for an update by replying on the mailing list to the
@@ -246,8 +191,6 @@ Additional Resources
 
 * [Bug tracker (Redmine)](http://projects.puppetlabs.com)
 
-* [Patchwork](https://patchwork.puppetlabs.com)
-
 * [Contributor License Agreement](https://projects.puppetlabs.com/contributor_licenses/sign)
 
 * [General GitHub documentation](http://help.github.com/)

data/README.md

@@ -8,6 +8,7 @@ configurations) based on a centralized specification.
 Documentation (and detailed installation instructions) can be found online at the
 [Puppet Docs site](http://docs.puppetlabs.com).
 
+
 Installation
 ------------
 
@@ -32,6 +33,13 @@ Generally, you need the following things installed:
 
 * Facter => 1.5.1 (available via your package manager or from the [Facter site](http://puppetlabs.com/projects/facter).
 
+Contributions
+------
+Please see our [Contibution
+Documents](https://github.com/puppetlabs/puppet/blob/master/CONTRIBUTING.md)
+and our [Developer
+Documentation](https://github.com/puppetlabs/puppet/blob/master/README_DEVELOPER.md).
+
 License
 -------
 

data/README_DEVELOPER.md

@@ -63,9 +63,7 @@ SyntaxError, invalid multibyte escape as mentioned above.
 # Windows #
 
 If you'd like to run Puppet from source on Windows platforms, the
-include `ext/envpuppet.bat` will help.  All file paths in the Puppet
-code base should use a path separator of / regardless of Windows or
-Unix filesystem.
+include `ext/envpuppet.bat` will help.
 
 To quickly run Puppet from source, assuming you already have Ruby installed
 from [rubyinstaller.org](http://rubyinstaller.org).
@@ -88,4 +86,41 @@ on Windows, so use the following rspec exclude filter:
 This will give you a shared filesystem with your Mac and allow you to run
 Puppet directly from source without using install.rb or copying files around.
 
+## Common Issues ##
+
+ * Don't assume file paths start with '/', as that is not a valid path on
+   Windows.  Use Puppet::Util.absolute_path? to validate that a path is fully
+   qualified.
+
+ * Use File.expand_path('/tmp') in tests to generate a fully qualified path
+   that is valid on POSIX and Windows.  In the latter case, the current working
+   directory will be used to expand the path.
+
+ * Always use binary mode when performing file I/O, unless you explicitly want
+   Ruby to translate between unix and dos line endings.  For example, opening an
+   executable file in text mode will almost certainly corrupt the resulting
+   stream, as will occur when using:
+
+     IO.open(path, 'r') { |f| ... }
+     IO.read(path)
+
+   If in doubt, specify binary mode explicitly:
+
+     IO.open(path, 'rb')
+
+ * Don't assume file paths are separated by ':'.  Use File::PATH_SEPARATOR
+   instead, which is ':' on POSIX and ';' on Windows.
+
+ * On Windows, File::SEPARATOR is '/', and File::ALT_SEPARATOR is '\'.  On
+   POSIX systems, File::ALT_SEPARATOR is nil.  In general, use '/' as the
+   separator as most Windows APIs, e.g. CreateFile, accept both types of
+   separators.
+
+ * Don't use waitpid/waitpid2 if you need the child process' exit code,
+   as the child process may exit before it has a chance to open the
+   child's HANDLE and retrieve its exit code.  Use Puppet::Util.execute.
+
+ * Don't assume 'C' drive.  Use environment variables to look these up:
+
+    "#{ENV['windir']}/system32/netsh.exe"
 EOF