Adding upstream version 2.3.5.upstream/2.3.5upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 76 insertions, 0 deletions

diff --git a/SUPPORT b/SUPPORT
new file mode 100644
index 0000000..d2a2b7d
--- /dev/null
+++ b/SUPPORT
@@ -0,0 +1,76 @@
+SUPPORT
+
+Using the mailing lists and issue tracker at GitHub are the
+best ways to obtain direct support for the Monitoring Plugins. There may
+also be commercial support options available to you -- check
+http://www.nagios.org/ to track the current status of commercial
+support offerings.
+
+There are two mailing lists associated with Monitoring Plugins development:
+'help' (mailto:help@monitoring-plugins.org), and 'devel'
+(mailto:help@monitoring-plugins.org). Unless you are fairly
+certain you have found a bug or that you are requesting a new feature,
+please direct support requests to 'help'.
+
+Because these lists are handled entirely by volunteers, and because
+these same volunteers are often plugin developers who can also use
+their time to fix bug and provide feature requests, it is generally in
+you interest to do a modest amount of legwork before posting to either
+of these lists.
+
+Plugins that are in the contrib directories are provided as-is. We will
+try to help, but sometimes the plugins have dependencies that the monitoring-plugin
+developers do not have access to. You may be able to try the authors
+directly.
+
+In brief, always provide the version of the software that you are
+using, and when requesting features or reporting bugs, first check to
+see that the issue has not already been addressed in the current Git
+code.
+
+GETTING HELP
+
+Requests to 'help' require posting the version number of the
+plugin. The best place to include the version information is in the
+subject. A good post would have a subject like:
+
+  Can I use SSL with check_imap (monitoring-plugins 1.3.0-beta2) 1.12
+
+If you do not include the version of the plugin, you risk having your
+post silently ignored.
+
+Be advised that the core plugins (and in fact many of the contributed
+plugins) will provide a description of their use when invoked with the
+'--help' option. Please read the help carefully and in it's entirety
+before asking for support.
+
+REPORTING BUGS AND SUBMITTING PATCHES
+
+Bug reports, investigations of possible bugs, feature requests, and
+patch submissions should be submitted to the development list at
+mailto:devel@monitoring-plugins.org. Please raise an issue first
+in GitHub, otherwise your email is likely to be missed over time.
+
+You should identify the version, preferably in the subject line.
+However, to best use developer resources, it is suggested that you
+reference your report to one of the following sources:
+
+  1) The most recent release, including beta's
+
+  2) The current snapshots (there's a link provided on
+     https://www.monitoring-plugins.org/download.html)
+
+  3) The current Git code from GitHub
+
+(This does not mean you should run any of these sources in a
+production environment - the latter two you clearly should
+not. However, if you find a bug, you should determine whether it is
+still present in one of these sources, preferably either (2) or (3)
+which are most recent.)
+
+From experience, I know that most bugs can be fixed with only a few
+more moments work than it takes to determine if the bug is still
+present in the Git tree. If you can save a developer the expense of
+that time, you ensure that bugs are fixed more rapidly, and thus you
+ensure your problem resolution is reflected in a stable release more
+quickly.