SV: Nagios 2.0 stable

[jeff vier]

On Wed, 2005-03-23 at 10:31 -0500, Sean Dilda wrote:
> >>I realise that my question is unclear. I'm refering to the fact that 2.0 still is in beta. 
> >>We are running v.1.2 currently and are interested in the v.2.0.
> >>I'm wondering if anyone has an idea of how much time it might take before 2.0 can go into a stable (non-beta) state.
> > To put it bluntly: Who Cares?
> Most professionals.
>
> > There are so many of us running it in production (I, myself, have been
> > doing so since "alpha"), isn't that good enough?
> Just because you walk the bleeding edge doesn't mean everyone else wants to.

Bleeding edge?  Please.

Best tool for the job.  I did my diligence running it in my skunkworks
environment, established what problems needed to be avoided (mostly,
embedded perl.  Notably, in the "stable" release, this is equally a
problem) and made allowances for that.

And if no one ever runs it In Real Life, no problems get found.  Not
having any bug reports doesn't mean it's stable.  It means it's unused
and no one knows.

> > There will always be bugs, no matter what you call it (alpha, beta, pr,
> > rc, gold, etc).
> > In my, and I'm sure many others', experience, super-pre-double-alpha
> > code from a nice community-supported project like this is still going to
> > have less bugs than anything similar from Microsoft no matter how many
> > "final" versions they have.
> > And if something major does come up, there's usually a fix/work-around
> > in a few hours or days, not weeks or months.
> I'm not opposed to using software that's still under development, but I 
> try to avoid it whenever possible in production environments.  If its as 
> good as you say it is, then maybe it shouldn't be called beta, but 
> that's an argument to be made with the developers, not the users.

It's one guy's decision who may or may not care what it's called.  Why
do you?

Test it (out of production) to your own satisfaction.

> For most projects, terms like 'alpha' and 'beta' have certain meanings 
> in regards to how stable/tested the code is and how likely it is to 
> change before final release.  And likewise, official releases tend to 
> not do things like drastically change the config layout as part of a 
> bugfix, whereas an alpha or beta might.

Oh?  As I said before, how is it that "stable" code from [some]
commercial companies have so many more problems than beta [and sometimes
alpha] code from the OSS community?

> You may have no problems with it, and that's great.  However, there are 
> people out there whose job performance is tied to how well stuff like 
> this operates.  As such, they tend to make the wise choice of waiting 
> for an official release before investing time setting up something and 
> risking having to completely change your setup in a couple of weeks.  To 
> many professionals, having an official (as opposed to beta) release is 
> an indication from the developers that this code is ready for prime time 
> and will have bugfixes that don't cause you to rework things.

So test it.
Are you saying you'd do a blind deployment because Ethan says "I think
it's fine"?

--boinger



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
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