Why did you split the repos
This was done to simplify the deployment and delivery process. When working with a repo as diverse as the community-plugins it's very hard to version and deploy in the methods that we all would like. Splitting the repo into smaller pieces makes this much easier and more manageable in the long run.
Why are the repos named this way
The repos are named based up the application, product, or function they are associated with. This means that if you use apache, you need only install the sensu-plugins-apache gem or clone the repo. When it comes to handlers, extensions, and mutators the same convention was used so that in the future if a check or extension is added the repo name won't change. Sensu-plugins-pagerduty is a great example, it may only contain handlers at this time but if in the future we want to add a check of an endpoint we don't need to do anything more than bump the version and update the docs.
Besides having a standard naming convention makes automation and deployment tools very happy and we all use them right?
How do I know what a repo contains
One of the conditions for dropping the prerelease or alpha tag will be a complete README that will include a list of all binaries and what each one does, sensu-plugins-disk-checks does this now.
Why did you change the filenames and why name them this way
One of the overriding issues is that there should be a standard naming scheme for the entire framework. It is very hard to effectively automate something if the pieces are scattered or named differently. As of now plugin is here to stay.
What about tests, how do I know a plugin works as designed
Tests are coming, that is one of the core requirements for stability and production grade. Tests are hard to write for some of these things given the very specific nature of them and most of us have other jobs so we can only contribute so much.
How do I use this handler, deploy this check
The readme will contain sample configs and commands. Many of the plugins also have a header that contains specific details. If this is lacking ask in IRC or on the mailing list and someone will be able to assist you.
Will the community-plugins repo be deleted and if so when
No! It will be frozen in place at a date TBD, most likely sometime this summer although that is a moving target and dependent upon a lot of things.
How should I deploy the new plugins
If a gem exists then that would be the best way. Instructions for installing it can be found in the README of the repo or here. If no gem exists yet, then you can attempt to build one based upon the gemspec. You can also install straight from source.
All repos have releases, you can just download the latest tarball or zip file, cloning the master branch is not recommended, supported and never will be. Unless it's a breaking change, the repo will not contain feature branches, everything will be pushed to master. You have been warned.
Checks are invasive how do I know they haven't been tampered with
All gems will be signed and each repo will contain the public key. If you are really concerned you could just inspect the code yourself as well before deployment.
Will you be targeting other pkg management systems
Not at this time, due to the design of Sensu, gems are the best choice. RPM's and Deb packages have not been ruled out but the manpower to create them is just not there at this time. If you have a very strong interest in this drop us a line and we can chat some more.
Are the gems dependent upon Rubygems
No
What is the policy on supporting end-of-life(EOL) Ruby versions
We will target the latest the EOL Ruby, currently that is 1.9.3
What versions or Ruby do you test against
1.9.3, 2.0, 2.1, 2.2
Note: Linting is not done against 1.9.3
What do you use for linting
Rubocop
Details are in .rubocop.yml within the root of each repo and in the developer guidelines
What do you use for testing
RSpec