XEmacs Pre-release Tester Guidelines
Once you have the sources, please review the files
etc/BETA and README if you haven't done
so recently. Then read the CHANGES-release and
PROBLEMS files. Review those two every time you
update your sources. (If you're using CVS and have a fast
connection, you may like to do this using cvs diff -r
r21-4-XX where XX is the last gamma version you tested;
please keep the -z level down to 3 or less.) Please
review the Testing Priorities section of this document
every time you update. If you haven't done so recently,
it may be useful to look at NEWS.
As always, the detailed instructions for building XEmacs are in
INSTALL.
Instructions on getting the
sources are presented below. Please read the Testing
Priorities first, and review them every time you
update the sources.
In the current structure, to have a functional XEmacs you
must get the packaged Lisp. You can
check out the source from CVS and build them,
if you like. However, you may prefer to
simply download and install
the SUMO package tarball if you haven't done so already. See
README.packages (HOWTO) and etc/PACKAGES
(list of available packages). These
files are still kept up-to-date, but you may find it more
convenient to read the Info versions available in the XEmacs
Manual. A version of README.packages is
available online.
Discussion of release plans, as well as all other issues related
to XEmacs development, is taking place on the developers' mailing
list, xemacs-beta@xemacs.org, which is an open mailing
list. More information can be found on the
Mailing Lists page.
Subscribe by sending a request containing the word
`subscribe' (without quotes) in the body of the message
to
xemacs-beta-request@xemacs.org. List archives are available
at http://list-archive.xemacs.org/xemacs-beta/.
Testers should subscribe to xemacs-beta, or review the archives
regularly.
Testing Priorities
In approximate order of importance:
-
Matt Tucker's syntax table improvements are now committed to
CVS. Please look for anomolies in font-lock and indentation,
the most likely place for problems to show up.
If you do discover problems, it is extremely important to
provide a text where the problem occurs. It is very difficult
to replicate syntax table-repated problems based on a verbal
description of what the text ``looks like'' and doing
``something like this.'' It is preferable if this is short
excerpt, and that you be able to demonstrate it starting from
xemacs -vanilla . But if you can't do that, send
us the whole file and your init file if it only happens then.
- Whatever else you can think of, because ...
-
... the Release Manager has to get off his lazy duff and fill in
this section.
- Please check back here regularly.
None; all have already been integrated.
Testing Procedure
-
Subscribe to xemacs-beta.
Get the current version of the sources.
Configure them.
-
Build them with redirection of stdin and
stderr to the file beta.err (used in
the reporting process).
-
Report the build
using M-x build-report .
Install (optional). Do it once in while, please.
-
Use it, especially trying out your favorite features and the
testing priorities. See also NEWS and the feature
list for new features that you might want to try out.
Report bugs to xemacs-beta@xemacs.org.
-
Fix them and submit patches to
xemacs-patches@xemacs.org (optional).
-
Repeat, with new configuration or updated sources. Often!
This section should be more formal and precise, without imposing
further burden on testers. Send suggestions to the
Release Manager
or to xemacs-beta@xemacs.org.
It is not only important to report problems with XEmacs,
although we're pleased when you do (in the sense that we can't fix
bugs we don't know about!) We also need to know about your
successes. That's the only way we can guess if new features are
ready for prime time (e.g., GTK/XEmacs): when we get
uniformly successful reports. It's also useful in isolating
problems. If we have a record of several similar builds with no
apparent problems, we can guess that it may be something in the
reporter's environment. We can also ask the other tester to check
for the problem, and to test the fix.
We try to make reporting builds easy. Use Adrian Aichner's
M-x build-report function. If you have a successful
build, that's all you need. Just run src/xemacs from
the top of your build tree, then M-x build-report .
It will automatically insert Installation and the ``interesting''
messages from make in the buffer, allowing you to add
some free form commentary before sending. Here's the docstring:
Report build information including Installation and make output.
Prompts for status (usually "Success" or "Failure"). Then uses
`compose-mail' to create a mail message. The Subject header contains
status and version information. Point is left at the beginning of the
mail text. Add some notes if you like, and send the report.
Looks for Installation and the make output file (`beta.err' by
default, customizable via `build-report-make-output-files') in the
build directory of the running XEmacs by default (customizable via
`build-report-make-output-dir'). The output from make is filtered
through `build-report-keep-regexp' and `build-report-delete-regexp'
before including in the message.
See also `mail-user-agent', `build-report-destination', and
`build-report-installation-file'.
If you don't get a working XEmacs, you
should report the build anyway, by setting
build-report 's variables. The ones you need to set
to use a different XEmacs to report the build are
build-report-installation-file and
build-report-make-output-files.
Suggestions for improving this function are welcome (as are any
suggestions that would make testing more productive or less work).
Hints for Testers
Once you have built (and optionally installed) your shiny new
XEmacs, the files etc/BUGS and
etc/DEBUG, among others, may be useful to review once
in a while. If you are going to actually read sources, the
file etc/CODING-STANDARDS and the introductory
material in the Internals Info manual may help you to
understand the conventions used in writing XEmacs code.
XEmacs has recently been subject to a large number of changes
without a thorough performance audit. It is not very difficult to
profile XEmacs Lisp programs. If you encounter a performance
problem, please consider profiling it. A recent thread on
xemacs-beta shows
how to do it.
#### FIXME: The messages in that URL's thread contain absurd
amounts of quoting. Condense!
Volunteer to fix it!
#### FIXME: We need more tips.
Suggestions?
Be warned that these trees are large! XEmacs 21 sources will take
up almost 40 MB of hard drive space, before compilation. Add in
the lisp packages tree (another 80 MB!) in your calculations if
you're interested in messing with them too. All in all, the total
tree size for the XEmacs core tree is 196MB, comprising over 2006
files with 397754-some odd lines of code. Packages add another
4042 files for 760315 lines of lisp.
There are two basic ways to get XEmacs development sources: by
CVS and by anonymous FTP.
CVS is preferred for several reasons.
First, when development on a particular feature moves,
it moves fast. The FTP tarballs explicitly include a
promise that they at least build (and so far this promise is
generally observed in the ``keeping''). This means that it's hard
to release them very often.
Even if you don't need to be on ``the bleeding edge,'' but just
want to see the shape of things to come, CVS has a number of
advantages. First, CVS allows us to identify the exact content of
the version you have by use of the CVS diff command. It's
unlikely, but tarballs do become indetectably corrupted in
transmission, or you may have not overwritten a read-only file, or
you may have a network file system, or whatever. In exactly the
same way, it also allows you to make local modifications, yet
always be able to identify them with a single command.
Second, if you do detect and isolate a bug, you can check to see
whether the questionable code is recent or not, and whether or not
a fix has been applied in more recent versions.
Third, if you're bandwidth-limited, it's more automatic and less
error-prone than upgrading via diffs, especially if you've skipped
multiple releases.
There are possibilities other than CVS or FTP from the XEmacs
sites. For example, the ``unstable'' branches of Linux
distributions (and I suppose *BSD as well) often keep fairly fresh
versions of the development branch of XEmacs in both binary and
source package form. However, these will be updated at the
distribution's pace, and they do not normally contain XEmacs.org
CVS configuration data, making them hard to update.
The Release Manager acknowledges a deep debt to the home
page of the XEmacs CVS Archive by Jareth Hein, from which this
section is mostly stolen. However, the Release Manager has revised
it for his own purposes, and you can't blame Jareth for any
mistakes.
First, you need to do, just once:
$ cvs -d :pserver:cvs@cvs.xemacs.org:/pack/xemacscvs login
(Logging in to cvs@sunsite.dk)
CVS password: cvs
To get the latest (21.4) tester sources, do:
cvs -d :pserver:cvs@cvs.xemacs.org:/pack/xemacscvs checkout -d xemacs-21.4 -r release-21-4 xemacs
There may be other branches,
containing specialized versions of the development source tree,
available. At present none are relevant to the gamma release.
Also available are the stable sources, which occasionally contains a few
patches not yet available in the most recent release, and the
sources to the packaged Lisp, whose development schedule is
completely divorced from the core C and Lisp sources. For the
stable sources, see the
XEmacs home page.
The
XEmacs lisp packages
are now unbundled, and are available in their own CVS module.
There is only one version of the XEmacs Packages - no
stable or unstable branch. Get them like this:
cvs -d :pserver:cvs@cvs.xemacs.org:/pack/xemacscvs checkout packages
XEmacs CVS Archive
If you're not yet familiar with CVS, there is a lot of information
at ../../Develop/cvsaccess.html:
This site has a collection of CVS (Concurrent Versions
System) trees for XEmacs. The site is intended for use by people
wanting to hack on or test the sources.
Each of the main components of XEmacs is available separately as a
non-CVS tarballs via anonymous FTP. Here is the current URL for
the core's gamma sources:
In the XEmacs core directories, the main tarballs are
named according to the pattern
xemacs-major.minor.current.tar.gz.
These are full tarballs, containing all C, Lisp, and Texinfo
sources, the etc data directory, and compiled Lisp
(.elc) and Info files. At present bzip2
tarballs are not being produced for the 21.4 series.
For example, at the time of writing, in the current gamma release,
major = 21, minor = 4, and
current = 5, yielding
xemacs-21.4.5.tar.gz
The incremental patch files are named according to the pattern
xemacs-major.minor.previous-major.minor.current.patch.gz.
The most recent incremental patch file is
xemacs-21.4.4-21.4.5.patch.gz
If you wish to make an update from an earlier version, then you
will need all of the intermediate incremental patch files. the
patch files update only the course files. To have a
completely up-to-date XEmacs, you will need to regenerate your
compiled Lisp and Info files. (This is normally done
automatically by make beta ; if it does not, it is a
bug and should be reported.)
Corresponding to each main tarball and incremental patch file
is a .sig file. It contains an MD5 hash of the data
file for use in verifying correct download.
Also available are the stable sources, which occasionally contains a few
patches not yet available in the most recent release, and the
sources to the packaged Lisp, whose development schedule is
completely divorced from the core C and Lisp sources. For the
stable sources, see the
XEmacs home page.
Packaged Lisp is available in three forms. The Lisp sources,
individual binary packages, and the ``SUMO'' tarballs. The
sources for Lisp packages are continually being updated by their
own maintainers, and are not kept in any particular
synchronization with the core. For this reason they are available
only by CVS. Individual
binary packages are available from the FTP URL above, and may be
fetched individually and unpacked in the ``appropriate place.''
The
URL for package tarballs, both individual binary packages and
the ``SUMO'' tarballs, is
The ``SUMO'' tarball is simply an aggregation of all of the binary
packages (with a very few exceptions due to name conflicts). The
SUMO tarball comes in two parts. One is named
xemacs-sumo.tar.gz, and the other is named
xemacs-sumo-mule.tar.gz. The former contains all
Lisp packages which do not require mule for correct
operation, including many which support Mule functionality. The
latter contains only Lisp packages which contain libraries that
cannot even be loaded correctly without a Mule-enabled XEmacs
(i.e., they contain non-ISO-8859 characters, typically
Japanese).
You may safely install the Mule packages if you put them in a
package hierarchy named
datadir/mule-packages. Only Mule-enabled
XEmacsen look for packages there.
For more information about the packages, see the file
README.packages.
|