77 lines
3.2 KiB
Plaintext
77 lines
3.2 KiB
Plaintext
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.
|