[3507] in Release_7.7_team
Minutes of 2002-09-18 release team meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 18 16:15:52 2002
Date: Wed, 18 Sep 2002 16:15:49 -0400
Message-Id: <200209182015.QAA17043@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
Attending: ghudson rbasch aurora cfox zacheiss amb sly wdc jweiss
1. PWOG updates
Camilla will be drafting the PWOG updates because Heather doesn't have
time to make substantial changes for a while. (Heather will review
and revise them, though.)
We will document the existence and limitations of zero cost Athena, in
section 1.1.1, and make note of it when we refer people to hotline.
We will document how to boot single-user mode in section 2.
We will document how to make an SMP machine use both processors, in a
new section between 3.5 and 3.6.
We will document that you use fdisk to partition a new disk under
Linux, but won't give a complete discussion of disk partitioning.
We will document that you run Xconfigurator to reconfigure X. We
won't document the tricks of doing this in single-user mode, because
we think in the long term that won't be necessary (we can have stock
answers about it in the meantime).
We will not document how to enable virtual consoles until it becomes
as easy as adding an rc.conf variable.
(Aside: our plan is to add the rc.conf variable, create the
/etc/athena/vcgetty script which honors it, and edit the "Type
CTRL-ALT-F7 to log in" inittab entries to run vcgetty instead. If a
user has commented out those entries in favor of the mingetty lines,
we won't try to undo that, since it's too error-prone.)
We will document where to find Red Hat RPMs and document that it's
generally okay to install them, and we will keep them up to date
during patch updates. We will document that you use "rpm -ivh" to
install an RPM. We will caution users against building a custom
kernel or changing the kernel version, since we can't make OpenAFS
work with that. We will caution users against using the --force flag
to rpm to work around dependency problems.
We will document the magic rpmupdate invocation which tells you what
changes you would need to make to get back to a stock set of RPMs, and
recommend that people do this if they have
We will document /etc/athena/access instead of adding Athena users to
/etc/passwd. We will describe how to read the access(5) man page,
since it's a little tricky.
We should document that local non-Athena accounts must be marked as
local in /etc/athena/access to prevent the login system from trying to
do Kerberos and Hesiod stuff with them.
We will gut the documentation about running track on Solaris. (And
maybe the stuff about attaching the packs, depending on what it's
there for.)
We will refer users to OLC instead of hotline in case of update
failure, since they are slightly more likely to get useful help there.
2. Laptop status
One of the laptops can't be supported because of X issues. The Dell
laptop will also enter this category the next time the product version
is revved.
3. Disconnected operation
Derek will resume work on this.
4. Linux partitioning
We will go ahead with Greg's plan for add-on operation.
If a user decides to use Partition Magic to create Linux partitions,
they must then use manual partitioning and enter the partition names
they want to use. We aren't comfortable having a "look for existing
Linux partitions which might work" mode of operation.
5. IMAP tools
We have some desires for better IMAP support in the release, in
roughly decreasing order of priority:
1. We would like an IMAP replacement for "from".
2. We would like to be able to sync IMAP stores, safely, for backup
purposes. (And also restore from AFS to IMAP, I guess.)
3. We would like gnus to work.
4. We would like to be able to develop tools to do other things
like (1) and (2) without a lot of effort.
There are two possible bases to work with:
UW has a "mailutil" program which can check for new mail and
manipulate mailboxes within the IMAP store (but it won't deal with
individual messages). This would give us (1) but nothing else.
CMU has the Cyrus SASL and IMAP tools, the latter of which includes
a debugging program "imtest". This would give us (3) (gnus can use
imtest) and, in a rather hackish way, (1) and (4).
We are not terribly comfortable with UW c-client's build system; we
will probably import the Cyrus code, and then modify "from" to use its
IMAP libraries to get (1) in a non-hackish way.
