Mercurial > hg > octave-terminal
changeset 14667:d95e719ef108
delete obsolete README files from etc directory
* etc/README.devel, etc/README.ftp, etc/README.mirrors,
etc/README.snapshots: Delete obsolete files.
author | John W. Eaton <jwe@octave.org> |
---|---|
date | Mon, 21 May 2012 06:28:32 -0400 |
parents | 1e77f6078692 |
children | 757f729fd41d |
files | etc/README.devel etc/README.ftp etc/README.mirrors etc/README.snapshots |
diffstat | 4 files changed, 0 insertions(+), 293 deletions(-) [+] |
line wrap: on
line diff
deleted file mode 100644 --- a/etc/README.devel +++ /dev/null @@ -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
deleted file mode 100644 --- a/etc/README.ftp +++ /dev/null @@ -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
deleted file mode 100644 --- a/etc/README.mirrors +++ /dev/null @@ -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
deleted file mode 100644 --- a/etc/README.snapshots +++ /dev/null @@ -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. -