[1612] in Release_7.7_team
notes, 1/26 (postponing 8.2.17)
daemon@ATHENA.MIT.EDU (Mike Barker)
Tue Jan 26 23:12:24 1999
Date: Tue, 26 Jan 1999 23:01:46 -0500
To: release-team@MIT.EDU
From: Mike Barker <mbarker@MIT.EDU>
Attending: Jeff Schiller, Heather Anne, Abby Fox, Oliver Thomas, Greg
Hudson, Bill Cattey, Bob Basch, Miki Lusztig, Mike Barker, Dan Winship,
Jonathon Weiss
We had a lively discussion concerning the impact and possibilities for
dealing with 8.2.17. In particular, members of the community who do not
automatically update were being forced to update.
these notes may be unusually cryptic for those who were not at the meeting.
I strongly recommend talking to someone who was at the meeting about it if
you have any concerns.
Selected notes from the discussion:
Have we done our homework on what happens with an old local disk and new
pack mixture?
We need to make sure to establish two-way communication with our stakeholders.
We need to be careful to include "please send questions and comments to
release-team" whenever we make an announcement.
Suggested general principles:
- don't break things
- there will always be some breakage, so make sure that people can hold off
until they are ready to deal with the breakage
The update process includes a "reset to known state" and then an update
phase. Re-setting to known state breaks many things.
From the board notes:
Questions:
Where do the patches fall -- local disk or packs?
How many back versions (major, minor, patches) do we claim to support?
Does the notice period need to be changed? Notification method?
What other ways of getting input should we explore?
Alternatives:
1. 8.2 Full release -- requires time, space, etc.
2. "fix me" script to correct problems for people not taking the update
3. Back out the patch that makes the update break systems that don't take
the update
Action items
1. Evaluate the patches risk, local disk vs. packs and dependencies -- greg
and Miki
2. Delay release at least one week (Jonathon will make sure ops knows)
3. Send mail to release-announce to let them know the release will be
postponed until at least Feb. 4 -- Jonathon Weiss
4. We will address long-term issues at a later meeting
5. may be updates to the private workstation owners guide -- Jonathon and
Heather
Items for later consideration
1. Discussion of moving to updating only explicitly changed files
2. Better space checking
3. Separating cleanup and update; allowing some control of which parts
occur (e.g. private workstation owners may not want to reset to a known state)
4. Better outreach/dialog with private workstation owners
