[689] in Release_7.7_team
Final Questions for Release notes
daemon@ATHENA.MIT.EDU (kcunning@MIT.EDU)
Mon Aug 5 12:41:54 1996
From: kcunning@MIT.EDU
To: release-team@MIT.EDU
Cc: kcunning@MIT.EDU
Date: Mon, 05 Aug 1996 12:41:45 EDT
Howdy,
I will soon hand over a final draft of the Release Notes to Graphic Arts
to be copied overnight so that we can distribute them first thing in the
morning to all the clusters. But first I need a few questions answered.
The rest of this message lists each issue and my proposed resolution.
Some are straightforward, others I need help with...
--Kevin
-----------------------------------------------------------------------
EMACS MH-RMAIL WARNING
from other.html:
>> [?] Now has warnings like "Message 219 modified; flush changes?
>> (yes or no)"
MIKE:
? is emacs mh-rmail
JONATHON:
I think the context here is mh-rmail mode in emacs. and I think you
get them if you edit a message and don't save it or something like
that. I only got that message once a few months ago.
Resolution: I will include the following note in the relevant part of
the Emacs section (NOT in the Other Software Changes section where it
currently appears):
* If you have edited a message in mh-rmail mode and try to switch
to a different buffer, Emacs now gives you an opportunity to save
the changes to the rmail messages with a warning of the form:
Message <em>message-number</em> modified; flush changes?
(yes or no)
Question: is this a system-specific behavior?
-----------------------------------------------------------------------
MH-RMAIL REFERENCE
from other.html:
>> Changes Particular to SGI
>> ...
>> * <tt>mh-rmail</tt> mode in Emacs now incorporates new mail
>> automatically even if the Emacs program is iconified.
Resolution: I plan to move this to the relevant Emacs section rather
than
leave it in the "other changes" section, as I think folks are more
likely
to find it in the Emacs Mail topic. (cf. above)
Question: Is this SGI-specific? If so, I'll include "On SGIs...".
-----------------------------------------------------------------------
#!/bin/csh ISSUE
from other.html:
>>Any ~/.xsession that starts with the line #/bin/csh will most likely
>>fail. [why? workaround?]
BRUCE:
Prior to release 8.0, /bin/csh was the same as /bin/athena/tcsh. Now
the vendor-supplied /bin/csh is left in place. This means that
scripts,
including .xsession files, starting with #!/bin/csh will likely fail,
since the global cshrc requires that $host be set. Scripts that begin
with #!/bin/csh -f will work fine if no tcsh features/variables are
used
within the script itself.
BRUCE:
I was wrong about /bin/csh.
vrt tells me we never replaced the vendor /bin/csh. It appears the
$host breakage is new, part of the recently-added XUSERFILESEARCHPATH
setting in the global cshrc.
GREG:
> BRUCE:
> Prior to release 8.0, /bin/csh was the same as /bin/athena/tcsh.
> Now the vendor-supplied /bin/csh is left in place.
This isn't true. /bin/csh is a symlink to /bin/athena/tcsh. I don't
have any idea why xsessions that start with #!/bin/csh would fail.
BRUCE:
The section of the release notes in question is for SGI-specific
changes. On my newly-installed sgi,
ls -l /bin/csh
lrwxrwxr-x 1 root sys 14 Aug 2 11:15 /bin/csh ->
../../sbin/csh
JONATHON:
> BRUCE:
> I was wrong about /bin/csh.
Actually I think you were right for the SGI, just not the sun (the
release team decicided to back out the csh change)
> BRUCE:
> vrt tells me we never replaced the vendor /bin/csh. It appears the
> $host breakage is new, part of the recently-added
XUSERFILESEARCHPATH
> setting in the global cshrc.
I think this was moved to the global cshrc, so the info may be
out-of-date. I think you will now lose, if you do not use the global
cshrc file. Can anyone confirm this.
I'll try to take a look at the release notes later today and send
mail.
Resolution: ???
Question: I can't tell where this discussion ended up.
What should I say about this item?
-----------------------------------------------------------------------
XUSERFILESEARCHPATH IMPLICATIONS
from other.html:
>> The variables XUSERFILESEARCHPATH and XFILESEARCHPATH, which
specify
>> where X applications should find their app-default files (etc.),
are
>> now given a value in the global cshrc file. As part of the default
>> Athena shell initialization process, these variables are given
>> reasonable default values, or the default values are automatically
>> appended to any existing values (as set in the user's
~/.environment
>> file) for the variables.
MIKE:
This means that applications which use XAPPLRESDIR to specify
app-default
files may have problems. The normal correction that needs to be made
is to set XUSERFILESEARCHPATH instead of XAPPLRESDIR.
(I think that's correct)
Resolution: I will add Mike's text immediately following the text
already shown.
Question: Is Mike's text correct? (Mike didn't sound 100% sure.)
-----------------------------------------------------------------------
MORE EXPLICIT MIME INSTRUCTIONS (MHN)
from mime.html:
>> Although this feature is now available, it is disabled by default
in
>> this release to minimize the impact on users.
MIKE:
should we explain that they need to unsetenv NOMHNPROC and set up
$MHN, /usr/athena/etc/mhn_defaults, maybe .mhn_defaults? also point
to "man mhn"? or should we save that for the advanced course in how
to shoot yourself in the foot?
Resolution: I'm going to leave this out and let users find this in a
stock answer or the MH books referred to in the section. I already have
a sentence pointing people to stock answers as the followup to this
section, so that's seems best to me.
-----------------------------------------------------------------------
MH DOC REFERENCE
(in mime.html)
Resolution: I got several pointers to the new home of Jerry Peek's MH
document (it's at several sites), and will use the following URL:
http://www.ics.uci.edu/~mh/book/
-----------------------------------------------------------------------
WEBLINT REFERENCE
from ez.html:
>> ... can use the Andrew HTML functionality, then check your files
>> against an HTML 3.2 validator (e.g.,
>> http://ugweb.cs.ualberta.ca/~gerald/validate/).
MIKE:
Bruce says we have weblint in the infoagents locker, too, if you want
to mention that.
Resolution: I checked with Bruce, and weblint does not support HTML 3.2.
To alert people to the existence of weblint, but not suggest it's 3.2-
compliant, I will add the following text within the parentheses, after
the URL:
... ; as of this writing, the weblint program in the
infoagents locker only checks HTML 2.0 validity).
-----------------------------------------------------------------------
EZ INTRO PROSE
from ez.html:
>> The Andrew software (including the EZ text processing program) has
been
>> upgraded and a variety of new features added. At the same time, the
>> software has been reorganized such that it now conforms to the
delivery
>> of standard third-party software on Athena. For example, the
software is
>> now delivered from a locker rather than directly in the Athena
release.
>> Nevertheless, users can access EZ directly from the release, as in
>> earlier versions of Athena.
BILL:
I have a teeny question: Did the prose in the intro about Andrew
change?
As it stands, on the most recent reading I made, it seemed awkwardly
crafted prose.
I see why you want to get people thinking about how Andrew now follows
locker standards, because you eventually want to introduce the notion
that some stuff is unsupported. But I think the meaning would be
better
communicated if that part were left out, and the relevant and highest
priority idea was just said. Something like:
> The Andrew software (including the EZ text processing program) has
been
> upgraded and a variety of new features added. The software has been
> reorganized. Users will access EZ directly from the release, as in
> earlier versions of Athena, but now, as is the case with our other
third
> party software packages, unsupported functions are mixed in with the
> supported functions. Users will see much more functionality, but
may
> not be able to get help with every function seen.
Even though I've gone to the trouble of suggesting prose, I consider
this an extremely minor issue. It's more important to come to closure
on the other areas.
Resolution: I will use the following text (already approved by Bill):
The Andrew software (including the EZ text processing program) has
been
upgraded and a variety of new features added. The software has also
been
reorganized: users can still access EZ directly from the release, as
in
earlier versions of Athena, but now, as with other third-party
software
packages on Athena, the software is actually maintained in a separate
locker and includes unsupported as well as supported functions.
-----------------------------------------------------------------------
XCAL
MIKE:
Before I forget - Paul Hill noted that xcal (from the calendar locker)
wasn't working on the new sgi's. craig and I fixed it Friday.
It still has an annoying small bug on the new systems - if you enter
data for "today", exit, and restart xcal, the first time it displays
it will not show the data. workaround--move to another day and then
back to today to display the data.
Resolution: I'm presuming this doesn't have to be documented, and was
not sent to the release-team for Release Notes purposes... I plan to
omit it.
-----------------------------------------------------------------------
KERBERIZED TELNET REFERENCE
from other.html:
>> Kerberized remote access to SGI workstations (e.g., Kerberized
>> rlogin or telnet to an SGI) now works. (It did not work in previous
>> releases.) The version of the Kerberos libraries installed on the
>> SGIs is now a vendor-supplied version (from Cygnus) rather than an
>> Athena-developed version. (Sun workstations still have an
>> Athena-developed version.)
JONATHON:
This is really only relevant to private machines which we don't quite
support yet, but I guess we will when I get to mkserv.
Resolution: I will leave this in as is because it alerts some folks
who might not otherwise see this info. In general, I have omitted
private WS info in favor of the System Notes, but this one seemed okay
to include.
Question: For the User Release Notes, is there a place (e.g., a URL)
I could point people to find the System Release Notes? It would be
nice to let users know there is (or will be) another source of
information. (It could even just be a placeholder for now...) Previous
Release Notes regularly included pointers to the System Notes.
-----------------------------------------------------------------------
ADDITIONAL SGI ITEMS (FROM THE SYSTEM RELEASE NOTES)
Resolution: Craig pointed me to /mit/builder/doc/8.0/rel80.tex as a
place to scrounge for any more SGI changes. I looked through a version
of that doc on Friday and didn't really see anything more to add to
the user Release Notes. Again, it would be nice to be able to point
to the System Notes...
-----------------------------------------------------------------------
That's it!
