Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
The poor horse isn't even flinching anymore, but... We only perform limited in-house testing on ERs so they can go out quickly-( we don't run them through our internal testing group) so we try to be careful about their distribution. When I make an ER available I want to have accurate contact info for the customer so I can get ahold of them if something nasty shows up with it at a customer site. If after a number of days several users have indicated that it has fixed their issue and it warrants posting, it will become a candidate for being made available on totalservice for download as a ServiceRelease. It's a trade off- There's an extra step involved for you (and for the call center), but there's less liklyhood of an ER causing problems for someone because a problem was found and they didn't know. This was probably just a rehash of what Todd said the other day... Steve Jeff Mcadams <jeffm@iglou.com> on 10/13/99 08:23:40 AM Please respond to usr-tc@lists.xmission.com Sent by: Jeff Mcadams <jeffm@iglou.com> To: usr-tc@lists.xmission.com cc: (Steve Valiunas/MW/US/3Com) Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST Thus spake Steve Valiunas
Do you mean 6.09 ? If so, what about 6.08 ?
It's available in an Engineering Release, so you'll have to call tech support. (I know- another example of excess bureaucracy <g>).
Heh...I really don't mind calling tech support for ER's, it just kinda annoyed me that tech support now has to go get permission from someone else to give them out. :) And even that doesn't *terribly* bother me...at least not on its own...its just a single fairly small example of the larger problem. :) -- 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. - 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.
Thus spake Steve Valiunas
The poor horse isn't even flinching anymore, but... We only perform limited in-house testing on ERs so they can go out quickly-( we don't run them through our internal testing group) so we try to be careful about their distribution. When I make an ER available I want to have accurate contact info for the customer so I can get ahold of them if something nasty shows up with it at a customer site. If after a number of days several users have indicated that it has fixed their issue and it warrants posting, it will become a candidate for being made available on totalservice for download as a ServiceRelease.
Here's the crux of the issue. 3Com is basically adding more layers of beaurocracy to try to *help* communication with their customers. I'm sorry, but that's just going about it the wrong way. Linux kernel 2.3.21 *certainly* isn't extensively tested, and its publicly available. Cisco version 12.0 IOS certainly had plenty of bugs in it when it was released...if you make stuff available to your customers, and strip out all these layers of crap that we have to go through, you *will* get more feedback from customers and foster better communication between 3Com and us. As it is, all you're doing is forcing people to switch to informal support methods (and eschewing support contracts...that its gotten to that point is a *SERIOUS* indictment of 3Com) because we *can't* get the support we need and the communication between 3Com and us concerning these releases...so then 3Com, in an effort to fix this, just goes and adds yet another layer, and makes it that much harder to get significant communication going. You know...I've been avoiding "warezing" the 3Com releases in an effort to give 3Com the benefit of the doubt...I'm just about -><- far away from changing that attitude because 3Com keeps screwing their customers over with respect to this and other things. I've tried my best to work within the system for 3Com, and I'm really running out of patience. I've talked to sales reps, SE's, even product managers, and my (dare I speak for other list members?) concerns have been, basically, blown off. I'm saying, controlling the ER releases that closely is a "Bad Thing[tm]"...and my thought isn't even (apparently) being considered in the slightest. Instead, the mantra is repeated that they're not fully tested. Bully...they're not fully tested...I don't care! Put the releases out there...tell us what you've changed in each, let *us* figure out whether its a good idea to use that code in our situation or not. To be brutally honest, 3Com hasn't even shown that they can consistently provide even basic tech support on this equipment (with the exception of a few individuals...most of which, from what I can see, are on this list), let *alone* know what the best thing to do in a real live production environment is.
It's a trade off- There's an extra step involved for you (and for the call center), but there's less liklyhood of an ER causing problems for someone because a problem was found and they didn't know.
Again...this just points to the need for *more* communication and less insulation of the customer, not the need to add "yet another" layer in process. Make bug tracking databases publically available. (rework your release numbering system so that it actually uses some semblance of logic). Make development work more transparent. Shoot...if you need a bug tracking product to do this...just go to www.mozilla.org and grab bugzilla...its open source, doesn't cost a penny...works great, and is easily set up to allow public access to it. As I said in a previous post...if such major issues as have been mentioned here in the past couple of days are still outstanding after such a lengthy period of time as many of them have still been outstanding...there's something intrensically wrong with the system and putting more layers on the system isn't the way to fix it. Maybe I should take a dose of my own medicine...I've been working from the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to come at it from the other direction. Maybe I/we need to start from the top down...since my current actions seems to be ineffective, perhaps my system is intrensically broken and I should be emailing Eric Benhamou and Bruce Claflin and the like...maybe if I can get them to understand, then some substantive changes will take place. As I said the other day, 3Com's corporate reaction seems to be to put *more* layers in the functioning when they see that there's a problem in the process...they seem to do this without thinking that the solution might really be to *remove* some. Has anyone in 3Com even really *considered* the idea that it might be better to have wide distribution of these releases rather than trying to limit it? Look at the thread that was going on regarding problems with OSPF. I didn't know the full extent of the problem, but someone else did. If I had been the only one with that code, 3Com wouldn't have really known what was wrong there. Cut out the layers of beaurocracy and I'd be willing to be that you'll get better response from customers, better communication, fewer complaints, and better feedback (without having to track and initiate that feedback yourself) from customers because they'll *want* to help you, and it won't be an arduous task for us. I'm a generally helpful guy, but I tend to not provide feedback to 3Com because I know its going to end up being a several day ordeal and may not achieve any results. This is all a result of the beaurocracy involved. Strip it out and, at least speaking for myself, you'll get considerably *more* feedback. As with all of my posts...I feel I own my words, so feel free, (indeed, please do!) forward my posts on up the chain of command, or on to anyone that might be able to benefit. My phone number is in my .sig, my extension is 1153, I'm definitely not trying to do a hit and run complaint here. :) I also know that the people on this list (for the most part from what I've seen) are not in a position to do anything about these things directly. Believe me, I'm not trying to cause your life to be miserable...I just don't know any other way to get feedback to 3Com about these things. Point me in a better direction and I'll go there (I know...talk to my sales rep...I already have...he's very aware of our issues here).
This was probably just a rehash of what Todd said the other day...
Basically, yeah...but better a rehash of things than no communication at all. :) -- 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.
<Claps> Jeff you have pretty much completely summed up 3com support and technical problems. Everyone should read your post. I have said for months how much better it was as USR. Yes it had it's faults but it was much better none the less. They LISTENED and tried to work to a solution. We never had so many outstanding issues and that was 2 years ago. You would think by now it would be close to perfected... it's not however and this is because it is one way communication the other side isn't listening. They dictate the rules and regs to us the customers and give the attitude like it or leave it... we are close to leaving it. Way too much beaurocracy to wade through at 3com. We have spent upwards of $1,000,000 on 3com equipment and it doesn't seem to matter. Our word has little value... Although I must give credit George Ebert has tried to help and some high level guys like Krishnan and Mike Wronski do an awesome job but they too are caught up in the muck of beaurocracy. You can't get to these guys without going through red tape... and they cannot personally deal with all customers. Ed ----- Original Message ----- From: Jeff Mcadams <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Wednesday, October 13, 1999 11:35 AM Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST Thus spake Steve Valiunas
The poor horse isn't even flinching anymore, but... We only perform limited in-house testing on ERs so they can go out quickly-( we don't run them through our internal testing group) so we try to be careful about their distribution. When I make an ER available I want to have accurate contact info for the customer so I can get ahold of them if something nasty shows up with it at a customer site. If after a number of days several users have indicated that it has fixed their issue and it warrants posting, it will become a candidate for being made available on totalservice for download as a ServiceRelease.
Here's the crux of the issue. 3Com is basically adding more layers of beaurocracy to try to *help* communication with their customers. I'm sorry, but that's just going about it the wrong way. Linux kernel 2.3.21 *certainly* isn't extensively tested, and its publicly available. Cisco version 12.0 IOS certainly had plenty of bugs in it when it was released...if you make stuff available to your customers, and strip out all these layers of crap that we have to go through, you *will* get more feedback from customers and foster better communication between 3Com and us. As it is, all you're doing is forcing people to switch to informal support methods (and eschewing support contracts...that its gotten to that point is a *SERIOUS* indictment of 3Com) because we *can't* get the support we need and the communication between 3Com and us concerning these releases...so then 3Com, in an effort to fix this, just goes and adds yet another layer, and makes it that much harder to get significant communication going. You know...I've been avoiding "warezing" the 3Com releases in an effort to give 3Com the benefit of the doubt...I'm just about -><- far away from changing that attitude because 3Com keeps screwing their customers over with respect to this and other things. I've tried my best to work within the system for 3Com, and I'm really running out of patience. I've talked to sales reps, SE's, even product managers, and my (dare I speak for other list members?) concerns have been, basically, blown off. I'm saying, controlling the ER releases that closely is a "Bad Thing[tm]"...and my thought isn't even (apparently) being considered in the slightest. Instead, the mantra is repeated that they're not fully tested. Bully...they're not fully tested...I don't care! Put the releases out there...tell us what you've changed in each, let *us* figure out whether its a good idea to use that code in our situation or not. To be brutally honest, 3Com hasn't even shown that they can consistently provide even basic tech support on this equipment (with the exception of a few individuals...most of which, from what I can see, are on this list), let *alone* know what the best thing to do in a real live production environment is.
It's a trade off- There's an extra step involved for you (and for the call center), but there's less liklyhood of an ER causing problems for someone because a problem was found and they didn't know.
Again...this just points to the need for *more* communication and less insulation of the customer, not the need to add "yet another" layer in process. Make bug tracking databases publically available. (rework your release numbering system so that it actually uses some semblance of logic). Make development work more transparent. Shoot...if you need a bug tracking product to do this...just go to www.mozilla.org and grab bugzilla...its open source, doesn't cost a penny...works great, and is easily set up to allow public access to it. As I said in a previous post...if such major issues as have been mentioned here in the past couple of days are still outstanding after such a lengthy period of time as many of them have still been outstanding...there's something intrensically wrong with the system and putting more layers on the system isn't the way to fix it. Maybe I should take a dose of my own medicine...I've been working from the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to come at it from the other direction. Maybe I/we need to start from the top down...since my current actions seems to be ineffective, perhaps my system is intrensically broken and I should be emailing Eric Benhamou and Bruce Claflin and the like...maybe if I can get them to understand, then some substantive changes will take place. As I said the other day, 3Com's corporate reaction seems to be to put *more* layers in the functioning when they see that there's a problem in the process...they seem to do this without thinking that the solution might really be to *remove* some. Has anyone in 3Com even really *considered* the idea that it might be better to have wide distribution of these releases rather than trying to limit it? Look at the thread that was going on regarding problems with OSPF. I didn't know the full extent of the problem, but someone else did. If I had been the only one with that code, 3Com wouldn't have really known what was wrong there. Cut out the layers of beaurocracy and I'd be willing to be that you'll get better response from customers, better communication, fewer complaints, and better feedback (without having to track and initiate that feedback yourself) from customers because they'll *want* to help you, and it won't be an arduous task for us. I'm a generally helpful guy, but I tend to not provide feedback to 3Com because I know its going to end up being a several day ordeal and may not achieve any results. This is all a result of the beaurocracy involved. Strip it out and, at least speaking for myself, you'll get considerably *more* feedback. As with all of my posts...I feel I own my words, so feel free, (indeed, please do!) forward my posts on up the chain of command, or on to anyone that might be able to benefit. My phone number is in my .sig, my extension is 1153, I'm definitely not trying to do a hit and run complaint here. :) I also know that the people on this list (for the most part from what I've seen) are not in a position to do anything about these things directly. Believe me, I'm not trying to cause your life to be miserable...I just don't know any other way to get feedback to 3Com about these things. Point me in a better direction and I'll go there (I know...talk to my sales rep...I already have...he's very aware of our issues here).
This was probably just a rehash of what Todd said the other day...
Basically, yeah...but better a rehash of things than no communication at all. :) -- 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. - 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.
Thus spake Steve Valiunas
The poor horse isn't even flinching anymore, but... We only perform limited in-house testing on ERs so they can go out quickly-( we don't run them through our internal testing group) so we try to be careful about their distribution. When I make an ER available I want to have accurate contact info for the customer so I can get ahold of them if something nasty shows up with it at a customer site. If after a number of days several users have indicated that it has fixed their issue and it warrants posting, it will become a candidate for being made available on totalservice for download as a ServiceRelease.
This would seem to be a contradiction of what most of us call BETA testing. If you only release ER code to a few select site.. then how can you verify your code base will work when put out for general consumption? Having two/three beta sites is not a through test.. it's more like an attempt to beta test. I would say release ER to all, then when customers call support (or an engineer) about problems with the ER they can talk to the person involved with the code... not a tech-bot in front of some database without a clue. Most people will not just install an ER unless they know they need it. If they do and it blows up.. then hey, it's a beta and you get what you get. 3Com's attempt to protect us from ourselves is not going over well. BTW.. what about a LINUX port of TCM!!!!!!!! Who can I mailbomb concerning this? Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 - 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.
Shoot...if you need a bug tracking product to do this...just go to www.mozilla.org and grab bugzilla...its open source, doesn't cost a penny...works great, and is easily set up to allow public access to it.
*definitly*. Redhat.com uses this. Bugzilla rocks the casba, and its free too. I would love to go thru Bugzilla on Total Control, so i can see what others are reporting.......unbiased, unedited. I think alot of people find bugs but because its so HARD to report a bug to 3com, it doesn't happen as often as it should. But if a public bugzilla existed, i think people like myself and others would just love to populate the hell out of it and then 3com would get 10 fold the input they are probably getting now. But its like a two edged sword. I imagine 3com woudln't want something like this, because they would be too concerned about potential customers seeing all the problems reported, or competition taking notes on 3com's weaknesses.........the result is a coverup, and the slowing of gears. Honesty would enable more free communication, and would allow you all to produce a much better product, I know it. Instead of hording the ER code, and forcing people to call your support people, I would say put it on the site, force the people downloading it to fill out a form (you really don't need to do that either, since you all know which account downloaded the code). then email that person once per week a survey asking about how the code is coming, and ask for feedback. You would get 10x the people using the code then, and even if only half the people responded, you would get more feedback.
Maybe I should take a dose of my own medicine...I've been working from the bottom up (tech support, sales reps, SE's, etc.), maybe I/we need to come at it from the other direction. Maybe I/we need to start from the top down...since my current actions seems to be ineffective, perhaps my system is intrensically broken and I should be emailing Eric Benhamou and Bruce Claflin and the like...maybe if I can get them to understand, then some substantive changes will take place.
very much the idea behind the unresolved issues list, which was btw, actually presented to the CEO of 3com.
Cut out the layers of beaurocracy and I'd be willing to be that you'll get better response from customers, better communication, fewer complaints, and better feedback (without having to track and initiate that feedback yourself) from customers because they'll *want* to help you, and it won't be an arduous task for us. I'm a generally helpful
right. You cant get ER code unless you call tech support............But I don't want to call tech support. Tech support doesn't know routing protocols, has never configured complex radius setups, I have no intrest in level 1 support.
I also know that the people on this list (for the most part from what I've seen) are not in a position to do anything about these things directly. Believe me, I'm not trying to cause your life to be miserable...I just don't know any other way to get feedback to 3Com about these things. Point me in a better direction and I'll go there (I know...talk to my sales rep...I already have...he's very aware of our issues here).
I agree. I think 3com engineers are really great and bright people. It must be hard to work for a company as large as 3com, its not like the engineers call all the shots. Its not like the engineers are going to come out and say, whether they believe it or not, "the company i work for has crappy procedures, blah blah".......we can't expect that, we can't expect them to tell us what to do to help them. We can only call them like we seem them, and go from there. It looks like "corporate" gridlock type stuff and so maybe some streamlining of processes is in order.
This was probably just a rehash of what Todd said the other day...
Basically, yeah...but better a rehash of things than no communication at all. :) -- 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.
----------------------------------------------------- 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.
On Wed, 13 Oct 1999, Steve Valiunas wrote:
The poor horse isn't even flinching anymore, but... We only perform limited in-house testing on ERs so they can go out quickly-( we don't run them through our internal testing group) so we try to be careful about their distribution.
Great, so as a 'software only' contract customer, I can't get ER releases. Seems like the concern might be more about selling full-blown support contracts in a panic/"I need this fix now" situation than organization. Just call it "Beta", have some lawyers put some fancy language that re-states what beta software is and make it available to anyone with software access. Hell, make me fill out a contract form, harass me by email about how it's working... It seems like you'd be better off getting beta code tested by a wider user base, no? Charles
When I make an ER available I want to have accurate contact info for the customer so I can get ahold of them if something nasty shows up with it at a customer site. If after a number of days several users have indicated that it has fixed their issue and it warrants posting, it will become a candidate for being made available on totalservice for download as a ServiceRelease. It's a trade off- There's an extra step involved for you (and for the call center), but there's less liklyhood of an ER causing problems for someone because a problem was found and they didn't know. This was probably just a rehash of what Todd said the other day...
Steve
Jeff Mcadams <jeffm@iglou.com> on 10/13/99 08:23:40 AM
Please respond to usr-tc@lists.xmission.com
Sent by: Jeff Mcadams <jeffm@iglou.com>
To: usr-tc@lists.xmission.com cc: (Steve Valiunas/MW/US/3Com) Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
Thus spake Steve Valiunas
Do you mean 6.09 ? If so, what about 6.08 ?
It's available in an Engineering Release, so you'll have to call tech support. (I know- another example of excess bureaucracy <g>).
Heh...I really don't mind calling tech support for ER's, it just kinda annoyed me that tech support now has to go get permission from someone else to give them out. :) And even that doesn't *terribly* bother me...at least not on its own...its just a single fairly small example of the larger problem. :) -- 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.
- 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.
participants (6)
-
Brian -
Charles Sprickman -
Ed -
farber＠admin.f-tech.net -
Jeff Mcadams -
Steve Valiunas