--- a/etc/README.devel	Mon May 21 02:31:05 2012 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,82 +0,0 @@
-This directory contains development releases of Octave.
-
-If you want a stable, well-tested version of Octave, you should be
-looking at ftp://ftp.gnu.org/gnu/octave.
-
-Development releases are provided for people who want to help test,
-debug, and improve Octave.  Very little testing is done before making
-the development releases and they may even be made when Octave is in
-an inconsistent state.  It is possible that you will encounter a
-very obvious bug, such as a failure to compile on *any* machine.  It is
-likely that such bugs will be fixed by the next development release,
-so it really isn't necessary to report them unless they persist over
-more than one release.
-
-Please DO report other bugs in the development releases as soon as you
-find them.  Bugs should be reported to the bug tracker at
-'http://bugs.octave.org'.  Please read read the bug reporting
-guidelines (http://www.gnu.org/software/octave/bugs.html) before
-submitting an item.
-
-If you have a fix for a bug, or an enhancement to submit, send your
-patch to maintainers@octave.org or submit it to the patch
-tracker at 'http://savannah.gnu.org/patch/?group=octave'. 
-
-By adhering to the following guidelines you can minimize the work that
-Octave maintainers need to do to apply your patch.  Maintaining Octave
-is a lot of work in the best of circumstances, and we can't keep up
-unless you do your best to help.
-
-   * Send an explanation with your changes of what problem they fix or
-     what improvement they bring about.  For a bug fix, just include a
-     copy of the bug report, and explain why the change fixes the bug.
-
-   * Always include a proper bug report for the problem you think you
-     have fixed.  We need to convince ourselves that the change is
-     right before installing it.  Even if it is right, we might have
-     trouble judging it if we don't have a way to reproduce the problem.
-
-   * Include all the comments that are appropriate to help people
-     reading the source in the future understand why this change was
-     needed.
-
-   * Don't mix together changes made for different reasons.  Send them
-     _individually_.
-
-     If you make two changes for separate reasons, then we might not
-     want to install them both.  We might want to install just one.
-
-   * Use `diff -c' to make your diffs.  Diffs without context are hard
-     for us to install reliably.  More than that, they make it hard for
-     us to study the diffs to decide whether we want to install them.
-     Unified diff format is better than contextless diffs, but not as
-     easy to read as `-c' format.
-
-     If you have GNU diff, use `diff -cp', which shows the name of the
-     function that each change occurs in.
-
-   * Write the change log entries for your changes.
-
-     Read the `ChangeLog' file to see what sorts of information to put
-     in, and to learn the style that we use.  The purpose of the
-     change log is to show people where to find what was changed.  So
-     you need to be specific about what functions you changed; in
-     large functions, it's often helpful to indicate where within the
-     function the change was made.
-
-     On the other hand, once you have shown people where to find the
-     change, you need not explain its purpose.  Thus, if you add a new
-     function, all you need to say about it is that it is new.  If you
-     feel that the purpose needs explaining, it probably does--but the
-     explanation will be much more useful if you put it in comments in
-     the code.
-
-     If you would like your name to appear in the header line for who
-     made the change, send us the header line.
-
-If you would like to be on the very sharpest part of the bleeding
-edge, you can now use Mercurial to access Octave's current development
-sources.  Instructions for checking out a copy are available on the
-web at http://www.gnu.org/software/octave/download.html.
-
-Last updated: Sat Jan 22 21:26:18 PST 2011

--- a/etc/README.ftp	Mon May 21 02:31:05 2012 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,38 +0,0 @@
-This directory contains the source for Octave, a high-level interactive
-language for solving numerical problems.  See the file README for more general
-information, and the file NEWS for a list of recent changes.
-
-Binary distributions:
---------------------
-
-Octave binaries are not distributed from this site.
-
-Packaged versions of Octave for various GNU/Linux systems are available
-with the major GNU/Linux distributions (Debian, Ubuntu, Red Hat, SUSE, etc.).
-
-Binary distributions of Octave for Mac OS X are available from both Fink
-and MacPorts.
-
-  http://www.finkproject.com
-  http://www.macports.org/
-
-The file README.Windows provides instructions for installing Octave on
-Windows systems.
-
-A note about .gz files:
-----------------------
-
-Files with names ending in `.gz' have been compressed with `gzip'.
-
-Unlike the compress utility, gzip is free of any known software
-patents and tends to compress better anyway.  Gzip can uncompress
-`compress'-compressed files too, so you can install it as "uncompress"
-and use it to handle both types of files.
-
-The gzip program is available in the directory /pub/gnu in shar, tar,
-or gzipped tar format (for those who already have a prior version of
-gzip and want faster data transmission).  It works on virtually every
-unix system, MSDOS, OS/2, and VMS.
-
-
-Last updated: Thu Jan 20 10:14:49 PST 2011

--- a/etc/README.mirrors	Mon May 21 02:31:05 2012 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,12 +0,0 @@
-If you have trouble transferring Octave from this site, you might try
-one of those listed below.  They mirror the /pub/octave directory on
-ftp.octave.org
-
-FTP:
-
-  site                          directory
-  ----                          ---------
-  ftp.u-aizu.ac.jp              /pub/SciEng/numanal/Octave
-  mirrors.fe.up.pt              /pub/octave
-
-Last updated: Mon Jan 10 21:26:17 PST 2011

--- a/etc/README.snapshots	Mon May 21 02:31:05 2012 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,161 +0,0 @@
-Octave Snapshots -- general info
-
-Snapshots are an "image" of the main Octave development tree, captured
-at a particular random instant in time.  When you use the snapshots,
-you should be able to maintain a local copy of Octave that is
-reasonably close to the official source tree used by the Octave
-maintainers.
-
-The primary purpose of providing snapshots is to widen the group of
-motivated developers that would like to help test, debug, and enhance
-Octave, by providing you with access to the "latest and greatest"
-source.  This has several advantages, and several disadvantages.
-
-    First the advantages:
-
-    o	Once we have a large base of motivated testers using the
-	snapshots, this should provide good coverage across all
-	currently supported Octave hosts and targets.  If a new bug is
-	introduced in Octave due to fixing another bug or ongoing
-	development, it should become obvious much more quickly and
-	get fixed before the next general net release.  This should
-	help to reduce the chances of Octave being released to the
-	general public with a major bug that went unnoticed during the
-	release cycle testing because they are machine dependent.  We
-	hope to greatly improve Octave's stability and reliability by
-	involving more people and more execution environments in the
-	prerelease testing.
-
-    o	With access to the latest source, any diffs that you send to fix
-	bugs or add new features should be much easier for the Octave
-	maintainers to merge into the official source base (after
-	suitable review of course).  This encourages us to merge your
-	changes quicker, while they are still "fresh".
-
-    o	Once your diffs are merged, you can obtain a new copy of Octave
-	containing your changes almost immediately.  Thus you do not
-	have to maintain local copies of your changes for any longer
-	than it takes to get them merged into the official source
-	base.  This encourages you to send in changes quicker.
-
-    And the disadvantages:
-
-    o	The snapshot you get will be largely untested and of unknown
-	quality.  It may fail to configure or compile.  It may have
-	serious bugs.  You should always keep a copy of the last known
-	working version before updating to the current snapshot, or at
-	least be able to regenerate a working version if the latest
-	snapshot is unusable in your environment for some reason.
-
-	If a production version of Octave has a bug and a snapshot has
-	the fix, and you care about stability, you should put only the
-	fix for that particular problem into your production version.
-	Of course, if you are eager to test Octave, you can use the
-	snapshot versions in your daily work, but users who have not
-	been consulted about whether they feel like testing Octave should
-	generally have something which is at least as bug free as the
-	last released version.
-
-    o	Providing timely response to your questions, bug reports, and
-	submitted patches will require the Octave developers to
-	allocate time from an already thin time budget.  Please try to
-	help us make this time as productive as possible.  See the
-	section below about how to submit changes.
-
-
-How to get the snapshots
-------------------------
-
-The current plan is to provide a full snapshot every week or so.  For
-now, diffs from previous versions will not be available.  The files
-will be available via anonymous ftp from ftp.octave.org, in the
-directory /private/octave in the form of a tar files compressed with
-GNU gzip.  You can ftp gzip from ftp.octave.org in the directory
-/pub/gnu.
-
-Even though the snapshots are available in a public place, we ask that
-recipients not widely publicize the availability of the snapshots.
-The motivation for this request is not to hoard them, but to avoid the
-situation where the general Octave user base naively attempts to use
-the snapshots, has trouble with them, complains publicly, and the
-reputation of Octave declines because of a perception of instability
-or lack of quality control.
-
-
-Octave test suite
------------------
-
-A test suite is distributed as an integral part of the snapshots.
-However, to use it you will need to get a copy of the dejagnu testing
-framework.  Snapshots of dejagnu are available alongside the Octave
-snapshots, using the same naming conventions as the Octave snapshots.
-Once you have installed the dejagnu framework, a simple "make check"
-in the Octave directory should be sufficient to run the tests.
-
-Note that the test suite is still quite limited.  The test framework
-itself might not install on your system if you have an environment
-that is not similar to one that the Octave developers already use.
-The tests themselves only cover a small portion of Octave features,
-and what tests do exist for a feature are not exhaustive.  New tests
-are welcomed.
-
-
-Bug reports
------------
-
-Send bug reports to maintainers@octave.org.
-
-Note that since no testing is done on the snapshots, and snapshots may
-even be made when Octave is in an inconsistent state, it may not be
-unusual for an occasional snapshot to have a very obvious bug, such as
-failure to compile on *any* machine.  It is likely that such bugs will
-be fixed by the next snapshot, so it really isn't necessary to report
-them unless they persist over more than one snapshot.
-
-Missing files should always be reported, since they usually mean there
-is a problem with the snapshot-generating process and we won't know
-about them unless someone tells us.
-
-Bugs which are non-obvious, such as failure to compile on only a
-specific machine, a new machine dependent or obscure bug (particularly
-one not detected by the testsuite), etc. should be reported when you
-discover them, or have a suggested patch to fix them.
-
-
-FORMAT FOR PATCHES
-------------------
-
-If you have a fix for a bug, or an enhancement to submit, send your
-patch to maintainers@octave.org.  Here are some simple guidelines for
-submitting patches:
-
-    o	Use "context diffs" for patches.  A typical command for
-	generating context diffs is "diff -rc octave-old octave-new".
-
-    o	Use the "minimalist approach" for patches.  That is, each patch
-	should address only one particular bug, new feature, etc.  Do
-	not save up many unrelated changes and submit them all in one
-	big patch, since in general, the larger the patch the more
-	difficult it is for us to decide if the patch is either
-	correct or desirable.  And if we find something about the
-	patch that needs to be corrected before it can be installed,
-	we would have to reject the entire patch, which might contain
-	changes which otherwise would be accepted if submitted
-	separately.
-
-    o	Submit a sample ChangeLog entry with your patch.  See the
-	existing Octave ChangeLog for examples of what a ChangeLog
-	entry should look like.  The emacs command ^X4A will create a
-	ChangeLog entry header for you.
-
-
-Thanks,
-
-John W. Eaton
-jwe@octave.org
-
-Wed, 31 Oct 2007 16:31:54 EDT
-
-This file was adapted from a similar document written by Fred Fish and
-used by the GDB developers.
-