Merge pull request #285 from mattkirby/add_changelog

(doc) Add changelog and contributing guidlines

CHANGELOG.md

@@ -0,0 +1,44 @@
+# Change Log
+
+All notable changes to this project will be documented in this file.
+
+The format is based on
+[Keep a Changelog](http://keepachangelog.com)
+& makes a strong effort to adhere to
+[Semantic Versioning](http://semver.org).
+
+Tracking in this Changelog began for this project with the tagging of version 0.1.0.
+If you're looking for changes from before this, refer to the project's
+git logs & PR history.
+
+# [Unreleased](https://github.com/puppetlabs/vmpooler/compare/4c858d012a262093383e57ea6db790521886d8d4...master)
+
+### Fixed
+
+- Remove unused method `find_pool` and related pending tests
+- Setting `max_tries` results in an infinite loop (POOLER-124)
+- Do not evaluate folders as VMs in `get_pool_vms` (POOLER-40)
+- Expire redis VM key when clone fails (POOLER-31)
+- Remove all usage of propertyCollector
+- Replace `find_vm` search mechanism (POOLER-68)
+- Fix configuration file loading (POOLER-103)
+- Update vulnerable dependencies (POOLER-101)
+
+### Added
+
+- Allow API and manager to run separately (POOLER-109)
+- Add configuration API endpoint (POOLER-107)
+- Add option to disable VM hostname mismatch checks
+- Add a gemspec file
+- Add time remaining information (POOLER-81)
+- Ship metrics for clone to ready time (POOLER-34)
+- Reduce duplicate checking of VMs
+- Reduce object lookups when retrieving VMs and folders
+- Optionally create delta disks for pool templates
+- Drop support for any ruby before 2.3
+- Add support for multiple LDAP search base DNs (POOLER-113)
+- Ensure a VM is only destroyed once (POOLER-112)
+- Add support for setting redis server port and password
+- Greatly reduce time it takes to add disks
+- Add Dockerfile that does not bundle redis
+- Add vmpooler.service to support systemd managing the service

CONTRIBUTING.md

@@ -0,0 +1,86 @@
+# How to contribute
+
+Third-party patches are essential for keeping vmpooler great. We want to keep it as easy as possible to contribute changes that
+get things working in your environment. There are a few guidelines that we
+need contributors to follow so that we can have a chance of keeping on
+top of things.
+
+## Getting Started
+
+* Make sure you have a [Jira account](http://tickets.puppetlabs.com)
+* Make sure you have a [GitHub account](https://github.com/signup/free)
+* Submit a ticket for your issue, assuming one does not already exist.
+  * Clearly describe the issue including steps to reproduce when it is a bug.
+  * Make sure you fill in the earliest version that you know has the issue.
+* Fork the repository on GitHub
+
+## Making Changes
+
+* Create a topic branch from where you want to base your work.
+  * This is usually the master branch.
+  * Only target release branches if you are certain your fix must be on that
+    branch.
+  * To quickly create a topic branch based on master; `git checkout -b
+    fix/master/my_contribution master`. Please avoid working directly on the
+    `master` branch.
+* 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.
+
+````
+    (POOLER-1234) Make the example in CONTRIBUTING imperative and concrete
+
+    Without this patch applied the example commit message in the CONTRIBUTING
+    document is not a concrete example.  This is a problem because the
+    contributor is left to imagine what the commit message should look like
+    based on a description rather than an example.  This patch fixes the
+    problem by making the example concrete and imperative.
+
+    The first line is a real life imperative statement with a ticket number
+    from our issue tracker.  The body describes the behavior without the patch,
+    why this is a problem, and how the patch fixes the problem when applied.
+````
+
+* Make sure you have added the necessary tests for your changes.
+* Run _all_ the tests to assure nothing else was accidentally broken.
+
+## Making Trivial Changes
+
+### Documentation
+
+For changes of a trivial nature to comments and documentation, it is not
+always necessary to create a new ticket in Jira. In this case, it is
+appropriate to start the first line of a commit with '(doc)' instead of
+a ticket number.
+
+````
+    (doc) Add documentation commit example to CONTRIBUTING
+
+    There is no example for contributing a documentation commit
+    to the Puppet repository. This is a problem because the contributor
+    is left to assume how a commit of this nature may appear.
+
+    The first line is a real life imperative statement with '(doc)' in
+    place of what would have been the ticket number in a
+    non-documentation related commit. The body describes the nature of
+    the new documentation or comments added.
+````
+
+## Submitting Changes
+
+* Sign the [Contributor License Agreement](http://links.puppetlabs.com/cla).
+* 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 Jira ticket to mark that you have submitted code and are ready for it to be reviewed (Status: Ready for Merge).
+  * Include a link to the pull request in the ticket.
+* The Puppet SRE team looks at Pull Requests on a regular basis.
+* After feedback has been given we expect responses within two weeks. After two
+  weeks we may close the pull request if it isn't showing any activity.
+
+# Additional Resources
+
+* [Puppet Labs community guildelines](http://docs.puppetlabs.com/community/community_guidelines.html)
+* [Bug tracker (Jira)](http://tickets.puppetlabs.com)
+* [Contributor License Agreement](http://links.puppetlabs.com/cla)
+* [General GitHub documentation](http://help.github.com/)
+* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)