Re: [Nagios-devel] Nagios 2.0!
Posted: Thu Oct 21, 2004 12:30 am
Ethan,
Nagios is great. Hell, it's beyond great. The day you decide to leave
this project, will be a black day in the history of Nagios in particular
and Open Source in general. Thanks for all your efforts. I am amongst
the ones that truely value them!
To Andreas: GG NO RE TNX KK (I'm sorry for the juvenile vocab, I happen
to play the occasional game of Warcraft every now and then). Please fork
Nagios into your own project and start up a mailing list of your own. It
would do Nagios the world of good.
Keep up the good work Ethan!
Tom
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.
>
>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.
>
>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. 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.
>
>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
>
>If you choose option #3, you might very well run into the problem
>where you have a highly customized version of Nagios which is no
>longer stock. As I mentioned previously, I don't accept all patches
>and I rewrite/mangle many of them before committing them to CVS. As
>long as you're able to keep on top of the Nagios CVS commits when
>they occur, you can manage it, but it'll keep you busy. Some big
>organizations do something like this, so they can have a customized
>version of Nagios in house. Of course, they have some extra work to
>do when Nagios CVS commits are made and when new versions are
>released.
>
>If you want to fork the project, please feel free to do so. Many of
>you are well qualified to do this, and I am certain that your project
>will succeed, so long as you can dedicate the time and energy to
>maintain the project over a number of versions and years. Just don't
>name
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Nagios is great. Hell, it's beyond great. The day you decide to leave
this project, will be a black day in the history of Nagios in particular
and Open Source in general. Thanks for all your efforts. I am amongst
the ones that truely value them!
To Andreas: GG NO RE TNX KK (I'm sorry for the juvenile vocab, I happen
to play the occasional game of Warcraft every now and then). Please fork
Nagios into your own project and start up a mailing list of your own. It
would do Nagios the world of good.
Keep up the good work Ethan!
Tom
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.
>
>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.
>
>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. 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.
>
>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
>
>If you choose option #3, you might very well run into the problem
>where you have a highly customized version of Nagios which is no
>longer stock. As I mentioned previously, I don't accept all patches
>and I rewrite/mangle many of them before committing them to CVS. As
>long as you're able to keep on top of the Nagios CVS commits when
>they occur, you can manage it, but it'll keep you busy. Some big
>organizations do something like this, so they can have a customized
>version of Nagios in house. Of course, they have some extra work to
>do when Nagios CVS commits are made and when new versions are
>released.
>
>If you want to fork the project, please feel free to do so. Many of
>you are well qualified to do this, and I am certain that your project
>will succeed, so long as you can dedicate the time and energy to
>maintain the project over a number of versions and years. Just don't
>name
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]