Thus spake Todd Keister
I think you have missed the point. We don't just want to "Throw Code" at given issues. It may seem like extra steps, and sometimes it is laborious to follow these procedures, but in business, law, and especially in science, if you don't have clearly documented data trails, and reproducible results - then you have not accomplished a darn thing.
No...I didn't miss the point...I understand where you're coming from...*however*. This seems (from my perspective at least) to be a reaction to as you put it "release[ing] code 'willy nilly'". IMO, the fix isn't to put yet another layer of beaurocracy down to track it, the real fix is to have tech support be good enough at what they do, and enough information available to them (I think this second part is the killer) that they can more intelligently use ER code releases as trouble-shooting tools. This is, as you say, intended to provide a fix for those that need it, and feedback on those fixes before they're put into an SR, but putting yet another layer of beaurocracy on this just puts that much more difficulty on us, the customers actually *using* this equipment and code, from being able to make the most from it. Basically, 3Com just added yet one more layer between us, the customers, and the development process of the code, yet one more layer that insulates our feedback from the actual people making decisions about the development of the product(s). Please don't get me wrong, Todd...I'm certainly not trying to take a shot at you, or any other tech support folks. I'm taking a shot at 3Com overall, who's (corporate) reaction to things seems to be to add more beaurocracy to things where there are problems in an effort to fix them...when...at the core, at least a major component of the problems are that there's entirely too much beaurocracy already, and customers are already entirely too isolated from the development effort.
I hope this clarifies my prior statements, and I hope this helps to clarify what could on the surface seem to be another "Stupid Policy" that is actually just a part of the Scientific Method.
Oh, I'm very clear on 3Com's thinking here...some of it even makes sense...that doesn't mean its not "another 'Stupid Policy'" though. ;) My other question still stands though...and this may be one that you, Todd, may not be able to answer, and I can understand that...but does upper management at 3Com really take us seriously? We (the users of tc equipment on this list) have constently, over the years, alerted 3Com to problem after problem, most of which were ignored until they reached epic proportions, resulted in various people threatening lawsuits, resulted in cascades of complaints from the users both on this list and in the totalservice fora. These problems are, almost invariably, not acted upon until it reached a crisis situation at 3Com and consequently took much greater effort to fix than it would have if addressed when it was first mentioned on the list. I will say that 3Com has seemed to become more responsive to actual implementation problems...ie, actually fixing bugs in code...while at the same time making it, in many cases, actually harder for the customer to get ahold of the code that makes the fixes. Security issues are still dealt with in much too slow of a manner. I reported "Yet Another(tm)" SNMP bug in the Total Control platform almost 3 weeks ago now (not yet made public...will be soon), and still haven't gotten any feedback about it. 3 weeks is *way* too long for a bug like this to exist in a known state. There should be an SR release for security issues made immediately...take the last released code...start from that base, and develop a fix for the security hole independently of your other fixes...3Com seems to have a *very* lax attitude concerning security fixes. We've been complaining about support contracts for years now...any progress there? None that I've heard of...indeed, this too has gone in the wrong direction. Used to be that you had to have equal support coverage on each card in a chassis, then you had to have it on each chassis in a location, now you have to have it on all your chassis in all your locations. This should be going the other direction! There are easily accessible serial numbers on each card (shoot, you can even pull them up in a nice clean spreadsheet format via TCM!), why not have support contracts be done on a per-card basis? Again...we here at IgLou specifically have been asking for exactly this for over a year, and the only response we have gotten from *anyone* (other than our sales rep, who agrees with us) has been a call to give us the pricing as it currently exists, they were *totally* unwilling to even *consider* that their support contract structure was sub-optimal. 3Com has *YET* to deal with the NETServer to HiPer Arc upgrade issue. They still are foisting essentially a Bait and Switch tactic on their long-time customers that have NETServer cards. 3Com has known about issues in the NETServer code base and refuses to take necessary and available steps to fix them (either replace the cards with Arcs, or back-port Pilgrim to the older cards, either would be an acceptable solution, 3Com refuses to do either), and now I've heard reports that 3Com tech support folks either don't know about this situation (broken MPIP in NETServers specifically) or don't acknowledge it as a known problem. Yeesh. I answered a post in the totalservice *.totalcontrol newsgroup just the other day telling someone that they were SOL regarding this issue because 3Com refused to stand by their product. These are the types of things that illustrate what I'm talking about...3Com would rather add more beaurocracy and hierarchy to things to try to fix it rather than step back, realize that the beaurocracy and hierarchy is largely what's standing in their way from figuring out what the real fixes are. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.