mirror of
https://github.com/monitoring-plugins/monitoring-plugins.git
synced 2026-02-03 18:49:29 -05:00
63734f52ab
This is an initial take at renaming the project to Monitoring Plugins. It's not expected to be fully complete, and it is expected to break things (The perl module for instance). More testing will be required before this goes mainline.
76 lines
3.2 KiB
Text
76 lines
3.2 KiB
Text
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.
|