[2633] in Release_7.7_team
Re: Please strongly consider backing out the zephyr servers
daemon@ATHENA.MIT.EDU (Bill Cattey)
Tue Mar 6 20:13:50 2001
Message-ID: <EudMh7tz0001N_g2hN@mit.edu>
Date: Wed, 7 Mar 2001 01:13:43 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
To: jis@MIT.EDU, Greg Hudson <ghudson@MIT.EDU>
CC: Garry Zacheiss <zacheiss@MIT.EDU>, azary@MIT.EDU,
Greg Hudson <ghudson@MIT.EDU>, John Hawkinson <jhawk@MIT.EDU>,
release-team@MIT.EDU, op@MIT.EDU, winzephyr-release@MIT.EDU
In-Reply-To: <200103070033.TAA30308@egyptian-gods.MIT.EDU>
Greg:
I think your analysis results in us having to work too hard and be too clever.
When we find unintended consequences of a change to a service, we should
undo the change first, asses the scope of the unintended consequences,
and then decide what to do next, even if it is to put the change right
back in.
I think we've too long worried that we won't be allowed to make changes
if we make mistakes. In conversation with Jeff, he re-affirmed to me
that, aside from taking too long to back out the change, that everything
else we did was right on target. He supports our need and desire to
make beneficial changes. It's just a matter of being explicit about
what the change is, and being prepared to back it out if there are
unintended consequences.
One could ask, "Does that mean we are to be held hostage by a single
customer who doesn't like some change we make?" The answer is,
"We are not being held hostage. We are being responsive. We get to
make a customer happy that we are taking them into account. We are
not required to leave the change out forever -- only to back it out and
negotiate AFTER the change is backed out."
This is the difference between a vendor that makes you feel bad and one
that makes you feel good. Most of the time we get all this stuff set
explicitly in advance, and don't have this situation to contend with.
-wdc
