Mercurial > hg > octave-lyh

comparison README.snapshots @ 2330:12ff450cbb1f

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
[project @ 1996-07-19 01:39:22 by jwe] Initial revision
author jwe
date Fri, 19 Jul 1996 01:49:31 +0000
parents
children b2ce28713791
comparison
equal deleted inserted replaced
2329:30c606bec7a8 2330:12ff450cbb1f
1 Octave Snapshots -- general info
2
3 Last updated: Mon May 23 18:58:05 1994
4
5 This file was adapted from a similar document written by Fred Fish and
6 used by the GDB developers.
7
8 Snapshots are an "image" of the main Octave development tree, captured
9 at a particular random instant in time. When you use the snapshots,
10 you should be able to maintain a local copy of Octave that is
11 reasonably close to the official source tree used by the Octave
12 maintainers.
13
14 The primary purpose of providing snapshots is to widen the group of
15 motivated developers that would like to help test, debug, and enhance
16 Octave, by providing you with access to the "latest and greatest"
17 source. This has several advantages, and several disadvantages.
18
19 First the advantages:
20
21 o Once we have a large base of motivated testers using the
22 snapshots, this should provide good coverage across all
23 currently supported Octave hosts and targets. If a new bug is
24 introduced in Octave due to fixing another bug or ongoing
25 development, it should become obvious much more quickly and
26 get fixed before the next general net release. This should
27 help to reduce the chances of Octave being released to the
28 general public with a major bug that went unnoticed during the
29 release cycle testing because they are machine dependent. We
30 hope to greatly improve Octave's stability and reliability by
31 involving more people and more execution environments in the
32 prerelease testing.
33
34 o With access to the latest source, any diffs that you send to fix
35 bugs or add new features should be much easier for the Octave
36 maintainers to merge into the official source base (after
37 suitable review of course). This encourages us to merge your
38 changes quicker, while they are still "fresh".
39
40 o Once your diffs are merged, you can obtain a new copy of Octave
41 containing your changes almost immediately. Thus you do not
42 have to maintain local copies of your changes for any longer
43 than it takes to get them merged into the official source
44 base. This encourages you to send in changes quicker.
45
46 And the disadvantages:
47
48 o The snapshot you get will be largely untested and of unknown
49 quality. It may fail to configure or compile. It may have
50 serious bugs. You should always keep a copy of the last known
51 working version before updating to the current snapshot, or at
52 least be able to regenerate a working version if the latest
53 snapshot is unusable in your environment for some reason.
54
55 If a production version of Octave has a bug and a snapshot has
56 the fix, and you care about stability, you should put only the
57 fix for that particular problem into your production version.
58 Of course, if you are eager to test Octave, you can use the
59 snapshot versions in your daily work, but users who have not
60 been consulted about whether they feel like testing Octave should
61 generally have something which is at least as bug free as the
62 last released version.
63
64 o Providing timely response to your questions, bug reports, and
65 submitted patches will require the Octave developers to
66 allocate time from an already thin time budget. Please try to
67 help us make this time as productive as possible. See the
68 section below about how to submit changes.
69
70
71 How to get the snapshots
72 ------------------------
73
74 The current plan is to provide a full snapshot every week or so. For
75 now, diffs from previous versions will not be available. The files
76 will be available via anonymous ftp from bevo.che.wisc.edu, in the
77 directory /private/octave in the form of a tar files compressed with
78 GNU gzip. You can ftp gzip from bevo.che.wisc.edu in the directory
79 /pub/gnu.
80
81 Even though the snapshots are available in a public place, we ask that
82 recipients not widely publicise the availability of the snapshots.
83 The motivation for this request is not to hoard them, but to avoid the
84 situation where the general Octave user base naively attempts to use
85 the snapshots, has trouble with them, complains publicly, and the
86 reputation of Octave declines because of a perception of instability
87 or lack of quality control.
88
89
90 Octave test suite
91 -----------------
92
93 A test suite is distributed as an integral part of the snapshots.
94 However, to use it you will need to get a copy of the dejagnu testing
95 framework. Snapshots of dejagnu are available alongside the Octave
96 snapshots, using the same naming conventions as the Octave snapshots.
97 Once you have installed the dejagnu framework, a simple "make check"
98 in the Octave directory should be sufficient to run the tests.
99
100 Note that the test suite is still quite limited. The test framework
101 itself might not install on your system if you have an environment
102 that is not similar to one that the Octave developers already use.
103 The tests themselves only cover a small portion of Octave features,
104 and what tests do exist for a feature are not exhaustive. New tests
105 are welcomed.
106
107
108 Getting help, Octave discussions, etc.
109 --------------------------------------
110
111 Mail sent to octave-testers@bevo.che.wisc.edu goes to everyone on the
112 list of octave testers, which should include everyone getting the
113 Octave snapshots. It is appropriate whenever you wish your mail to be
114 seen by all the testers. This would include announcements of any
115 kind, notices of intent to implement a specific enhancement (to
116 coordinate with other people on the list), etc. Before sending
117 something to octave-testers, ask yourself if what you are about to
118 send would be something you would care to see show up in your mailbox
119 if it was sent by someone else.
120
121 Do *not* send any questions about the snapshots or patches specific to
122 the snapshots to bug-octave@bevo.wisc.che.edu. Nobody there will have
123 any idea what you are talking about and it will just cause confusion.
124
125
126 Bug reports
127 -----------
128
129 Send bug reports to octave-maintainers@bevo.che.wisc.edu.
130
131 Note that since no testing is done on the snapshots, and snapshots may
132 even be made when Octave is in an inconsistent state, it may not be
133 unusual for an occasional snapshot to have a very obvious bug, such as
134 failure to compile on *any* machine. It is likely that such bugs will
135 be fixed by the next snapshot, so it really isn't necessary to report
136 them unless they persist over more than one snapshot.
137
138 Missing files should always be reported, since they usually mean there
139 is a problem with the snapshot-generating process and we won't know
140 about them unless someone tells us.
141
142 Bugs which are non-obvious, such as failure to compile on only a
143 specific machine, a new machine dependent or obscure bug (particularly
144 one not detected by the testsuite), etc. should be reported when you
145 discover them, or have a suggested patch to fix them.
146
147
148 FORMAT FOR PATCHES
149 ------------------
150
151 If you have a fix for a bug, or an enhancement to submit, send your
152 patch to octave-maintainers@bevo.che.wisc.edu. Here are some simple
153 guidelines for submitting patches:
154
155 o Use "context diffs" for patches. A typical command for
156 generating context diffs is "diff -rc octave-old octave-new".
157
158 o Use the "minimalist approach" for patches. That is, each patch
159 should address only one particular bug, new feature, etc. Do
160 not save up many unrelated changes and submit them all in one
161 big patch, since in general, the larger the patch the more
162 difficult it is for us to decide if the patch is either
163 correct or desirable. And if we find something about the
164 patch that needs to be corrected before it can be installed,
165 we would have to reject the entire patch, which might contain
166 changes which otherwise would be accepted if submitted
167 separately.
168
169 o Submit a sample ChangeLog entry with your patch. See the
170 existing Octave ChangeLog for examples of what a ChangeLog
171 entry should look like. The emacs command ^X4A will create a
172 ChangeLog entry header for you.
173
174
175 Thanks,
176
177 John W. Eaton
178 jwe@bevo.che.wisc.edu
179 University of Wisconsin-Madison
180 Department of Chemical Engineering