[Nagios-devel] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated)

[Andreas Ericsson]

On 05/12/2011 04:52 PM, Julien Mathis wrote:
> 
>> Thanks for the link though. I've been looking for it but was unable to
>> find the download before you posted it. It should be interesting to see
>> if they can solve the I/O load problems like someone here at the
>> Bolzano conference mentioned they're working on. That's one of my goals
>> too, but so far I haven't had time to sit down and think it through
>> properly. If they have, we should be able to profit from their work
>> quite easily.
>>
>>
> Yes we will work on the subject. We hope you will benefit these
> developments.

Glad to hear it :)

Which version (svn revision number or git commit id) did you fork from?
I'm trying to see what you've done so far, but with patches recently
being applied in Nagios core as well, it's hard to make out the diff
properly. If you're using an import of the code for your repositories
it might be easiest just to publish those online, if possible.

> We have repeatedly offered our help, without success...
> 

That must be something I've missed. I know some patches have fallen
between the cracks last year and some this spring when I was busy at
$dayjob with various things, but the amount of patches submitted and
that I've been poked for isn't such a vast amount that I'd think it
worth announcing a new fullblown fork of Nagios for. Ah well.

I know that not all patches that are submitted are accepted into the
core. That's normal. If I *had* accepted all patches submitted in the
2 or more years that I've been reviewing and queueing patches for
Nagios, few of the addons that exist today would still work without
major surgery, and Nagios would have been bloated beyond belief.

Some patches get accepted immediately. Some get deferred until the
next major release because they break the API's that broker modules
rely on. Some patches get accepted after a couple of rounds of review
and polish, and some patches get dropped on the floor because they
add something that is highly complex and useful only to some very
few people, or they solve a problem for which there is a very easy
different way to solve the same thing that doesn't involve adding
complexity to the core. Some also have been dropped because they
were downright crap. I tend to not remember who was responsible for
a particular patch, but if the content of the patch is mentioned I
will usually remember what I thought of it. Very engineerish, imo.

> 
>>> Shinken is already proofing what's possible, let's welcome another
>>> competitor in the game :)
>>>
>>
>> Yes. And no. Shinken is incompatible with all of Nagios' current
>> broker modules. Icinga have broken the ABI compatibility, but not to
>> the same extent. Shinken has some very neat ideas (and some not so
>> neat ones too). Like all good engineers, I'll happily borrow the
>> good ones and let the bad ones go hang.
>>
> 
> That's not the goal. We want to keep the compatibility.
> 
> We do not want war. We do not want to split between all projects "Nagios (R)
> ".
> We just want to bring new thinking and help the project without breaking
> your
> organization. We hope you understand us.
> 

Sure do. So let's work together. Me, Ton and Ethan just had a meeting
about an hour ago where we decided on some features that we want to
implement in Nagios that, according to ideas.nagios.org and the Nagios
bugtracker at tracker.nagios.org matches quite closely what the users
want.

I'll be sending out an email tomorrow afternoon, crossposting to
nagios-users and nagios-devel (actually, it'll be several emails),
requesting help in certain areas that we've decided to improve on
in the very near future. I've also committed to make these changes
my self, though I'd prefer to share the work with the rest of the
community. Matthieu Kermagoret, among others, would be a valuable
asset in that, as he's proven more than once that he's not only a
competent coder but also very pleasant to work with.

Feel free to pick up one of the tasks we've decided to do from
those emails, either for Centreon Engine (from where we can backport
it to Nagios if it plans out the way I expect it will), or as patches
to Nagios. Or perhaps both. Either way works for me.

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

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null