[Nagiosplug-devel] Obsoleted contrib and tarballs files

[sean finney]

hi,

(quoting with permission a private mail from stanley hopcroft)

On Tue, Jun 28, 2005 at 02:25:26PM +1000, Stanley Hopcroft wrote:
> I have a different view of /contrib: that /contrib are candidates for
> inclusion in the supported plugins (those in with the /plugin prefix) when
> there is sufficient information to decide that they are popular enough or
> conformant enough for one of the plugin developers to say they should be.
> 
> At present, this is loosely decided based on the number of recommendations
> about a contributed plugin (eg try plugins/check_ica or whatever it's called
> these days).
> 
> The matter of the lower quality of the code is understood by inclusion in
> /contrib. The ISC BIND and DHCP projects both distribute /contrib code with
> disclaimers about fitness for purpose or support; I thought that this was the
> view this project took also.
> 
> There is no doubt that there could be code that is less useful in /contrib but
> it seems to me that there is
> 
> 1 no cost in retaining it
> 
> 2 a benefit in demonstrating the projects gratitude for contributed code so
> that people will produce plugins for the project.

both are good points.  this has to be balanced with a certain amount of
quality control, but i guess that should really be before the plugins
are accepted into contrib.  

> Irrespective of whether there _is_ a superior published plugin
> API/Framework/Modus operandi, I don't think it hurts to provide examples in
> /contrib of simple, script kiddy code that still serves a useful purpose.
> 
> Until the project clearly states that Nagios plugins require this this and
> this and should adhere to these coding standards, I don't think we should
> discard /contrib contributions.

i'm coming around to the same opinion myself for the plugins that aren't
superceded by 'official' plugins.

> To sum up, I don't think this is a debate about the quality of contributed
> code, but about the projects relationship with developers and about the metrics for
> inclusion in the supported plugins..

On Tue, Jun 28, 2005 at 09:50:29AM +0200, Andreas Ericsson wrote:
> I'll set up a different testing release then. Distributing it with the 
> sane plugins that aren't exclusively for testing doesn't make much sense 
> if you ask me, as only core testers will be able to make any use of it 
> at all.

i think just another directory in CVS would be appropriate, wouldn't it?
perhaps nagiosplug/debug-plugins?

> I don't know if you followed the thread from start, but all of the nuked 
> plugins are obsoleted by official ones which have been extended since 
> the contrib ones were contributed. All of them were also notoriously 

with the exception of the rbl/ftp plugins...

> ugly in code and many of them suffered from lots of hardcoded paths and 
> variables. Bringing them up to official standards would have taken more 
> time than anyone can politely be asked to spend, and given their very 
> narrow usage I think it's safe to say that noone would ever have done it.

i think that for future reference, we should have a higher level
of code quality required before plugins are brought into ./contrib
(which should then be documented), but i'm beginning to side with ethan
and stanley that existing plugins should be grandfathered (does that
expression work in swedish too?) in until they can be replaced with
something better.

> That said, if someone wants to check downloads from an FTP-site, I'll be 
> happy to write a (much faster, safer and cleaner) version in C. Given 
> the simplicity of the FTP protocol it shouldn't take much longer than 
> 20-30 minutes.

i'd be happy to see this.  if it's complicated by the upcoming changes
wrt the np_runcmd or other api stuff perhaps we can table it in a TODO
until then.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20050628/94f7272c/attachment.sig>