English

German

Japanese

America

Asia

Australia

Europe

Searching XEmacs Quick Links

About XEmacs

Getting XEmacs

Customizing XEmacs

Troubleshooting XEmacs

Developing XEmacs

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.

Candidates for inclusion in the release
(separate branches)

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.

Build Reports

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?

Getting XEmacs Sources

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.

<img src="http://www.xemacs.org/icons/cvssmaller.gif" alt="[CVS logo]" /> Getting XEmacs Sources via CVS

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.

Quick Start Guide

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:

Quick start guide

What is CVS

Using the XEmacs CVS server

Tags: what they are and their use

Packages info

Web access to the trees

Commit (R/W) access to the CVS trees

Getting XEmacs Sources via Anonymous FTP

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:

ftp://ftp.xemacs.org/pub/xemacs/xemacs-21.4

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.

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

ftp://ftp.xemacs.org/pub/xemacs/packages

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.

Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML