[Nagiosplug-devel] Obsoleted contrib and tarballs files

[Andreas Ericsson]

sean finney wrote:
> 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).
>>

AFAIK, no plugins that have been in contrib for an extended period of 
time has ever been included in the official distro without a clean patch 
from an outside user that makes that last effort to push them into 
stable use.

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

This is only true if you count money. Maintaining code in contrib which 
has superior counterparts or are otherwise obsoleted makes auditing said 
plugins pure pain. I did just that, and scanning through the often-times 
very obscure and shoddy code to deduce what the plugin actually does 
(many don't have any comments or --help output) takes its fair amount of 
time.

>>2 a benefit in demonstrating the projects gratitude for contributed code so
>>that people will produce plugins for the project.
> 

This would be greatly increased if those plugins were actively moved to 
the official distro once in a while. Using ideas from contrib to enhance 
the official counter-part of the plugin is also worthy of mentioning in 
the THANKS file. Accepting plugins per default so that people can feel 
fuzzy inside doesn't make much sense if the plugins only work on the 
plugin authors own machine.

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

For those that aren't redundant with official ones, yes.

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

Umm... I would have thought the metrics for inclusion were in a very 
real way related to code quality.

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

Only beta-testers can use it, but whatever floats your dinghy. I'll 
still be maintaining my own fork of the plugins though. I have neither 
time nor energy to juggle the amount of patches I end up with after an 
audit-run, and I can't really justify my paycheck if I sit around 
waiting for others to do my work for me.

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

A small comment in the form of;
# check_toaster.pl - checks heat emitted from the SNMP-enabled 
SuperToaster, using Net::SNMP.
# Threshold values are in fahrenheit, unless suffixed by C.
# usage: check_toaster.pl -H <ip> -w <warn-heat> -c <crit-heat>

at the top of the script should do it. Some industrious script-person 
can then cook up the right --help function and make sure things are done 
properly.


> but i'm beginning to side with ethan
> and stanley that existing plugins should be grandfathered (does that
> expression work in swedish too?)

Not really. The exact translation (such as it is) would be "Farfara", 
which I'm fairly certain means something very rude in hebrew.

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

Setting up a socket and sending a few commands is not exactly difficult. 
I'll manage without the api, I think. np_runcmd() won't have any impact 
at all.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer