[Nagiosplug-devel] A couple of suggestions

[Benoit Mortier]

Le samedi 4 Décembre 2004 13:36, Andreas Ericsson a écrit :
> 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.

Yes ;-) As i am the responsible for all the recents commits and hitcups in 
code quality ;-)

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

Yes thats normaly done only on nightly build, will ask ton if it's possible.
but i compile it normaly on my box first, before committing, the problem is 
i have not all dependancies in my box.

I have know a chroot to build the package with all his dependencies without 
ruining my box ;-)

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

Yes but that was needed to make internationalization work at all ;-)

But the good news i now this is nearly finished, and as reduced the need to 
localization a lot of string but around 200 hundred, that's a lot of work 
not to be done.

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

Internationalization should not be a problem right now, but a freeze date is 
always a good idea and your testcase is welcome of course.

I am in te process of making a template plugin to ease creations of new 
plugins, and a dictionnary of string to use in english and translations.

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

The signal thing is effectively a problem, i have seen in numerous part of 
the plugins, getting a signal not checked etc..

I have a lot of check_hpdj in the newtorks i monitor ;-)

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

good.

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

Yes, i like pretty much all of them except for the plugin in perl but that 
my taste, and i thing the plugin should be written in a consisten manner, 
not the to different way of coding we see right now.

I will also try to enhance the developper guidelines.

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

We want all the best code and deserve a flame if we didn't do the thing 
right ;-)
-- 
Benoit Mortier
OpenSides sprl
Linux Engineer