[Nagiosplug-devel] Nagios plugins CPAN-like archive

[Andreas Ericsson]

Voon, Ton wrote:
> Sorry for top-posting.
> 
> Why would non-clashing names not last? For example, if there were
> multiple implementations of check_physical_disk, how do you propose they
> be differentiated? By author? I think a restriction of non-clashing
> names will force people to use more suitable names
> (check_rs6000_physical_disks). Easier to lift a restriction than to
> apply one later.
> 

I thought you meant the naming standard thing Sean brought up. 
Non-clashing names is fairly obvious after all (although check_log and 
check_log2 seems legal to me).


> I think user feedback is good for a guage on the quality of the plugin.
> It effectively moves the auditing of a plugin from a small set of people
> (the dev team) to the wider community. I use the Amazon review system a
> lot to guage how good a product is - I don't see how that is different
> on a plugin basis. However, not essential on day 1, hence in the SHOULD
> HAVE.
> 

But you stated SHOULD HAVE must be implemented in the near future (a 
couple of weeks). It is in no respect vital to the functionality of the 
plugin or the NPAN's (Nagios Plugin Archive Network) functionality. 
Granted, it's nice if it's there, but compared to amazon (a couple of 
million hits per day) it won't be even half as valuable, and I don't 
think very many people will vote for it. Also, authors will ofcourse 
vote top grade for their own plugins, so initially every plugin would be 
top rated.


> Apologies if I missed your other objections. Can you summarise?
> 

You didn't miss any, so I'll skip the summary.

> 
> -----Original Message-----
> From: nagiosplug-devel-admin at lists.sourceforge.net
> [mailto:nagiosplug-devel-admin at lists.sourceforge.net] On Behalf Of
> Andreas Ericsson
> Sent: 14 July 2005 21:58
> To: NagiosPlug Devel
> Subject: Re: [Nagiosplug-devel] Nagios plugins CPAN-like archive
> 
> 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