[3545] in Release_7.7_team
Minutes of 2002-10-02 release team meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Oct 2 14:25:13 2002
Date: Wed, 2 Oct 2002 14:25:11 -0400
Message-Id: <200210021825.OAA18189@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
Attending: ghudson rbasch wdc jweiss tbelton
1. Help
Nobody loves the help locker any more. Rather than make someone love
it, we will stop using it; /usr/athena/bin/help will be a script which
echoes "Starting web browser..." and then runs htmlview with the
appropriate URL.
2. Patch release plans
Sunblade 150 video card support drives us to make a patch release; it
should go to the dev cell by the middle of next week and the Athena
cell some appropriate time thereafter.
3. Mozilla
Greg broke the web icon on IRIX by mistake. Rather than put it back
to running netscape, though, we think we can install mozilla for IRIX
in the infoagents locker, and dump a /usr/athena/bin/mozilla onto the
packs.
(IRIX machines will bring mozilla local, as it turns out; that change
was also mistakenly propagated during the last patch release.)
Mozilla 1.0.1 should be installed soon; we will keep 1.0 around,
somehow, for recovery in the case of some disastrous problem being
discovered.
There appears to be an endian issue in Mozilla's history files, which
affects anyone who runs Mozilla on both Solaris/IRIX and Linux. It
doesn't seem to be fixed on the Mozilla mainline. We may need to turn
off URL completion by default to make the bug less problematic for
users.
4. NTFS
Lack of NTFS support on Linux will become a bigger problem for us over
time, but we are not in a better legal position than Red Hat is to
make it available. So we won't be doing that.
5. Status
We did our status report; it will show up in mail to release-team some
time soon.
6. GConf
More GNOME programs are starting to use GConf, which expects sites
like ours to run a GConf network server to handle multiple logins per
user. (But, they don't support any security more advanced than
tcp_wrappers.) Nautilus is already a problem here, and Evolution may
have some hidden GConf-related problems as well. We are also planning
on using gconf for athconf (GUI configuration of Athena account
options), although our life would be somewhat simpler there because we
wouldn't have any long-running processes using information from GConf.
Our options are:
1. Hack it to run unlocked. If a user logs in in two places at
once, changes made on one machine may get stomped by the other;
the likelihood of such stomping depends on how long gconfd caches
information for, both for reading and for writing.
2. As in (1), but issue a warning to the user whenever they log in
on two machines at once saying what bad things might happen.
3. Try to make it talk to itself nicely over the filesystem,
noticing when changes were made by a different instance. This
might be tough, and it can't be completely perfect, but it might
be the right tradeoff depending on how hard it is.
4. Run a GConf network service which clients talk to. This probably
means rewriting the GConf network code to use Kerberos, and of
course requires a contuining commitment from ASO as well as dev.
The benefit here is that changes made on one machine can be
immediately reflect on other machines, assuming the applications
play nicely. A single process serializes changes, so it would be
more robust than option (3) where there would be some delay (even
if it's only a few seconds) before a change made by one gconf
instance would be noticed by other instances.
We will probably resort to option 1 or 2 unless someone gets inspired.
