Antwort: Re: The nagios community wants to keep its open soul

[Andreas Ericsson]

On 03/01/2010 04:19 PM, Sascha.Runschke at gfkl.com wrote:
> I'm using Nagios now for like 8 or 9 years or so.
> I have seen many ideas coming in over the last 2 years, I've seen
> many patches from eager Nagios contributors coming in the last 2 years,
> yet I still have to see that eager participation of the president of
> Nagios Enterprise (c)(r)[tm]. As already mentioned before, it's not
> actually the fact that not everything gets done in an instant, it's
> the fact that the president of Nagios Enterprises (c)(r)[tm] does
> not seem to care about what community members think or whatnot.
> There was no "nice patch, I'll get it in once I get the time" or
> "I'm unsure how the patch behaves, please provide me with a test
> scenario" or maybe even just a "your patch sucks, go away".
> 

That's true. I complained to Ethan about that about a year back too,
and the action he took then was to make me and Ton core developers.
This means Ethan doesn't have to look at all the patches, since me
and Ton can do it instead. And we're doing just that, although some
patches do slip through unnoticed. We're human. Remind us. If it's
done without rancor neither me nor Ton or Ethan will bite your heads
off. They're quite nearly as nice as I am really, but even the nicest
will bite if pushed too far.

> It rather feels like a lot of people are discussing here to no
> avail - since the president of Nagios Enterprises (c)(r)[tm]
> is busy with business.
> 

And well he should be. A president has no business not doing
business. Since he appointed me and Ton core developers we have
a more or less equal footing with regards to code as Ethan does.

> 
> Nice - but what about a bugfree core?

That would be awesome indeed, even though it's a dream we probably
won't ever live to see. I'll work on it though. It seems there are
quite a few rather easily fixable issues on tracker.nagios.org (40,
to be precise).

> Most complaints or wishes I have seen ignored here are actually only
> relevant to the core. All others, especially those mentioned above,
> are healthy open source projects that react quite quickly to requests,
> patches or questions. Let's take NagVis for example - I've contributed
> quite some ideas and even a few patches to the project and so far all
> of them have been either accepted, commented, denied or delayed for
> a future major release by a core dev within a few days.
> 

That's what we're striving for here too.

> 
> We all hoped for changing times, when Ethan went inactive.
> Now we do have those changes big time - but I frankly doubt that
> anyone but Ethan is happy with them. You might go on with "Nagios
> is Ethans baby and he can do what he wants" - yes it is. But
> hundreds and thousands of codelines have been supplied by
> contributors in good faith and those get the shaft now.
> 

No they don't. All of the core is made up of ~64K lines of code.
Other tools can be used by other products as well. Of those 64K
lines of code, Ethan has written about 50K and random contributors
(myself included) have taken care of the remaining 14K.

> 
> I didn't provide any patches to nagios back then because
> Ethan ignored everything anyway and I considered them a waste
> of time. Now I'm really happy I didn't do it and I certainly
> won't provide any in the future...
> 

Well, it's a bit harsh to request that others do something for
you without you wanting to take part of the work too but if
that's a standpoint you can live with, then so be it.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev