Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST

From: Steve Valiunas <[email-masked]>
Date: Wed, 13 Oct 1999 16:55:57 +0000

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 <[email-masked]> on 10/13/99 08:23:40 AM

Please respond to [email-masked]

Sent by:  Jeff Mcadams <[email-masked]>

To:   [email-masked]
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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 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 "[email-masked]"
 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.

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 13 Oct 1999 17:40:00 +0000

>  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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Ed <[email-masked]>
Date: Wed, 13 Oct 1999 18:13:54 +0000

<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 <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 13, 1999 11:35 AM
Subject: Re: (usr-tc) RE: (USR-TC) RADIUS QUEST

-

-

---

From: [email-masked]
Date: Wed, 13 Oct 1999 18:19:58 +0000

> >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
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Charles Sprickman <[email-masked]>
Date: Wed, 13 Oct 1999 18:44:07 +0000

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

-

---

From: Brian <[email-masked]>
Date: Thu, 14 Oct 1999 05:48:15 +0000

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

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

> know...talk to my sales rep...I already have...he's very aware of our

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.

> Basically, yeah...but better a rehash of things than no communication at

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-