(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. > > > > > > > > > > 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