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.

Ok, here is an idea. At least post on Totalservice what ER codes are available, what they are supposed to fix. This way we know the option exists. Another plus would be "fill out this form before downloading the code". Then you all could spam our mailboxes and ask us to evaluate the code........a little automation, good for us, good for you, you don't have to pay those expensive tech support people just to hand us the ER code, you get your data, and we get our code. Brian On Tue, 12 Oct 1999, Todd Keister wrote:

Jeff:

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.

Once again: >This is done so that we can document the use of these special codes to >see if the code fixes the specific issue it was designed to address, AND also >to see if the new fix for one issue causes issues with any other >processes in the code or product.

If we were to just release code "willy nilly" and not track what we've done, it would be of no use to anyone, and we would be breaking many more things than we fix.

ER code is "special issue" code that addresses one speicific problem, and it is not feasible to stress check this code for all possible issues in all possible configurations. A specific ER code may have a known issue with another process - and that will be fixed before an ER is promoted to a Service Release. In the meanwhile customers who desperately need one item fixed, and who can "make due" while any other errors are resolved - can do just that - they can get the fix that they need - and they can get it NOW (which is the whole point of this process).

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.

Todd ;-}

Jeff Mcadams <jeffm@iglou.com> on 10/12/99 12:12:31 PM

Please respond to usr-tc@lists.xmission.com

Sent by: Jeff Mcadams <jeffm@iglou.com>

To: usr-tc@lists.xmission.com cc: (Todd Keister/MW/US/3Com) Subject: Re: (usr-tc) 2.0.60 HDM Code

Thus spake Todd Keister

...

ER or Engineering Release Code is only available by calling to Tech Support, and then WE (Tech Support) must get permission to release the code.

Good grief, its getting worse. What's next? Are we going to have to get a note from our mother's to use ER code? Blech.

...

This is done so that we can document the use of these special codes to see if the fix the specific issue they are supposed address, and also to see if the new fix for one issue causes issues with any other processes in the code or product.

Is it at all possible that 3Com could ever *eliminate* beaurocracy in their processes rather than constantly adding layer upon layer of it?

...

I hope this helps.

Unfortunately, no, I doubt it really does. :/

Does anyone in upper management at 3Com listen to what we're saying? I sometimes get the distinct impression that they really don't give a crap what we feel. I guess that is progress though...we do have *some* people at 3Com listening to us now...even if they aren't the people making decisions on most of these things.

Jeff "getting frustrated with 3Com idiocy again" McAdams

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

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

----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - 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.