YEAH finally something good in this thread!!! "Ah well. We live and we learn. Now it's time for me to learn how much wine I can drink on a friday night without passing out. I'm looking forward to that particular experiment. Cheerios :)"
Join winehq for a drink and a wine wow.exe maybe ?! :P Over and out! On Fri, 2011-06-10 at 14:48 +0200, Andreas Ericsson wrote: > On 06/10/2011 02:31 PM, Michael Friedrich wrote: > > -------- Original Message -------- Subject: Re: [Nagios-users] IPv6 > > support From: Andreas Ericsson <a...@op5.se> To: Nagios Users List > > <nagios-users@lists.sourceforge.net> Date: 2011-06-10 14:09 > >> > >> So give _address6 official status *in the ui*. Or make a config > >> item that lets users specify which custom variables to show in the > >> UI. Or show all of them by default. That's a change that actually > >> makes sense, would have been far less intrusive and would have made > >> very nearly everyone happy (especially the "configure which you > >> want to see", with a general switch to show all and then > >> include/exclude parameters to filter passwords and whatnot out of > >> the UI). Wasn't that the real reason behind the patches in the > >> first place? That's at least the only real unique benefit from this > >> over using custom vars. > >> > >> The problem here is actually laziness and possibly poor > >> maintenance. When presented with the patch, you need to ask the > >> submitter; "What purpose does this patch serve and why is it so > >> generally important that we have to break the ABI?" Given some > >> prodding, you would have found out that the user really just wants > >> to see a special custom variable in the web-interface. Achieving > >> that is basically peanuts, given half a day and a junior coder > >> fresh out of kindergarten, so it's quite likely the submitter could > >> have been persuaded to rewrite the patch like that so it would have > >> been easy to maintain it. It would also have made it acceptable in > >> the Nagios core and would have made life easier for those broker > >> module authors that actually care about supporting Icinga and for > >> the users that use modules with it. > >> > >> That turned a bit harsh there. Sorry about that. > > > > conclusion - you won't accept such patches, > > I won't accept patches that break things when there are easier ways > to achieve what the user desires that doesn't break things. > > > i can live with the extra > > work they will cause. even with addons staying compatible with icinga > > but not supprting the address6 field. everything else still remains > > compatible and tested. but that's not the point within nagios related > > stuff. there are other nagios patches pending, still breaking the abi > > (see some of opsviews patches and those from nagios-devel) which will > > make a change happen somewhere in the future. so maybe after a while > > users demand (even those from your customers), and it will hit nagios > > too. until then, let's just ask people out there what they really > > want and how *they* would achieve that. either live with it, patch it > > or even pay for it. > > > > Yup. That's what major releases are for. I guess I'm just a bit whiny > because I'd hoped Icinga would stay "compatible with Nagios in all > possible ways" as was promised from the beginning. > > Ah well. We live and we learn. Now it's time for me to learn how much > wine I can drink on a friday night without passing out. I'm looking > forward to that particular experiment. Cheerios :) >
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________ Nagios-users mailing list Nagios-users@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
