[4060] in Release_7.7_team
Minutes of 2003-11-05 release team meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Nov 5 15:22:16 2003
Date: Wed, 5 Nov 2003 15:22:15 -0500
Message-Id: <200311052022.PAA08768@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
Attending: ghudson aurora rbasch jweiss wdc miki amb
1. Mail
There is some concern that direct delivery from Athena machines to big
ISPs may stop working, if they start whitelisting the MIT mail hubs
and blacklisting the rest of MITnet. (Or blacklisting the rest of the
Internet for *@mit.edu envelope froms.) We don't really expect this
to happen, but if it does, we'll have a very difficult transition for
our MUAs.
(It won't be a major catastrophe if it does happen, since almost all
user-level mail gets relayed to outgoing, and any mail which fails to
directly deliver will result in a bounce.)
2. IMAP tools
Bob raised three questions on source-developers:
A. Tool names (mailscan vs. imapscan or other options) - We decided
we should not use generic names because the chance of conflicts with
future tools is too high. "mitmail" seems like a good prefix to make
the names non-generic without making them too unfriendly. We did not
decide between one command with subcommands ("mitmail scan")
vs. three-word command names ("mitmailscan"); Bob can make that
choice offline. It might be easier to communicate the latter choice
over the phone.
B. How to identify messages - There are UIDs, which will grow big,
and sequence numbers, which may have weird properties (like, if you
have 100 messagse, and you delete one in the middle, the next one
that comes in might fill in the gap--but that seems very wrong).
More research may be required. If we have to use UIDs, we can just
tell users to cut and paste them in the rare cases where users have
to use these tools, and scripts can just extract and use them like
they'd use any message identifier.
C. Display - We decided we shouldn't pipe stuff through mhshow in
order to avoid creating a new dependency. Since the goal is not to
provide an alternative MUA, "grab message to stdout" is really all we
should provide. The user can pipe that through mhshow by hand if
that's really needed.
3. Linux distributions
We're not sure what we'll wind up doing. Red Hat will EOL RH9 in the
not-too-distant future, leaving us on our own for security updates.
(Which isn't the end of the world.) Fedora is probably the most
likely future upgrade path, but that depends on the quality of what
comes out of that project. Mandrake is another option, especially
since we're used to mostly doing our own thing with GNOME.
4. Patch release
We will reschedule it to Wednesday on account of the holiday.
5. tex
owls discussed the tetex issue (adding functionality vs. using stock
Red Hat package) and pretty much deferred to us. We decided on the
following:
* We will use a native package on Linux, assuming there is a tetex
2.0.x package available for the next release. We will use a
locker and attach-and-run scripts on Solaris.
* When people request additional functionality, we should probably
tell them to install it in their homedir; spending developer time
on stuff wanted by just one or two users isn't very efficient.
* If we do add functionality centrally, we should do it by adding
the content to a separate locker which sets environment variables
and runs the normal latex. That way we don't suffer the confusion
of providing functionality by default on Solaris and not on Linux.
6. Disconnected operation
With the addition of the offlinehome script, we are closer to being
able to deploy. We need to:
* Perform testing to make sure there's a reasonable user experience
* Document
* Tell support we have something ready
[After post-meeting consultation with Derek and Andrew:]
Before user testing, we may have to solve the missing piece of how to
make the framework notice when the user goes on or off net, or if we
can't do that, to provide a tool (perhaps based on NEAT) for the user
to inform the system about that. In the realm of automatic solutions:
* For PCMCIA interfaces, the user can insert or eject the card.
We're pretty sure that works now.
* For integrated wired interfaces, Andrew believes that the RH9
hotplug framework will generate an event when the user plugs or
unplugs a cable, and that the disconnected operation framework
should already receive appropriate events when that happens, but
Derek reports that this does not appear to happen on his Athena
9.2 laptop. More investigation required.
* For integrated wireless interfaces, we know of no existing good
answer. We could perhaps write a little daemon which monitors the
signal strength and applies heuristics.
7. Status report
Under separate cover.
