[6955] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Release Team Minutes, 9/10

daemon@ATHENA.MIT.EDU (Jonathan Reed)
Fri Sep 10 16:52:43 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: <DCCDD5C8-5914-4818-8485-5BFF10DC152E@mit.edu>
Date: Fri, 10 Sep 2010 16:52:35 -0400
Message-Id: <6F9888AF-0649-48C5-AC22-023043EF12F6@mit.edu>
To: release-team@mit.edu
Content-Transfer-Encoding: 8bit

> 1) Discuss new definitions of alpha and beta cluster
> This includes re-purposing the "development" repo to be slightly less bleeding, and also soliciting testers.

There was general acceptance of this, plus a note that staff should have their machines in alpha, and we could possibly increase the number of beta machines in the clusters.  SIPB should also have an alpha and/or beta machine.

There was discussion about what to do with "early", and I believe agreement that it will only be significant for distribution upgrades, and not "patch releases".

One thing I forgot to mention at the meeting is that I have new signage to identify such machines.

> 2) Discuss new workflow
> The ability to push out quick fixes has left us in some unfortunate situations, so we need to adopt a less ad-hoc workflow.  This may mean that changes take a bit longer to get pushed out; I'm not convinced this is a bad thing.  A draft is at http://debathena.mit.edu/trac/wiki/WorkflowPolicy.  Feel free to edit or annotate that page before the meeting (buttons are at the bottom if you're logged in to Trac).  Use of strikethrough (double tildes on each side of the text) would be appreciated if you make significant changes.

I will update the Wiki to reflect what we discussed
- Commit changes.  If change is significant and not urgent, wait a day for feedback.
- Build and upload to development.  Development has minimum TTL of 1 business day.
- Moving to proposed requires 1 ACK from a developer (who has reviewed code) and 1 ACK from a tester (who has used an alpha machine).  These can be the same person, but not the original commiter [sic].
- Minimum TTL in proposed is 3 business days (no change).

We will consult with hotline and investigate the possibility of a "patch day" where we move from proposed to production on a specific day of the week.

Stages of the workflow can be bypassed or changed on a case-by-case basis with consent from release-team.

Notification:  We will use release-announce for patch-release announcements, and ideally send the announcement at T-3 or T-2 days.  Mail will be sent to release-announce informing list members of the increase in traffic.

Ideally, bugfixes will be kept separate from enhancements (so that we can, if necessary, FastTrack(tm) one without the other.

> 3) Discuss soliciting additional SIPB attendees

There is a hackathon tomorrow.  Debathena will be shamelessly plugged. 

ACTION ITEM: geofft will request a spot for a cluedump for Debathena that can be used to jump-start debathena-trainees.  jdreed can assist with the cluedump as long as it occurs on Thursdays, or after 7:30pm on Tuesdays.

> 4) Revisit fglrx in the clusters (alexp)

Blender doesn't work.  

ACTION ITEM: alexp will test the fglrx drivers on his machines.
ACTION ITEM: amb will test on all supported cluster hardware in test cluster.

Applications to test include Blender (from Ubuntu repos, not locker), Cambridge Structural Database, possibly Mathematica and Maya

> 5) Schedule fall term meetings to work around student schedules

Fridays at 3:00pm for now.  Subject to change pending additional student attendees.

> 6) Possibly deploy 32-bit workstations

There's a small but vocal community of Pro/Engineer users.  Pro/E cannot be made to work on 64-bit.  32-bit dialups are not a sustainable option.  We will consider deploying clearly-marked 32-bit workstations in W20, with a finite TTL. (i.e. this academic year only).   The vendor ceased to care about Pro/E on Linux 3 years ago.

ACTION ITEM: lizdenys will investigate possibly finding out which courses, if any, are using it.

> 7) Printing

There was universal agreement that CUPS is quite possibly the worst software ever.  Ops will investigate changes, including sending PDF jobs directly to the 9050s, and connecting to the 9050s using IPP instead of the JetDirect port.

Ops will drop 5GB+ jobs.  Our wrappers will notify the user on STDERR about the rejected jobs.  Various GUIs will not.  The status information is available on OS X and Linux GUIs if you know where to look, and Windows simply doesn't care.

For now, stalled print queues will be dealt with using lprm.  If there is no active job, the queue should be cupsenable'd.  

ACTION ITEM: jdreed will ensure Servicedesk is aware of these procedures.

ACTION ITEM: Camilla will investigate why the Duplex setting in moira is not turning into a default setting of "sides=two-sided-long-edge" in the CUPS config.

> 8) Cluster status notifications

jdreed will check with hotline about their usage of Nagios.






home help back first fref pref prev next nref lref last post