Regression tester has web pages again
Gerald Pfeifer
pfeifer@dbai.tuwien.ac.at
Sat Feb 8 08:53:00 GMT 2003
On Mon, 3 Feb 2003, Geoffrey Keating wrote:
> The regression tester now has its web pages at
> <http://gcc.gnu.org/regtest/>.
Nice, thanks!
(In case someone wonders why this does not seem to be in CVS, I have set
up an area gcc.gnu.org where Geoff automatically rsyncs his results.)
Geoff, would you mind considering the patch below, which
o addresses some markup issues (it looks better that way on links,
for example),
o replaces Sourceware by GCC,
o and makes minor simplifications here and there.
Ah, and would you mind adding an entry to htdocs/testing/index.html ?
Thanks,
Gerald
--- index.html.orig Tue Feb 4 19:32:23 2003
+++ index.html Sat Feb 8 09:49:13 2003
@@ -7,54 +7,55 @@
<body>
<h1>GCC Automated Testing System</h1>
- The GCC automated continuous testing system is, at present, a
+ <p>The GCC automated continuous testing system is, at present, a
single machine which waits for a checkin to the <a
- href="http://gcc.gnu.org/cvs.html">Sourceware CVS archive</a>;
+ href="http://gcc.gnu.org/cvs.html">GCC CVS repository</a>;
checks out the HEAD of the CVS tree; checks that it builds (for
the native case, checks that it bootstraps); and runs the
testsuite, checking whether any test which used to pass now fails.
If any of the checks fails, it determines from the ChangeLog
- entries which checkins were made and sends mail to their authors.
+ entries which checkins were made and sends mail to their authors.</p>
<p>The tester tests a powerpc-darwin6 (MacOS 10.2.3)
- native.
+ native.</p>
+
+ <p>The following information is available:</p>
- <p>The following information is available:
<dir>
- <li><a href="status.txt">The current status of the tester</a>;
- <li><a href="log.txt.gz">The tester's logfile</a> showing the state
+ <li><a href="status.txt">current status of the tester</a>;
+ <li><a href="log.txt.gz">logfile</a> showing the state
of the tree since March, 2000;
- <li>The log output of the last build for
+ <li>log output of the last build for
<a href="native-lastbuild.txt.gz">native</a>.
- <li>The <code>.log</code> and <code>.sum</code>
+ <li><code>.log</code> and <code>.sum</code>
files from the last time the tree successfully built for
<a href="native-logsum/">native</a>.
- <li><a href="lastmail.txt.gz">The last mail that the tester sent</a>;
- <li>The list of tests that are known to pass, for
- <a href="native-passes.txt">native</a>.
+ <li><a href="lastmail.txt.gz">the last mail the tester sent</a>;
+ <li>list of <a href="native-passes.txt">tests that are known to pass
+ for native</a>.
</dir>
- All the mail from the tester is also sent to the <a
- href="http://gcc.gnu.org/lists.html">gcc mailing list</a>
- gcc-regression, which is also <a
- href="http://gcc.gnu.org/ml/gcc-regression/">archived</a>.
+ <p>All the mail from the tester is also sent to the <a
+ href="http://gcc.gnu.org/ml/gcc-regression/">gcc-regression</a>
+ mailing list.</p>
<p>The tester automatically tries to update its dejagnu, binutils and
- newlib daily, if the GCC tree is stable:
+ newlib daily, if the GCC tree is stable:</p>
+
<dir>
- <li><a href="status-objs.txt">The current status of the tester</a>;
- <li><a href="log-objs.txt.gz">The tester's logfile</a>;
- <li><a href="lastbuild-objs.txt.gz">The log output of the last build</a>;
+ <li><a href="status-objs.txt">current status</a>;
+ <li><a href="log-objs.txt.gz">logfile</a>;
+ <li><a href="lastbuild-objs.txt.gz">log output of the last build</a>.
</dir>
<p> Occasionally people ask "Why did I get sent mail? I didn't break
anything!" These are the reasons why you might get sent mail by
- the tester:
+ the tester:</p>
<dir>
<li> Your patch actually did break something. Yes, I know your
patch couldn't possibly have caused the behaviour shown, but
- stranger things have happened.
+ stranger things have happened.</li>
<li> Your patch was tested at the same time as another patch
which caused the problem. The tester doesn't have the CPU
@@ -65,7 +66,7 @@
more closely at the failure and try to eliminate patches
that couldn't possibly have caused it (for instance,
a change to the mips backend can't cause a regression test
- failure on x86 native).
+ failure on x86 native).</li>
<li> The tester sent you mail to warn you that it couldn't fully
test your patch, because the tree didn't build. This is not
@@ -74,7 +75,7 @@
a time. I believe the best way to reduce this mail is to try
to ensure that the tree doesn't get broken, not by changing
the tester. I'd rather not switch this off, because that would
- only make the underlying problem worse.
+ only make the underlying problem worse.</li>
<li> The tester sent you mail to warn you that it couldn't fully
test your patch, because there were pre-existing regressions,
@@ -84,13 +85,14 @@
handling tests were failing before your patch went in, then
your patch might have a bug but there's no way to tell).
It'll only send you one of these until the list of regressions
- changes. This isn't supposed to happen often either.
+ changes. This isn't supposed to happen often either.</li>
</dir>
- <hr>
- <address><a href="mailto:geoffk@apple.com">Geoffrey Keating</a></address>
+ <hr />
+ <address>Geoffrey Keating <a href="mailto:geoffk@apple.com">geoffk@apple.com</a></address>
<!-- Created: Fri Jun 16 14:29:12 PDT 2000 -->
<!-- hhmts start -->
<!-- hhmts end -->
</body>
</html>
More information about the Gcc
mailing list