[2635] in Release_7.7_team
Re: Please strongly consider backing out the zephyr servers
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Wed Mar 7 03:13:58 2001
Message-Id: <200103070813.DAA03442@riff-raff.mit.edu>
To: "Jeffrey I. Schiller" <jis@MIT.EDU>
cc: Garry Zacheiss <zacheiss@MIT.EDU>, "Susan S. Minai-Azary" <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: Your message of "Tue, 06 Mar 2001 18:43:41 EST."
<20010306184341.C1894@mit.edu>
Date: Wed, 07 Mar 2001 03:13:49 -0500
From: Garry Zacheiss <zacheiss@MIT.EDU>
>>Let's talk when we see each other in person.
I agree this would be a good thing, and would like it very much.
>> That the customer is a "tester" is besides the point. There is an
>> implied understanding with testers (generically, not just here at MIT)
>> that software being tested may have bugs. However this agreement does
>> not usually extend to "we can pull the service out from underneath you"
>> unless there is an agreement that states this. Of course customers are
>> not good agreement readers!
I'd like to preface my comments by stating that I too now
believe that backing out was the right decision. The fact that after
looking at the winzephyr source, we don't immediately understand what
the problem is indicates to me a subtle failure that makes backing out
the changes worthwhile, even if the problem in question is still a
client side failure.
I agree that we shouldn't go out of our way to break software
that we have opened up for testing. Software that is qualified as
"alpha" by the project manager of the group ostensibly responsible for
its development does seem like it should carry less of a support burden
than packages we have explicitly recommended.
My basic concern in this is twofold:
1.) That software may have "escaped", as opposed to being
"released", and we now have an unknown user base with
support expectations, when we have made no specific plans
for supporting them.
2.) That the label "unsupported" mean something when we apply it
to a product/service/etc.
In light of this, I would like to suggest this plan for
proceeding with the current situation:
1.) The zephyrd on erato, the test zephyr server, be
reverted to enforcing checksums, so that the winzephyr
developers may have an example of the code we'd like to
ultimately deploy to work against.
2.) To demonstrate that we take the security hole in zephyrd
seriously, we resolve to deploy the new zephyr code base two
weeks after a fixed release of winzephyr becomes available
for download, so long as this time doesn't occur during the
period of term between drop date and the end of finals.
Susan expressed a commitment to making sure the necessary
winzephyr development would take place in a timely manner
and Greg has volunteered to provide development assistance,
so I would propose a timeframe of the end of the month for
the release of the new winzephyr, with a corresponding
zephyrd upgrade in mid-April.
All of these dates are somewhat arbitrary on my part, and
open to negotiation. Do they seem reasonable?
3.) In the future, that the winzephyr developers have some
clients pointing at erato, the test zephyr server, and be
notified when changes to it are made, so that they may test
their software.
Reminding the MacZephyr developers of the existance of erato
would also be worthwhile.
>> There is a technical issue hiding here. That issue has to do with where
>> the service "interface" is provided. When you control all of the
>> software (both client and server) you can ignore the wire protocol used
>> by the service. As long as you can arrange for all of your customers to
>> have a compatible client, you can change the server and wire protocol at
>> will. Throughout the history of Athena, this has pretty much been the
>> case.
This is an excellent point; I hadn't thought of it in these
terms previously, but you're correct. It seems to now be the case that
we have a fair number of "hidden" clients out there. It might be
worthwhile for us to consider what methodology, if any, will be used to
track these clients and notify them of changes that may affect them; I
suppose this is a question for the Software Release Team.
>> What I saw was an extended debate about who was responsible for
>> fixing what... while the customers were not working. Customer focus
>> means that we don't leave customers broken while we discuss the best
>> approach to solving the problem, not if there is any reasonable way
>> to get them back up and running. In the end IS is service
>> organization. We need to remember that.
This is also a point well taken. From my standpoint, I wasn't
aware of significant customer inconvenience, other than the original
problem report that was received; the lack of reaction, combined with
the understanding that winzephyr wasn't considered "supported", made me
consider the situation non-urgent; this was backed up by looking at the
OLC queue and at newly received cases in Casetracker for problem reports
relating to winzephyr, of which there seemed to be none. I had been
hoping to speak with Tom Thornton or one of the other Pismere developers
later that morning regarding the problem, but fate, it seems, had other
plans.
What I've taken away from this email discussion is a general
consensus that upgrades should be backed out if they cause any
unexpected behavior, even if the results of that behavior only affect
setups we would consider unsupported. If we are aware of the problems
in advance, and make a good faith effort to contact users of the
unsupported software and an upgrade path is available, then we may
proceed. Would you characterize this as a good summary of your opinion?
Garry
