[2637] in Release_7.7_team
Minutes of 2001-03-07 release-team meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Mar 7 15:35:21 2001
Date: Wed, 7 Mar 2001 15:35:17 -0500
Message-Id: <200103072035.PAA10068@equal-rites.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@mit.edu
(People who were at the meeting might want to pay attention to 2.2.1,
where I added a couple of items I forgot to mention the meeting.)
Attending: ghudson zacheiss ajfox amb miki rbasch tbelton wdc jweiss
1. Zephyr
We spent a short time going over the zephyr situation. Relevant
concerns seem to have been expressed to the relevant parties.
Greg does not have any more time to help the winzephyr developers with
the bug, unfortunately.
2. Risk analysis for 9.0
Greg presented risks he has identified for 9.0:
2.1. xscreensaver
xscreensaver needs to be updated because of known serious bugs, some
of which are probably its fault. The merge has proven to be more work
than anticipated, and will almost certainly result in some number of
new bugs which need to be fixed.
2.2. GNOME
2.2.1. Integration of GNOME is not yet complete. In particular:
- We have to write code to do panel logout confirmation.
- We have to write code to confirm a user's desire to revert
the dash-based interface.
- We have to write code to confirm a user's desire to revert
to the default GNOME configuration, and develop a method to
do so without panel screwing us up.
- We have to punt control-center capplets which won't work,
particularly the gnome-session capplet.
- We have to make NOCALLS work with the gnome_config system.
With everything else going on, it's possible that we might simply not
finish all of this work.
2.2.2. The user-visible GNOME configuration has not settled down, and
we are currently eating into the four-month window of lead time
requested by the documentation team.
2.2.3. GNOME code tends to spew assertion failures to stderr (with no
obvious ill effect). Ideally we should hunt these down and fix them.
The other option is to redirect panel and gnome-terminal stderr to
/dev/null like Red Hat effectively does, at the cost of losing
potentially important error messages (not just from GNOME stuff, but
from any subprocesses of panel or gnome-terminal).
2.2.4. Users who do not use sawfish will get more assertion failures
and sometimes annoying dialog boxes because they don't have a
GNOME-compliant windowmanager. (Which is not supposed to be a
requirement, but not all GNOME developers have a reasonable conception
of that design goal.)
2.2.5. GNOME may turn out to be unstable enough as to present a big
support problem.
2.2.6. GNOME may turn out to be too hard to centrally administer
because it has no model for integrating site defaults with user
configuration.
2.2.7. GNOME may turn out to be difficult or painful to upgrade
because its developers may not obey proper discipline with regard to
shared libraries or user configuration.
2.2.8. GNOME may continue to present difficulties for our model of
shared home directories in a multi-platform environment.
2.2.9. Without nautilus (which is looking awfully unlikely), some
existing users may feel that GNOME does not provide enough value to
justify such a major change in the interface.
Issues (5)-(9) above cannot really be addressed by us without
jettisoning the project, so will note them but not do anything about
them.
We will deprioritize (3) and the stderr part of (4) because we have
an easy if suboptimal way out, and there are more important issues.
2.3. Solaris
2.3.1. Partition sizes may prevent people from upgrading without a
reinstall, particularly for sun4m machines.
Swap size is also potentially at issue, though we can use different
miniroots for sun4m/sun4u machines. (Basically, we need a new, larger
miniroot for the new sunblade machines, and it won't fit in the swap
partition of some sun4m machines.)
2.3.2. 32-bit versus 64-bit incompatibility will pose some problems.
miki will run some tests. Most likely only kernel-delving programs
like top/sysinfo/xntpd will be affected, and we can use
bin/{sparcv7,sparcv9} magic, but we will still have to kludge our
build procedure to produce two different binaries for those programs.
2.4. Linux
2.4.1. Red Hat 7.0 has a bad reputation. 7.1 may not be out soon
enough for us to use it. But sticking with 6.2 will have bad
repercussions in terms of PR and hardware/software compatibility.
2.4.2. The new RPM format continues to hurt us. We need a way to make
sure that the rpmupdate RPM is built in 3.x format, and the new RPM
doesn't seem to have an option to do that.
2.5. krb5
A new version of krb5 is out, 1.2.2. krb5 merges are always hard and
we're already short of Greg time. But falling behind puts more of a
burden on the krb5 team.
2.6. BIND 9
BIND 9.1.1 (when it comes out; it's in release candidate 4 status
right now) has promise as a way to eliminate random lookup failures
and lets us do DNSSEC given a little work from ops. There is no
anticipated high cost (we don't customize the BIND source code much),
but it's a total rewrite, so it's a big unknown.
We will probably relegate this to time-available (i.e. "probably not")
status for 9.0, and revisit it for 9.1.
