[2750] in Release_7.7_team
Minutes of 2001-05-23 release team meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed May 23 15:03:57 2001
Date: Wed, 23 May 2001 15:03:53 -0400
Message-Id: <200105231903.PAA05845@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@mit.edu
Attending: ghudson ajfox wdc rbasch amb tbelton jweiss zacheiss
1. Performance
Ultra 5s and O2s are rather slow, particularly in terms of how long it
takes them to draw the panel.
We've been planning to track more files locally, at least on Suns with
one big partition, although that may turn out to be difficult.
Another source of slowness is reading the panel menus out of AFS (many
many small files). We should probably copy the menus to local disk
nightly. Greg will work on that.
2. Status
9.0.4 will go out today, fixing some small bugs (notably, a bunch of
xalf bugs). More recent fixes will wait a week.
We have some open and undiagnosed bugs; mostly, panel and
tasklist-applet are fairly crash-prone, and capplets also seem to
crash fairly easily.
3. Solaris
We have several issues:
* Many Ultra 5s and 10s can't boot the miniroot due to IDE
device number issues. The fix will be ugly.
* catman doesn't work because of the way AFS is mounted on the
miniroot.
* Ultra 1s can't boot the miniroot because 64-bit mode is
disabled by default on that platform; it's easy to reenable
it, though.
Fixes for the second and third problems are already deployed as of
this writing; still working on the first one.
There are also some packages to install for the Sunblades for things
like firewire support; they will go in the 9.0.5 version script.
There are also some OpenGL packages which need to be installed; that will wait for miki to get back.
4. OpenAFS SMP
OpenAFS does not appear to work with SMP in 2.4.2-2. We think it will
work in more recent kernels. We will wait for Red Hat to package a
more recent kernel; in the meantime, SMP users will have to compile
their own kernel and OpenAFS modules, or run in uniprocessor mode.
We should think about building our own kernel RPMs in the future, but
don't have time for that right now.
