[Nagiosplug-devel] Nagios plugins CPAN-like archive
Andreas Ericsson
ae at op5.se
Thu Jul 14 14:01:08 CEST 2005
Ton Voon wrote:
> Thank you for your thoughts on the future plugin archive. Matthias Eble
> coined this as NP-CPAN, which I will use for now.
>
> In summary:
>
> Need to move away from contrib area. For: Richard Brodie, Sean Finney,
> Andreas Ericsson. Against: none.
>
> Control of names of plugins. Andreas thinks this is not possible and I
> would agree with him. However, I would like names not to clash
> (thinking about simplified downloading). Matthias is worried about
> check_http and check_http2, etc. I'm not sure we can control this in
> any meaningful way, so a user will need to decide on which plugin they
> would use. I think if we could get a sense of how "maintained" a plugin
> is and other users feedback, this would help a user in making a
> decision on which to use.
>
> Quality issues. Sean is worried about quality of external plugins, but
> the point of this is to be able to unleash the community to develop and
> maintain their plugins themselves. Andreas is right: current contribs
> are not really QA'd and forks will happen. I think Stanley Hopcroft
> said it best: "CPAN is [...] absolutely indispensable [...] because of
> the high quality of __some__ of the modules [and is a] dumping ground
> for other modules of lower quality". I think plugins will sink or rise
> based on popularity and/ or quality, which will be unrelated to how
> Nagios Plugins performs.
>
> Easy install. Richard mentions an unstable package for download, which
> shows some degree of "blessed" plugins by the project. As the point is
> to unleash, I don't think this is a reasonable expectation because it
> is again putting work onto this project. However, NP-CPAN should have
> some easy way of installing plugins.
>
> Certification. Sean thinks is a good idea, but also wants metrics on
> whether audited, or scheduled for inclusion. Again, as my aim is to
> unleash, I think auditing is an impossible objective. I would hope that
> some plugins come with test cases too, but that is fully up to the
> developer.
>
> Nagiosexchange. Sean says in his previous experience they seem
> "reasonable" and given they have some infrastructure already there, I'm
> inclined to talk with them.
>
> So I think there is a consensus to do it. No one has really commented
> on requirements, so here's my interpretation of the responses plus a
> few of my own:
>
> MUST HAVE: mirroring of repository, last updated, non-clashing plugin
> names
Skip the non-clashing plugin names. It won't last. Also, the entire site
must be mirror-able through plain FTP or some such. wget and other
web-mirroring programs have a tendency to include weird things and skip
some others. A pure and simple lftp-style mirroring is the best.
> SHOULD HAVE: user feedbacks, certification results
> NICE TO HAVE: easy downloadability
>
I think that "easy downloadability" actually comes first, since a
repository is completely useless unless the data can be extracted from
it in a simple manner. User feedbacks is more like nice to have (it's
not very used on CPAN, and I don't really think people will sit around
and vote for various plugins).
> I think the must haves must be available for NP-CPAN to be endorsed,
> with should haves as soon as possible.
>
> So, unless there are any objections by next Tuesday, I'll begin
> discussions with Nagiosexchange if they can be our official repository.
>
Well, I had some objections, but for the sake of expediency you can
simple disregard them.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Lead Developer
More information about the Devel
mailing list