[3081] in Release_7.7_team

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

Topics from me for next meeting

daemon@ATHENA.MIT.EDU (Bill Cattey)
Fri Jan 4 18:07:06 2002

Message-ID: <4wBXKM9z0001QokMgr@mit.edu>
Date: Fri,  4 Jan 2002 23:07:04 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
To: release-team@MIT.EDU

Here are 4 things I'd like to be put on the Release Team agenda:

1. Check in on hesiod-free updating.

At the Linux Desktop Discovery meeting, I was asked to verify
that the requested feature that Athena updates happen even if customers
have NO Hesiod information was implemented.  (This is a quick item.  I'm
reasonably sure the answer is yes.)

2. Feature request by EECS.

I met with Chris Terman today of EECS and am excited by the prospects of
having him as a customer.  He's got 125 brand new systems, apparently
all identical, with an interest on putting Athena Linux on them.  I've
dispatched amb to make sure the install works.  But as a prerequisite
for enabling auto-update, Chris has asked for a feature.

The specific thing he asked for may not be the best thing.  He
specifically asked to be able to specify a control file in /etc/rc.conf.

What he's trying to do is control whether or not a group of machines get
updated.  I think there is a lot of interesting pondering around this
functionality, and I want the Release Team to discuss it.

3. Athena Kerberos config files as a separate package.

At the Athena Desktop Discovery meeting today sly pointed out that there
are conditions where just the couple Athena kerberos config files and a
doc on how to install them is enough to put someone online with
kerberos.  (In fact, I was suggesting to a DSpace colleague that he do
precisely that with an hpux system.)

Could we discuss what is involved here, and see if it's something that
can be just done, or determine trying to do it will not work or be a bad
idea?

4. Publicising our rules of release.

Something has come clear to me about people's perception of Athena
updates.  They have NO IDEA that we have rules like the "No changes
after drop date" that govern our roll-out of updates.  I'd like to
discuss how we might publish our rule set to help people understand that
we really DO think very hard sometimes before rolling out an update.

-wdc

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