[Nagiosplug-devel] Nagios plugins CPAN-like archive

[Voon, Ton]

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'd obviously expect easy downloading, I think my thoughts were around
automated installs of plugins and maybe groups of plugins. Of course, it
helps if the plugin names do not clash! But you are right, it should be
higher in priority, so I'll move it to MUST HAVE. 

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.

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


-----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


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________________
Nagios Plugin Development Mailing List
Nagiosplug-devel at lists.sourceforge.net
Unsubscribe at
https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue.

::: Messages without supporting info will risk being sent to /dev/null

-----------------------------------------
Egg is a trading name of the Egg group of companies which includes: Egg plc
(reg no 2448340), Egg Financial Products ltd (reg no 3319027), Egg
International ltd (reg no 4059266), Egg Financial Intermediation ltd (reg
no 382828), Egg Investments ltd (reg no 3403963) and Egg Banking plc (reg
no 2999842.  Egg Investments Ltd, Egg Banking plc and Egg Financial
Intermediation Ltd are authorised and regulated by the Financial Services
Authority (FSA) and are entered in the FSA register under numbers 190518,
205621 and 309551 respectively. These members of the Egg group are
registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.    This e-mail is confidential and for
use by the addressee only.  If you are not the intended recipient of this
e-mail and have received it in error, please return the message to the
sender by replying to it and then delete it from your mailbox.  Internet
e-mails are not necessarily secure. The Egg group of companies do not
accept responsibility for changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by the Egg group of companies in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
This communication does not create or modify any contract.