[1837] in Release_7.7_team
notes, 6/23
daemon@ATHENA.MIT.EDU (Mike Barker)
Fri Jun 25 12:52:41 1999
Message-Id: <4.1.19990625114242.00cf03f0@po11.mit.edu>
Message-Id: <4.1.19990625114242.00cf03f0@po11.mit.edu>
Date: Fri, 25 Jun 1999 12:49:22 -0400
To: release-team@MIT.EDU
From: Mike Barker <mbarker@MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Attending: Greg Hudson, Miki Lusztig, Bill Cattey, Jonathon Weiss, Bob
Basch, Mike Barker, Oliver Thomas, Abby Fox, Thomas Bushnell, Karl Ramm,
Heather Anne, Dan Winship
1. The meeting is moving to 1 p.m.
2. To help Mike, various roles within the release team are being picked up:
- minutes: Dan
- agenda, convening, reminders: Greg
- moderator: Greg
- food: Heather
- management liaison/release team point of contact: Bill
- jik (bug handling): Karl
3. 8.3 status
Greg will prepare a patch release soon (8.3.9). This may result in a second
small patch release near the end of early, but the team prefers extended
testing of the known corrections to trying to bundle corrections into one
large patch release.
Update times -- see Bill for details about how many of what there are.
The current plan is to have an indy, o2, and sun night for the general
release to allow for the expected lengthy time of update on the indy
platform without interfering with other systems.
4. We continued discussion of the CRL difficulty with upgrading to Athena
8.2.19. Some points of the discussion included:
- crl uses "mkserv ops" for security features. it seems unlikely that
we can separate the security features out into a "mkserv security" package.
- Are there principles to avoid the kind of problem we had earlier with
the system pack update forcing local updates? Some suggestions:
- If the choice is between copying packs and breaking private WS,
copy packs if at all possible.
= In cases where we believe we may need to break private WS, the
decision needs to be escalated to a larger group before being committed to.
- When there are massive OS changes, we should change packs.
Agreement/Action Item: Consider having "Release Principles" on the release
web pages.
- We need to provide a path for reporting operationally important bugs
that has quick response and high visibility built in.
- to document the problem and the solution, we want email to bugs in
every case. This can be done before, while, or immediately after the other,
but it must be done (both by the person reporting the problem and by the
person solving it -- at least send a short note saying it has been solved!)
- three paths: zephyr instance consult. page ops. contact Bill
Cattey. zephyr instance consult.
- upon resolution of problem, we (E40 folks) will document the
solution by sending mail to bugs.
Agreement/Action Item: we need to publicize this as the way to handle
operationally important bugs.
- Should we have a "private Workstation Defender of the Faith" attend
the release team? Or perhaps on occasion/invitation? Maybe have an
occasional "Private WS" focused meeting of the release team? Discussion to
continue...
mike
