Finally, we get to see the elusive Ethan on the mailing list.
Ethan Galstad wrote:
> Okay, there have been a number of messages on the list over the past
> few days, relating to Nagios 2.0 development (or lack thereof), that
> need to be addressed.
>
> First, this project does not rule my life. I imagine the plugin
> developers feel the same about their involvement, though I can't
> speak for them. This project is something we work on in our spare
> time. We don't work at this full time and we don't get paychecks
> from Nagios, Inc. We all have day jobs and, believe me, we don't
> rush home after a full day of work and plop ourselves back down at a
> computer to eagerly apply all the latest patches so we can get a warm
> fuzzy feeling inside.
>
We all understand that, and I'm sure many of us has similar problems.
What those of us that have discussed this matter feel is that there
should be some means by which we can assist you to speed up development
by some more effective means than posting patches to the mailing list.
More on that below.
> Development on this project has its ups and downs, its slow periods
> and its frenetic periods. This is a slower time as far as
> development is concerned. Please realize that without slowing down
> occassionally, we'd all go crazy, end up hating this project, and
> eventually abandon it altogether. Amazingly, this project has
> managed to survive and thrive over the past 5+ years.
>
It is an excellent program. Excellence has a way of surviving.
> As far as patches are concerned, yes there is a bit of a backlog.
> That's just the way I've had to juggle things lately. Every so often
> I'll go through and apply some of the backlogged patches. Some, not
> all. I don't always think all the patches have merit. Some patches
> I sit on and think about for months before I decide whether or not
> they should be incorporated.
Which is your right as the founding father.
> Those that I do commit are often
> rewritten or mangled before doing so. I rarely, *rarely*, ever apply
> patches to CVS verbatim. Sometimes I edit for coding style,
> othertimes its to change to patch so it doesn't break things
> elsewhere. I always manually review the patches that come in, so I
> can completely understand what they're doing and what they'll affect.
> As such, it doesn't matter to me if different developers submit
> conflicting patches or patches against a slightly older version of
> the code. I can manage that just fine.
>
Someone (Wayne, I think) suggested you give a couple of devoted
patch-submitters 'official tester and reviewer' status. That should let
you do less work per patch, since testing, coding style and such could
be managed by your reviewers. It would also increase the understanding
of the inner logic for the reviewers, which is never a bad thing.
> As far as giving additional developers CVS write access, I'm not at
> that point yet. After 2.0 or 3.0 I may very well decide to leave
> this project for good and hand over the reins to others. At that
> point, you can all go nuts and do whatever the new maintainers allow.
> For the time being, however, patches for the core program still need
> to go through me. If you're not happy with that, you can always:
>
> 1. Run 1.x and not 2.0 alpha code in your production environment
> 2. Keep bugging me until I commit the patch to CVS
> 3. Maintain a separate repository with your own patches (a mini-fork)
> 4. Fully fork the code into another project
>
#2 is hard to do when there are no responses to the mailing-list that
maintainers have even received the patch or are aware of the problem.
Re-posting the same issue several times is bad form. Pestering is very
rude, and should we send patches anywhere else than nagios-devel then
the list description on sourceforge is somewhat askew.
I suggested #3 to a couple of fellow maintainers. It was intended to
hold proven and tested bugfixes only. No extensions or add-ons.
I have done #4 for the plugins. So far I've fixed numerous bugs, made
several optimizations, moved most of the
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]