--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/etc/BETA	Mon Aug 13 08:56:04 2007 +0200
@@ -0,0 +1,212 @@
+				-*- mode:outline; minor-mode:outl-mouse -*-
+
+* Introduction
+==============
+
+You are running an experimental version of XEmacs.  Please do not
+report problems with Beta XEmacs to comp.emacs.xemacs.  Report them to
+xemacs-beta@xemacs.org.
+
+** XEmacs Beta Mailing List
+===========================
+
+*** Subscribing
+---------------
+
+If you are not subscribed to the XEmacs beta list you should be.  Send
+an email message with a subject of `subscribe' (without the quotes) to
+xemacs-beta-request@xemacs.org and follow the directions.  You do not
+have to fill out the survey if you don't want to.
+
+*** Unsubscribing
+-----------------
+
+To unsubscribe from the list send an email message with a subject of
+`unsubscribe' (without the quotes) to xemacs-beta-request@xemacs.org.
+
+*** Administrivia
+-----------------
+
+The XEmacs beta list is managed by the SmartList mailing list package,
+and the usual SmartList commands work.  Do not send mailing list
+requests to the main address (xemacs-beta@xemacs.org), always send
+them to xemacs-beta-request@xemacs.org.  If you have problems with the
+list itself, they should be brought to the attention of the Mailing
+List manager Chuck Thompson <cthomp@xemacs.org>.
+
+
+** Beta Release Schedule
+========================
+
+The URL ftp://ftp.xemacs.org/pub/beta/README always contains the best
+estimate of when the next beta XEmacs will be released.  For weekend
+betas the release time is generally in the vicinity of 2PM to 5PM US
+Pacific Time (Universal Time minus 8 hours).  For weekday betas, the
+release time is generally in the vicinity of 8PM to Midnight US
+Pacific Time on the listed day.
+
+While 19.15 and 20.x are in parallel development, a simultaneous
+release day implies a release of 20.x first, followed a few hours
+later by 19.15.
+
+Betas are nominally a week apart, scheduled on every Saturday.
+Midweek releases are made when a serious enough problem warrants it.
+
+
+** Reporting Problems
+=====================
+
+The best way to get problems fixed in XEmacs is to submit good problem
+reports.  Since this is beta software problems are certain to exist.
+Please read through all of part II of the XEmacs FAQ for an overview
+of problem reporting.  Other items which are most important are:
+
+1.  Do not submit C stack backtraces without line numbers.  Since it
+    is possible to compile optimized with debug information with GCC
+    it is never a good idea to compile XEmacs without the -g flag.
+    XEmacs runs on a variety of platforms, and often it is not
+    possible to recreate problems which afflict a specific platform.
+    The line numbers in the C stack backtrace help isolate where the
+    problem is actually occurring.
+ 
+2.  Attempt to recreate the problem starting with an invocation of
+    XEmacs with `xemacs -q -no-site-file'.  Quite often problems are
+    due to package interdependencies, and the like.  An actual bug in
+    XEmacs should be reproducible in a default configuration without
+    loading any special packages (or the one or two specific packages
+    that cause the bug to appear).
+
+3.  A picture can be worth a thousand words.  When reporting an
+    unusual display, it is generally best to capture the problem in a
+    screen dump and include that with the problem report.  The easiest
+    way to get a screen dump is to use the xv program and its grab
+    function.  Save the image as a GIF to keep bandwidth requirements
+    down without loss of information.  MIME is the preferred method
+    for making the image attachments.
+
+* Compiling Beta XEmacs
+=======================
+
+** Building an XEmacs from patches
+==================================
+
+All beta releases of XEmacs are included with patches from the
+previous version in an attempt to keep bandwidth requirements down.
+Patches should be applied with the GNU patch program in something like
+the following.  Let's say you're upgrading XEmacs 20.4-beta10 to
+XEmacs 20.4-beta11 and you have a full unmodified XEmacs 20.4-beta10
+source tree to work with.  Cd to the top level directory and issue the
+shell command:
+
+$ gunzip -c /tmp/xemacs-20.4-b10-20.4-b11.patch.gz | patch -p1
+
+After patching check to see that no patches were missed by doing
+$ find . -name \*.rej -print
+
+Any rejections should be treated as serious problems to be resolved
+before starting compilation.
+
+After seeing that there were no rejections, issue the commands
+
+$ ./config.status --recheck
+$ make beta
+
+and go play minesweep for awhile on an older XEmacs while the binary
+is rebuilt.
+
+** Building an XEmacs from a full distribution
+==============================================
+
+Locate a convenient place where you have at least 100MB of free space
+and issue the command
+
+$ gunzip -c /tmp/xemacs-20.4-b11.tar.gz | tar xvf -
+
+(or the simpler `tar zxvf /tmp/xemacs-20.4-b11.tar.gz' if you use GNU
+tar).
+
+cd to the top level directory and issue an appropriate configure
+command.  The maintainer uses the following at the time of this
+writing:
+
+./configure --with-offix --with-mule=yes --with-dialogs=athena3d \
+	--cflags="-m486 -g -O4 -fno-strength-reduce -malign-loops=2 \
+	-malign-jumps=2 -malign-functions=2" --with-sound=no \
+	--with-xface=yes --error-checking=all --debug=yes \
+	--with-scrollbars=athena3d \
+	--with-canna=yes --with-wnn=yes --wnn-includes=/usr/X11R6/include/wnn
+
+Save the output from configure that looks something like:
+Configured for `i586-unknown-linux2.0.28'.
+
+  Where should the build process find the source code?    /usr/src/xemacs-20.0
+  What installation prefix should install use?            /usr/local
+  What operating system and machine description files should XEmacs use?
+        `s/linux.h' and `m/intel386.h'
+  What compiler should XEmacs be built with?              gcc -m486 -g -O4 -fno-strength-reduce -malign-loops=2 -malign-jumps=2 -malign-functions=2
+  Should XEmacs use the GNU version of malloc?            yes
+  Should XEmacs use the relocating allocator for buffers? yes
+  What window system should XEmacs use?                   x11
+  Where do we find X Windows header files?                /usr/X11R6/include
+  Where do we find X Windows libraries?                   /usr/X11R6/lib
+  Compiling in support for XAUTH.
+  Compiling in support for XPM.
+  Compiling in support for X-Face headers.
+  Compiling in support for GIF image conversion.
+  Compiling in support for JPEG image conversion.
+  Compiling in support for PNG image conversion.
+  Compiling in support for Berkeley DB.
+  Compiling in support for GNU DBM.
+  Compiling in Mule (multi-lingual) support.
+  Compiling in support for OffiX.
+  Using the Lucid menubar.
+  Using the Athena-3d scrollbar.
+  Using the Athena-3d dialog boxes.
+
+Then type make and you should have a working XEmacs.
+
+After you have verified that you have a functional editor, fire up
+your favorite mail program and send a build report to
+xemacs-beta@xemacs.org.  The build report should include
+
+1. Your hardware configuration (OS version, etc.)
+
+2. Version numbers of software in use (X11 version, system library
+   versions if appropriate, graphics library versions if appropriate).
+   If you're on a system like Linux, include all the version numbers
+   you can because chances are it makes a difference.
+
+3. The options given to configure
+
+4. The configuration report illustrated above
+
+5. Any other unusual items you feel should be brought to the attention
+   of the developers.
+
+** Creating patches for submission
+==================================
+
+When making patches you should use the `-c', or preferably if your
+diff supports it, `-u'.  Using ordinary diffs like this are
+notoriously prone to error (and this one won't in fact work, since
+I've already applied a patch to this file so the line numbers probably
+don't match up any more).
+
+$ diff -u old-file.c new-file.c
+
+-or-
+
+$ diff -c old-file.c new-file.c
+
+Also, it is helpful for me if you create the patch in the top level of
+the XEmacs source directory:
+
+$ diff -u lwlib/xlwmenu.c~ lwlib/xlwmenu.c
+
+I prefer patches to be accompanied by an update (either a raw entry or
+a patch) to the appropriate ChangeLog file, but it is not required.
+
+Also note that if you cut & paste from an xterm to an XEmacs mail buffer
+you will probably lose due to tab expansion.  The best thing to do is to
+M-x cd to the appropriate directory, and issue the command `C-u M-!' from
+within XEmacs.