build status page problem

build status page problem

[Joe Buck]

I have an issue with

http://gcc.gnu.org/gcc-3.0/buildstat.html.

No distinction is made between 3.0, 3.0.1, and 3.0.2, and it's possible
that an unnoticed regression might mean that, say, 3.0.1 builds on some
obscure platform but 3.0.2 does not.  We need to include the actual
release number, there is no such thing as "3.0.x".

Re: build status page problem

[Janis Johnson]

On Wed, Dec 05, 2001 at 10:01:26AM -0800, Joe Buck wrote:
> I have an issue with
> 
> http://gcc.gnu.org/gcc-3.0/buildstat.html.
> 
> No distinction is made between 3.0, 3.0.1, and 3.0.2, and it's possible
> that an unnoticed regression might mean that, say, 3.0.1 builds on some
> obscure platform but 3.0.2 does not.  We need to include the actual
> release number, there is no such thing as "3.0.x".
> 

The assumption is that everything on the GCC 3.0 build status page
builds with all releases of 3.0.x unless it says otherwise.  So far
there's only one note otherwise, for s390-linux-gnu which is supported
beginning with 3.0.1.

I'd prefer to keep that assumption.  If there's a regression that
prevents a target from building with a particular release we can add a
note to that effect for that target.

Janis

Re: build status page problem

[David Edelsohn]

>>>>> Janis Johnson writes:

Janis> The assumption is that everything on the GCC 3.0 build status page
Janis> builds with all releases of 3.0.x unless it says otherwise.  So far
Janis> there's only one note otherwise, for s390-linux-gnu which is supported
Janis> beginning with 3.0.1.

Janis> I'd prefer to keep that assumption.  If there's a regression that
Janis> prevents a target from building with a particular release we can add a
Janis> note to that effect for that target.

	The problem is that we cannot tell from the page what reports we
actually have received.  If we have a report that some target worked with
3.0.1 but no report for 3.0.2, we cannot tell if it works and it may
discourage someone from testing that new release and reporting the result.

David

Re: build status page problem

[Joe Buck]

I wrote:
> > I have an issue with
> > 
> > http://gcc.gnu.org/gcc-3.0/buildstat.html.
> > 
> > No distinction is made between 3.0, 3.0.1, and 3.0.2, and it's possible
> > that an unnoticed regression might mean that, say, 3.0.1 builds on some
> > obscure platform but 3.0.2 does not.  We need to include the actual
> > release number, there is no such thing as "3.0.x".

Janis wrote:
> The assumption is that everything on the GCC 3.0 build status page
> builds with all releases of 3.0.x unless it says otherwise.  So far
> there's only one note otherwise, for s390-linux-gnu which is supported
> beginning with 3.0.1.

Sorry if this sounds like I'm picking on you ...

But how are you assuring this?  Do you have three success reports for each
platform listed?  (one each for 3.0, 3.0.1, and 3.0.2)?  When 3.0.3 is
released, will you then be sure to have four success reports for each?

Re: build status page problem

[Janis Johnson]

On Wed, Dec 05, 2001 at 01:21:45PM -0500, David Edelsohn wrote:
> >>>>> Janis Johnson writes:
> 
> Janis> The assumption is that everything on the GCC 3.0 build status page
> Janis> builds with all releases of 3.0.x unless it says otherwise.  So far
> Janis> there's only one note otherwise, for s390-linux-gnu which is supported
> Janis> beginning with 3.0.1.
> 
> Janis> I'd prefer to keep that assumption.  If there's a regression that
> Janis> prevents a target from building with a particular release we can add a
> Janis> note to that effect for that target.
> 
> 	The problem is that we cannot tell from the page what reports we
> actually have received.  If we have a report that some target worked with
> 3.0.1 but no report for 3.0.2, we cannot tell if it works and it may
> discourage someone from testing that new release and reporting the result.
> 
> David

We don't get a flood of new reports for existing entries when a new
version of GCC is released, and I don't think that such reports would be
particularly useful.  If there is an entry for a target and someone has
problems building it on some version of 3.0.x, then they should report
the problem, along with the fact that a successful build has been
reported.

Ideally, when a new release comes out people will build it and send in
their test results, which is more useful information than the build
status list.  I see the build status list as initial information about
whether GCC 3.0.x is known to work on a particular target.  There are
still a lot of variables that could prevent even the same version that
was reported from building on the same target with a slightly different
environment, so I hope that the existence of a target on the list
doesn't prevent new testing of it for new releases.

It would be useful to have a script similar to contrib/test_summary to
generate a message for reporting a successful build.  Use of that script
would ensure that we get all of the relevant information in a report of
a successful build, including the configure flags to know whether all
languages were built, and versions of other relevant software on a
GNU/Linux system.

Janis

Re: build status page problem

[Janis Johnson]

OK, I now agree that it would be a good idea to include the versions for
reports of successful GCC builds.  I'd like to request that reports
include additional relevant information, and add links to the archived
mail messages containing the reports so that the additional information
is not lost if it doesn't fit neatly into the format of the status page.

Here's how I'd like to change the Final Installation documentation for
the mainline, with similar changes to 3.0, hopefully in time for the
3.0.3 release.

--- gcc/doc/install.texi.orig	Sun Dec  9 12:13:19 2001
+++ gcc/doc/install.texi	Sun Dec  9 12:13:32 2001
@@ -1244,18 +1244,46 @@ If you built a released version of GCC t
 quickly review the build status page for
 @uref{http://gcc.gnu.org/gcc-3.0/buildstat.html,,3.0} or
 @uref{http://gcc.gnu.org/gcc-2.95/buildstat.html,,2.95}.
-If your system is not listed, send a note to
+If your system is not listed for the version of GCC that you built,
+send a note to
 @email{gcc@@gcc.gnu.org} indicating
 that you successfully built and installed GCC.
+Include the following information:
 
-Include the output from running @file{@var{srcdir}/config.guess}.  (Do
+@itemize @bullet
+@item
+Output from running @file{@var{srcdir}/config.guess}.  (Do
 not send us the @file{config.guess} file itself, just the one-line output from
-running it!)  Also specify which version you built.
-If the build was for GNU/Linux, also include the distribution name and version
-(e.g., Red Hat 7.1 or Debian 2.2.3, available from @file{/etc/issue})
-and the version of glibc you used; for RPM-based systems like Red Hat,
+running it!)
+
+@item
+The output of @samp{gcc -v} for your newly installed gcc.
+This tells us which version of GCC you built and the options you passed to
+configure.
+
+@item
+If the build was for GNU/Linux, also include:
+@itemize @bullet
+@item
+The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3);
+this is available from @file{/etc/issue}.
+
+@item
+The version of the Linux kernel, available from @samp{uname --version}.
+
+@item
+The version of glibc you used; for RPM-based systems like Red Hat,
 Mandrake, and SuSE type @samp{rpm -q glibc} to get the glibc version,
 and on systems like Debian and Progeny use @samp{dpkg -l libc6}.
+@end itemize
+For other systems, you can include similar information if you think it is
+relevant.
+
+@item
+Any other information that you think would be useful to people building
+GCC on the same configuration.  The new entry in the build status list
+will include a link to the archived copy of your message.
+@end itemize
 
 We'd also like to know if the
 @ifnothtml

I can probably locate the messages reporting the existing successful
builds for GCC 3.0 and will try to add those versions to the status list
before 3.0.3 is released, when there will be a flurry of new reports.

Janis

Re: build status page problem

[Gerald Pfeifer]

On Sun, 9 Dec 2001, Janis Johnson wrote:
> Here's how I'd like to change the Final Installation documentation for
> the mainline, with similar changes to 3.0, hopefully in time for the
> 3.0.3 release.

This looks fine (for both branches) with minor changes:

> --- gcc/doc/install.texi.orig	Sun Dec  9 12:13:19 2001
> +++ gcc/doc/install.texi	Sun Dec  9 12:13:32 2001
> +Output from running @file{@var{srcdir}/config.guess}.  (Do
>  not send us the @file{config.guess} file itself, just the one-line output from
> -running it!)  Also specify which version you built.

I'd write "Do not send us that file itself..." (even though it has been
the other way already before your patch)".

> +The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3);
> +this is available from @file{/etc/issue}.

"...these/this should be available..." (as we cannot be sure about all
systems).

Thanks!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/