(In reply to Mark Hill from comment #78)
> (In reply to Sam Kottler from comment #75)
> > (In reply to Mark Hill from comment #74)
> > > (In reply to Sam Kottler from comment #69)
> > > > (In reply to Mark Hill from comment #65)
> > > > > This must be some kind of joke right? Are there serious considerations to
> > > > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > > > now after reading that last comment and associated blog article, I am
> > > > > outraged! And are we really worried that the new team writing the code for
> > > > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > > > fifth-grader could meet the standards the previous team set, It isn't
> > > > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > > > 
> > > > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > > > set" but you're not trying to be degrading...
> > > > 
> > > 
> > > Fair enough, that was a bit harsh, I let my emotions get the better of me
> > > and I apologize.
> > > 
> > > > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > > > or anything Nagios related (other than promoting Nagios XI on stack
> > > > overflow) I'm not sure I trust your opinion on this.
> > > > 
> > > 
> > > The sensitive nature of my work requires that I keep a low profile. (I even
> > > had to receive clearance to post here) So although you don't see my name
> > > publicly, several others who have commented here are familiar with my
> > > extensive nagios work. 
> > > 
> > > > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > > > assume that because of the changes that got everyone all upset we should
> > > > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > > > As other "community members" have already said, I do not want to deal with
> > > > > all of the dependency issues this creates, just because of a little pissing
> > > > > match. 
> > > > 
> > > > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > > > 
> > > 
> > > We have a massive nagios infrastructure built (and team dedicated to it). We
> > > rely heavily on the nagios-plugins rpm. We have scripts all over the place
> > > that use yum to install and update the plugins. And now by the sounds of it,
> > > we are going to have to touch each one of these if we want the
> > > nagios-plugins from the new team? Does that help clarify my concern?
> > 
> > It does, thanks. That being said it's just updating a bunch of package
> > names; there won't be any additional process. No paths will change if you
> > stick with the nagios-core-plugins package.
> > 
> 
> Yep, I understand. The work I am trying to avoid is going to be finding all
> of the locations where we need to update the package names.

If you're managing lots of machines across several networks you should probably use config management.

> 
> > > 
> > > > > 
> > > > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > > > head on this.
> > > 
> > > Again, I really appreciate your work on this Sam. I don't have a stake in
> > > this other than the time my team is going to have to spend fixing stuff if
> > > you decide to force us to go to 'nagios-core-plugins'. And my biggest
> > > concern is what if my team misses one? We are going to have mismatches
> > > across our various networks, and anything we have built on top of that will
> > > break. And yes, this would be easy to accomplish if are networks were not
> > > completely isolated from one another. Several of our network require
> > > out-of-band management, so again, I think you understand my concern. This
> > > just seems like a very unnecessary headache in the making.
> > 
> > Understood and I totally sympathize with you on that, but this wasn't really
> > my decision. You can talk with Nagios Enterprises about how they're making
> > the lives of their users more difficult - maybe they'll listen.
> 
> We have. We complained several times to them that issues my team was having
> with the plugins were not being addressed. Maybe those conversations are
> part of the reason for this? Anyway, I think you know where I would like to
> see this go, and I will go back to my quiet, peaceful cave and watch how
> this unfolds from there.
> 
> thanks again