[7014] in Release_7.7_team
Minutes from 10/15 release team
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Fri Oct 15 23:08:26 2010
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <36443CC5-8B5E-4EB2-A3B2-6A0532B04608@mit.edu>
Date: Fri, 15 Oct 2010 23:08:19 -0400
Message-Id: <7F91A06C-573A-4329-96EA-916865F17457@mit.edu>
To: "release-team@MIT.EDU" <release-team@mit.edu>
Content-Transfer-Encoding: 8bit
Attending: jweiss, geofft, jogomes, jdreed, silvesa, alexp, amb, rbasch
> 1) New attendees and change in meeting structure (jdreed)
Due to the nature of attendees and the high ratio of software issues to larger concerns, release-team devolved over the past year to the point that it was a developer meeting. This is helpful, but only a subset of release team's purpose.
Moving forward, we're going to focus on higher-level discussions at the beginning of the meeting, and save Trac review until the end.
> 2) Dialup upgrade and printing status check-in (zacheiss/jweiss)
Mail was sent separately, but the dialups should be upgraded over the next week or so. Unclear whether it will be a phased deployment or a flag day.
Additionally, ops thinks the dialup slowness problem has been solved due to a VM config change unrelated to the 64/32 bit issue.
It was noted that test.dialup falling back to athena.dialup was confusing users and that perhaps that should be changed.
ACTION ITEM: jdreed will send mail to bug-dialup asking for this.
sun.dialup will likely be turned off by Jan 1. Ops is planning reach out to current sun.dialup users.
Printing update: We've seen improvements, but it's unclear if the improvements are due to the fact that we're killing jobs faster now or if jobs are printing successfully. Certainly we're still seeing some stalled queues. The next step is to switch to PDF for internal job handling; the goal for this is "by Thanksgiving".
Discussion ensues about whether we want to give up on CUPS+Kerberos entirely, because it seems like that ship has sailed, and "authenticated printing" in the rest of the world means "username and password". Certainly this would solve the Gtk issue (#691). Job control could perhaps be accomplished by a web interface only?
ACTION ITEM: jdreed will invite zacheiss and cfox to a future release-team (or subset thereof) to discuss this.
Ops wants to turn off the LPRng servers "soon". There are some things blocking on this, one of which is the legacy LPRng kerberized queues. The primary motivation for keeping these was to mitigate financial impact to dorms paying for printing and toner. This should no longer be the case, and ops would prefer if dorm kerberized queues went away by IAP. June 30 was kicked around as a potential date by which the LPRng servers might be decommissioned.
ACTION ITEM: jdreed will confirm with othomas that the list of copytech-maintained printers in Hermes is correct, and will then reach out to dorms about disabling Kerberos authentication and restrict lists on those printers.
> 3) 32-bit workstations in W20-575 (jdreed)
This will be in place by Thurs 10/21.
ACTION ITEM: jdreed will send signage to release-team for feedback
ACTION ITEM: jdreed will inform hotline prior to deployment
ACTION ITEM: amb will come up with an option to specify architecture type at install time, but deployment won't block on that.
Liz was in coordination with Mech E to find out who was using Pro/E and why. jdreed will follow up with her when she gets back.
> 4) Amendments to Workflow Policy (amb)
There is general approval. jdreed will edit the wiki to reflect amb's changes and send a formal announcement to release-team.
> 4a) Formal adoption and approval of workflow policy
> 4b) Procedure for new release support (jdreed/geofft)
We need better communication to end-users both before a release and after release. jdreed will document this in the wiki using the following guidelines:
- 1-2 weeks before release: packages in -development, communication to -announce saying the release is not supported but explaining how users can test. Mail should also recommend that people not upgrade immediately on release day unless they have a really good reason, and point out that even though we expect packages in production on $date, it will not yet be formally supported until more testing has occurred.
- 1 week before release through 3-4 weeks after release: testing and bugfixes.
- 3-4 weeks after release: mail to -announce saying release is formally supported.
For Maverick, specifically, we'll aim for a mail on Tuesday 10/19, but will remind users that we're still testing and that they should plan upgrades accordingly.
> 5) Hotline check-in (jogomes/silvesa)
We have done a poor job of keeping hotline in the loop on all changes. jdreed will create a series of Hermes articles on common installation issues and how to work around them, and send them to hotline for feedback.
When hotline encounters install failures in the field, they will report them to release-team, ideally aggregating into a single mail per day.
> 6) Other business
At other schools, screensavers (in a Mac and WIndows lab) display the Rules of Use for the facility, e.g. "turn off your cell phone", etc. This is done with both text and graphics. Lucid seems to have increased the DPMS power-down delay to 30 minutes, so this would give us a good 20-25 minutes of visibility in the clusters.
The xcluster machines are getting pulled. There are only 3 of them, 1.5 of which are functional. They will be replaced in the short term by large-format laminated copies of the Computing@MIT map.
ACTION ITEM: jdreed will coordinate with othomas to get said maps and then let Ops know when to pull the machines.
> 7) Trac Review, time permitting.
debathena-thunderbird-config moved to proposed, with estimated deployment on Wednesday. This will allow users to actually run Thunderbird. We should investigate the new autoconfig method and possibly fall back to an extension.
#648 will be fixed when the new installer is deployed with Maverick.
