[Nagiosplug-devel] A couple of suggestions

[Andreas Ericsson]

Ahoy.

I might as well apologize right away, since this probably won't go down 
too well with all of the developers.

Down to business.

I'm delighted to see that plugin development pace has picked up. I'm not 
equally delighted in the deterioration of code quality and the apparent 
lack of even basic testing of checked in changes.

Suggestions;
1. Provide a cvs commit script containing only the extremely simple line 
below;
./configure && make && make distclean && cvs "$@" commit
(the "$@" lets people specify their own -m "commiting plugins" message 
and whatnot). Decapitate developers that check in code that doesn't pass 
this simple test.
The number of prettyprint commits (internationalization falls under 
prettyprint) that has broken the compilation process of the plugins is 
appalling and downright silly. Most of the problems can be traced to 
missing parentheses or semicolons which is just plain dumb and most of 
the time not even worthy of a patch submission.

2. Set a date where nothing but bugfixes make it into the repository. 
Put a halt in internationalization, porting (to new platforms, that is), 
prettyness and whatever else might be nice to have and concentrate on 
making the plugins build and execute properly. Decide what functionality 
you'll be supporting. Create a testcase (I'm already working on an 
easily extendable one) that tests all of that functionality and run it 
for each change before checking in changes.

3. When the plugins are stabilized (petty stuff frozen and bugfix period 
has come to an end), release a beta and review the plugins for best 
practices. A couple of examples;
The check_load plugin should have
float load[3], warn[3], crit[3];
instead of the present code.
check_hpjd (well, all plugins, but check_hpjd doesn't) should do signal 
handling to determine timeout instead of assuming that's what happened 
when snmpget sends output to stderr. It should also pass -Onq instead of 
-OQa (which currently yields unparseable output and throws an error with 
ucd-snmp 4.x). Possibly, output parsing plugins should be rewritten in 
perl if the increased load is justifiable for the more rarely used 
plugins (how many check_hpjd checks does people have in each network?).
Replace hard-to-port code with more portable such where possible.

4. Have another bugfix period, open for regression fixes only. Make sure 
the "best practice" changes doesn't break functionality. If they do, 
roll them back and put a TODO to do a later review of that plugin.

5. Release stable when all checks pass the testcase.


This sort of simplified version of Extreme Programming works fairly well 
to help keeping the release cycle on schedule by the simple expedient of 
helping developers focus on what's currently important.

These are only suggestions. If you (plugin developers) don't like them, 
then don't follow them.

Disclaimer;
I'm well aware of the fact that the plugin developers do this for free 
and on their spare time. That's not an excuse not to do things properly. 
If anyone on the plugin developmen team thinks this is an overwhelming 
task then just drop the commits for a while (so any patches created will 
be valid) and I'll have a patch to bring it to and complete phase 3 by 
the end of next week (that's 4 days before next planned alpha release).


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