[Nagiosplug-devel] Obsoleted contrib and tarballs files

[Ton Voon]

Guys,

Sorry, jumping into this thread a bit late.

I think if a contrib plugin has functionality that is available in an  
official plugin, it can go. I'd like the developer to look into it  
though, rather than just take the word of someone else. Err on the  
side of caution and retain.

check_timeout should not be in contrib. I'm happy for it to be an  
official plugin.

I really think we should unshackle ourselves from every plugin in the  
world and setup a CPAN-like area (or promote the use of one). That  
way support is kept with the plugin originators and they can update  
them independently from this project. The Nagios Plugins will still  
be for "core" functionality and showcasing new methods and techniques  
of interfacing with Nagios.

I have had resistance to this idea in the past and I want to reopen  
the debate because I think this is the only way to go in future.

Ton


On 28 Jun 2005, at 16:15, 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).
>>
>> 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
>