patch: total macros

[Andreas Ericsson]

Wayne Mery wrote:
> On 10/19/2004 3:51 AM, Andreas Ericsson wrote:
> 
>> Matthew Kent wrote:
>>
>>> On Tue, 2004-10-19 at 00:16, Matthew Kent wrote:
>>>
>>>> Enclosed is a patch (against latest cvs) to add some more macros,
>>>> similar values to what tac.cgi displays, for use in notifications. They
>>>> are filtered appropriately for the permissions of the contact being
>>>> notified.
>>>
>>>
>>>
>>>
>>
>> Matthew, Ben, Titus; Would you be interested in helping me keep a 
>> publicly accessible CVS repository up to date with fixes and 
>> improvements in case we don't hear from Ethan about the status of all 
>> the recent patches and such?
>>
>> I'm not thinking about forking the main branch, but rather have some 
>> place to gather up the patches for easy testing and to keep people 
>> from doing the same work twice, while staying compatible with other 
>> patches.
>>
>>
>> Ethan; Can we please hear something from you about which patches 
>> you'll want to include and which ones you won't?  It would help a lot...
>>
> Andreas,
> 
> perhaps you've Bcced Ethan, but if not, you might want to e-mail him 
> directly.

I should indeed have done that, but I forgot. He gets a CC of this though.

> I don't think it will be easy to win him over to someone else 
> authorizing the CVS.

Karl DeBisschop has write-access, but he hasn't contributed to either 
nagios or nagiosplug in a very long time. Having at least one active 
user that can update the CVS with community contributed bugfixes/patches 
speeds up development immensely.

> However, a fallback position could be to approach it as mozilla works, 
> i.e. there are reviewers (and super reviewers) who approve the code and 
> it then gets kick upstairs for checkin - this way all the big mahaf 
> (sp?) doesn't have to check/worry so much about code quality and 
> architectural standards.
> 

Mozilla is a very large project with a great many active developers. I 
believe there is a group of people with CVS write access instead of just 
one who takes the project down with him in case of illness or inactivity.

The problem with Nagios devel rate is that its community is currently 
growing from small-ish to medium/large, with all the added user 
contribution activity it involves. It's also in alpha state, which means 
a lot of bugs of which quite a few are really easy to fix.
Historically, Nagios hasn't followed the open-source idiom of 'update 
small and release often', but with alpha releases this becomes a real 
burden for the users, which eventually might grow tired and abandon the 
project for something commercial which is fixed a bit more often.

> Thanks for taking up the banner on this issue.
> 

Someone has to. I work for a company that sells packaged versions of 
Nagios and support for the same. Currently, the patching and keeping 
patches in sync is a more burdensome task than it would be to simply 
fork the code and maintain our own branch.
Patches should be dropped with new releases (more often than not, 
anyways) or based on The Founding Father's decisions. Not adapted to fit 
10 other patches.
When a project reaches it's "critical patch level" it will, inevitably, 
fork.

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


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl