Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)

Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)

[Nathanael Nerode]

Wolfgang noted:

> [Port maintainers:]
> - The state of reports in the "bootstrap" and "target" categories is
>   probably best described by "neglected". Since not many people can test
>   them, it really requires more attention by the port maintainers. The 
>   majority of our 1800 or so unfixed reports are in these categories, and
>   many of them are in "open" state since their filing -- often two years
>   or more ago. I have tried to make an effort to indicate in the synopsis
>   of many of them for which target they are, but that doesn't seem to
>   incite maintainers to look at them :-( If nobody cares about these
>   reports, we could just as well delete them, since the bug database is
>   worthless then.

How's this for a (slightly radical) proposal?

1. Platforms for which no 3.x build has been reported: Close all 
target-specific bugs immediately and possibly deprecate the platform. 
These are the ones which just aren't going to get worked on.  I would 
make an exception for platforms where the port maintainers are very 
active at fixing bugs, but I don't think I *need* to, since they 
probably have reported builds.  This means there won't be any bugs open 
against 'experimental' platforms, which is fine by me.

2. Platforms for which builds work, but bugs sit open indefinitely: 
Contact the port maintainers.  If there are no active port maintainers, 
or the port maintainers aren't interested in that specific platform, 
close all the bugs and possibly deprecate the platform.

If there are active port maintainers, the bugs should either get fixed, 
be closed as unreproducible, or be noted as 'unfixable' somewhere; but 
I'm guessing that bugs in actively used platforms aren't actually the 
majority of the 1800 reports.  If they are, we have a different problem.

If this sounds like a good proposal, I can start closing reports against 
dead ports in my spare time...

--Nathanael

Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)

[Joseph S. Myers]

On Sat, 22 Feb 2003, Nathanael Nerode wrote:

> 1. Platforms for which no 3.x build has been reported: Close all 
> target-specific bugs immediately and possibly deprecate the platform. 

We should close such bugs when support for the target is *removed* from
mainline, not when the target is deprecated.  (And this is something that
does need to be done as part of the target removal process, just as stray
references to the target and its problems need to be removed from
trouble.texi and elsewhere in the manual and sources - preferably as part
of the target removal rather than left for someone else to do later.)

This may make sense for native platforms, but in general people do not
seem to report their cross builds at all or submit testresults for them.

I would like to see a list of all supported platforms (which I think ought
to go in install.texi, host/target specific notes, even where there are no
specific notes for a system, just so that users can see exactly which
systems are supported and what their target triples are) together with the
list of those native systems which haven't had a 3.x build report or
testresults sent and so are candidates for deprecation.  (Also indicate
which if any of those have had any user interest at all - questions asked
about them, or bug reports saying they don't work.)

Also remember that some target-specific bugs are in fact bugs in generic
code that just happen only to show up on certain platforms.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)

[Nathanael Nerode]

Joseph S. Myers wrote:
> On Sat, 22 Feb 2003, Nathanael Nerode wrote:
> 
> 
>>1. Platforms for which no 3.x build has been reported: Close all 
>>target-specific bugs immediately and possibly deprecate the platform. 
> 
> 
> We should close such bugs when support for the target is *removed* from
> mainline, not when the target is deprecated.  (And this is something that
> does need to be done as part of the target removal process, just as stray
> references to the target and its problems need to be removed from
> trouble.texi and elsewhere in the manual and sources - preferably as part
> of the target removal rather than left for someone else to do later.)
> 
> This may make sense for native platforms, but in general people do not
> seem to report their cross builds at all or submit testresults for them.
How sad...

> I would like to see a list of all supported platforms (which I think ought
> to go in install.texi, host/target specific notes, even where there are no
> specific notes for a system, just so that users can see exactly which
> systems are supported and what their target triples are) together with the
This would be a very, very good idea.

> list of those native systems which haven't had a 3.x build report or
> testresults sent and so are candidates for deprecation.  (Also indicate
> which if any of those have had any user interest at all - questions asked
> about them, or bug reports saying they don't work.)
> 
> Also remember that some target-specific bugs are in fact bugs in generic
> code that just happen only to show up on certain platforms.
Yeah.  I'm trying to make suggestions which will help clear the bug 
reports down to a managable quantity, though.  Bugs which can't be 
reproduced on maintained systems have no value in the bug tracking 
system, unfortunately.

For another thought, I strongly suggest that any bug in feedback and 
without feedback for 3 months be closed, and that this be documented 
somewhere.  (The standard I've been using is 6 months, which I think is 
overly generous.)

Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)

[Gerald Pfeifer]

On Sat, 22 Feb 2003, Nathanael Nerode wrote:
> For another thought, I strongly suggest that any bug in feedback and
> without feedback for 3 months be closed, and that this be documented
> somewhere.

http://gcc.gnu.org/gnatswrite.html already documents something similiar
(at the end).

In http://gcc.gnu.org/ml/gcc/2003-02/msg01258.html I have made a suggestion
on how to improve the documentation and any chance like that is hereby pre-
approved.

Gerald

PS: I'd do it by myself, but I'll go offline for 2+ weeks shortly...
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)

[Chester R. Hosey]

----- Original Message -----
From: "Gerald Pfeifer" <pfeifer@dbai.tuwien.ac.at>
To: "Nathanael Nerode" <neroden@twcny.rr.com>
Cc: <gcc@gcc.gnu.org>
Sent: Saturday, February 22, 2003 4:03 AM
Subject: Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going
up)


> On Sat, 22 Feb 2003, Nathanael Nerode wrote:
> > For another thought, I strongly suggest that any bug in feedback and
> > without feedback for 3 months be closed, and that this be documented
> > somewhere.
>
> http://gcc.gnu.org/gnatswrite.html already documents something similiar
> (at the end).
>
> In http://gcc.gnu.org/ml/gcc/2003-02/msg01258.html I have made a
suggestion
> on how to improve the documentation and any chance like that is hereby
pre-
> approved.
>
> Gerald
,>
> PS: I'd do it by myself, but I'll go offline for 2+ weeks shortly...
> --
> Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at
http://www.pfeifer.com/gerald/
>

I'm sort of a gimp and wasn't sure how to handle having diff add/delete
files other than -N, so that's how I handled adding bugs/tracking.html (and
removing gnatswrite.html). Diff is against a fresh checkout of CVS module
wwwdocs.

If I can/should submit in a slightly different format, let me know. ;-)

All HTML validated at w3.org as required by "Contributing to GCC".


2003-02-23  Chester Hosey  chosey@tr0n.com

        * Split gnatswrite.html into gnats.html and bugs/tracking.html

diff -rupN wwwdocs.orig/htdocs/bugs/tracking.html
wwwdocs/htdocs/bugs/tracking.html
--- wwwdocs.orig/htdocs/bugs/tracking.html	1969-12-31
19:00:00.000000000 -0500
+++ wwwdocs/htdocs/bugs/tracking.html	2003-02-23 02:35:01.000000000 -0500
@@ -0,0 +1,119 @@
+<html>
+
+<head>
+<title>Maintaining the GCC GNATS database</title>
+</head>
+
+<body>
+<h1>Managing Bugs (GNATS and the test-suite)</h1>
+
+<p>This section contains information mostly intended for GCC
+contributors.</p>
+
+<p>If you find a bug, but you are not fixing it (yet):</p>
+<ol>
+<li>Create a (minimal) test-case.</li>
+<li>Add the test-case to our test-suite, marking it as XFAIL unless
+the bug is a regression.</li>
+<li>Add a bug report referencing the test-case to GNATS.</li>
+</ol>
+
+<p>If you want to provide additional information in the bug tracking
+system about a reported bug:</p>
+<ol>
+<li>If the bug is a segmentation fault in the compiler,
+<a href="bugs/segfault.html">provide information about its location</a>.
+</li>
+<li><a href="bugs/minimize.html">Minimize the test case</a>.</li>
+<li>Try the test case with earlier and later versions of GCC to
+determine which versions it affects and whether it is a regression.
+If it is a regression, <a href="bugs/reghunt.html">identify the
+patch</a> that introduced it.</li>
+</ol>
+
+<p>If you fix a bug for which there is already a GNATS entry:</p>
+<ol>
+<li>Remove the XFAIL on the test-case.</li>
+<li>Close the bug report in GNATS.</li>
+</ol>
+
+<p>If you find a bug, and you are fixing it right then:</p>
+<ol>
+<li>Create a (minimal) test-case.</li>
+<li>Add the test-case to our test-suite, marking it as PASS.</li>
+<li>Check in your fixes.</li>
+</ol>
+
+<h1>Maintainer's View of Fields</h1>
+
+<p>As a GCC-specific convention, we will attach a special meaning to
+some fields. The State field should be used in the following way:</p>
+
+<dl>
+
+<dt>open</dt>
+<dd>The PR has been filed and the responsible person(s) notified.</dd>
+
+<dt>analyzed</dt>
+
+<dd>A maintainer has verified that this is indeed a bug in GCC. Every
+once in a while, old reports will need to be rechecked, to find out
+whether the bug still exists. At that time, an indication should be
+left in the report who tested the bug and when.</dd>
+
+<dt>feedback</dt>
+<dd>The submitter was asked for further information, or asked to try
+out a patch. The PR remains in that state until the submitter
+responds.</dd>
+
+<dt>suspended</dt>
+<dd>Work on the problem has been postponed.  This happens if a timely
+solution is not possible or is not cost-effective at the present time.
+The PR continues to exist, though a solution is not being actively
+sought. If the problem cannot be solved at all, it should be closed
+rather than suspended.</dd>
+
+</dl>
+
+<p>In addition, the <b>high</b> priority is reserved to maintainers in
+GCC, indicating that a certain problem must be solved before the next
+version of GCC is released.</p>
+
+<h2>Procedures and Policies</h2>
+
+<p><strong>Bugs that are in state "feedback"</strong> because they lack
+information that is necessary for reproducing the problem can be closed
+if no response was received for three months.</p>
+
+<p><strong>Regressions</strong> should be explicitly marked as such.
+The synopsis line should read</p>
+
+<blockquote>
+[&lt;branches-to-fix&gt; regression] &lt;rest-of-synopsis&gt;
+</blockquote>
+
+<p>where &lt;branches-to-fix&gt; is the list of <em>maintained</em>
+branches (separated by slashes) that need fixing. A regression should
+start with priority "<strong>high</strong>" to bring it to attention.
+It may be downgraded later if a defect is not important enough to justify
+"high priority".</p>
+
+<p><strong>Bugs in category "bootstrap"</strong> that refer to older
+releases or snapshots/CVS versions should be put into state "feedback",
+asking the reporter whether she can still reproduce the problem and to
+report her findings in any case (whether positive or negative).</p>
+
+<ul>
+<li>If the response is "works now", close the report,</li>
+<li>if the reponse is "still broken", change the state to "open", and</li>
+<li>if no response arrives, close the PR after three months.</li>
+</ul>
+
+<p><strong>Bugs in category "ice-on-illegal-code"</strong>, where gcc
+emits a sensible error message before issuing an ICE (the ICE will be
+replaced by the message "confused by earlier errors, bailing out" in
+release versions) should get "low" priority.
+It should be noted in the audit trail, that the error recovery fails.</p>
+
+</body>
+</html>
diff -rupN wwwdocs.orig/htdocs/bugs.html wwwdocs/htdocs/bugs.html
--- wwwdocs.orig/htdocs/bugs.html	2003-02-23 02:28:45.000000000 -0500
+++ wwwdocs/htdocs/bugs.html	2003-02-23 02:36:11.000000000 -0500
@@ -24,7 +24,6 @@
  <li><a href="#pch">Detailed bug reporting instructions when using a
precompiled header</a></li>
  </ul>
 </li>
-<li><a href="#manage">Managing Bugs (GNATS and the test-suite)</a></li>
 <li><a href="#known">Frequently Reported Bugs in GCC</a>
  <ul>
  <li><a href="#general">General</a></li>
@@ -276,45 +275,6 @@ use it.</p>
 header.  It is likely to be very large and we can't use it to
 reproduce the problem.</p>

-<h1><a name="manage">Managing Bugs (GNATS and the test-suite)</a></h1>
-
-<p>This section contains information mostly intended for GCC
-contributors.</p>
-
-<p>If you find a bug, but you are not fixing it (yet):</p>
-<ol>
-<li>Create a (minimal) test-case.</li>
-<li>Add the test-case to our test-suite, marking it as XFAIL unless
-the bug is a regression.</li>
-<li>Add a bug report referencing the test-case to GNATS.</li>
-</ol>
-
-<p>If you want to provide additional information in the bug tracking
-system about a reported bug:</p>
-<ol>
-<li>If the bug is a segmentation fault in the compiler,
-<a href="bugs/segfault.html">provide information about its location</a>.
-</li>
-<li><a href="bugs/minimize.html">Minimize the test case</a>.</li>
-<li>Try the test case with earlier and later versions of GCC to
-determine which versions it affects and whether it is a regression.
-If it is a regression, <a href="bugs/reghunt.html">identify the
-patch</a> that introduced it.</li>
-</ol>
-
-<p>If you fix a bug for which there is already a GNATS entry:</p>
-<ol>
-<li>Remove the XFAIL on the test-case.</li>
-<li>Close the bug report in GNATS.</li>
-</ol>
-
-<p>If you find a bug, and you are fixing it right then:</p>
-<ol>
-<li>Create a (minimal) test-case.</li>
-<li>Add the test-case to our test-suite, marking it as PASS.</li>
-<li>Check in your fixes.</li>
-</ol>
-
 <hr />

 <h1><a name="known">Frequently Reported Bugs in GCC</a></h1>
diff -rupN wwwdocs.orig/htdocs/cvswrite.html wwwdocs/htdocs/cvswrite.html
--- wwwdocs.orig/htdocs/cvswrite.html	2002-12-07 08:51:44.000000000 -0500
+++ wwwdocs/htdocs/cvswrite.html	2003-02-23 02:47:10.000000000 -0500
@@ -13,7 +13,7 @@

 <p>We have read/write access to the CVS repository available for all
 our significant developers. Maintainers are also encouraged to edit
-the <a href="gnatswrite.html">GNATS database</a>.</p>
+the <a href="gnats.html">GNATS database</a>.</p>

 <hr />
 <h2>Contents</h2>
diff -rupN wwwdocs.orig/htdocs/gnats.html wwwdocs/htdocs/gnats.html
--- wwwdocs.orig/htdocs/gnats.html	2003-02-23 02:28:45.000000000 -0500
+++ wwwdocs/htdocs/gnats.html	2003-02-23 02:36:30.000000000 -0500
@@ -172,5 +172,59 @@ does not foo", "objc crashes when doing

 </dl>

+
+<h1>Accessing the database</h1>
+
+<p>In order to manage PRs, you need an account for our GNATS database
+which is different from the authenticated access to the CVS repository
+(though the username will be the same). If you have CVS write access
+or a "senior" GCC Maintainer agrees that
+you should have a GNATS account, fill in
+<a href="http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi">this form</a>
+with "GNATS access only" in the SSH key part.</p>
+
+<p>Also, when you manage PRs, make sure mail-forwarding from
+gcc.gnu.org to your normal email account is activated; otherwise
+replies to status change notifications will bounce.</p>
+
+<p>You can access the database either via <a
+href="http://gcc.gnu.org/cgi-bin/gnatsweb.pl">gnatsweb</a>, or via
+the gnatsd running on gcc.gnu.org.</p>
+
+<h2>Using gnatsd and Emacs</h2>
+
+<p>Check out GNATS v3 from
+<code>:pserver:anoncvs@sources.redhat.com:/cvs/gnats</code> by means of
+the <code>-r gnats-v3-branch</code> option. Build and install that.</p>
+
+<p>Add the the ../share/emacs/site-lisp/ directory installed by the GNATS
+build to your <code>load-path</code> in order to pick up the gnats library.
+</p>
+
+<p>Finally, add the following entries to your <code>.emacs</code> file</p>
+
+<blockquote><code>
+  (load-library "gnats")<br />
+  (setq gnats:network-server "gcc.gnu.org")<br />
+  (setq gnats:userid "YourUserName")<br />
+  (setq gnats:password "YourGNATSPassword")<br />
+  (setq gnats:alias "gcc")<br />
+  (autoload 'edit-pr "gnats"
+            "Command to edit a problem report." t)<br />
+  (autoload 'query-pr "gnats"
+            "Command to query information about problem reports." t)
+</code></blockquote>
+
+<p>(If you already have PRMS support set up in you <code>.emacs</code>
+file, remove that first, to avoid conflicts with duplicate symbols.)</p>
+
+
+<h1>Adding Reports</h1>
+
+<p>To add a new report, you should be familiar with the <a
+href="gnats.html">general instructions</a>. In addition, you might
+want to use the gccbug.el Emacs-Lisp file to aid putting forwarding
+bug reports from gcc-bugs into the gnats database.</p>
+
 </body>
 </html>
diff -rupN wwwdocs.orig/htdocs/gnatswrite.html
wwwdocs/htdocs/gnatswrite.html
--- wwwdocs.orig/htdocs/gnatswrite.html	2003-02-23 02:28:45.000000000 -0500
+++ wwwdocs/htdocs/gnatswrite.html	1969-12-31 19:00:00.000000000 -0500
@@ -1,133 +0,0 @@
-<html>
-
-<head>
-<title>Maintaining the GCC GNATS installation</title>
-</head>
-
-<body>
-<h1>Accessing the database</h1>
-
-<p>In order to manage PRs, you need an account for our GNATS database
-which is different from the authenticated access to the CVS repository
-(though the username will be the same). If you have CVS write access
-or a "senior" GCC Maintainer agrees that
-you should have a GNATS account, fill in
-<a href="http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi">this form</a>
-with "GNATS access only" in the SSH key part.</p>
-
-<p>Also, when you manage PRs, make sure mail-forwarding from
-gcc.gnu.org to your normal email account is activated; otherwise
-replies to status change notifications will bounce.</p>
-
-<p>You can access the database either via <a
-href="http://gcc.gnu.org/cgi-bin/gnatsweb.pl">gnatsweb</a>, or via
-the gnatsd running on gcc.gnu.org.</p>
-
-<h2>Using gnatsd and Emacs</h2>
-
-<p>Check out GNATS v3 from
-<code>:pserver:anoncvs@sources.redhat.com:/cvs/gnats</code> by means of
-the <code>-r gnats-v3-branch</code> option. Build and install that.</p>
-
-<p>Add the the ../share/emacs/site-lisp/ directory installed by the GNATS
-build to your <code>load-path</code> in order to pick up the gnats library.
-</p>
-
-<p>Finally, add the following entries to your <code>.emacs</code> file</p>
-
-<blockquote><code>
-  (load-library "gnats")<br />
-  (setq gnats:network-server "gcc.gnu.org")<br />
-  (setq gnats:userid "YourUserName")<br />
-  (setq gnats:password "YourGNATSPassword")<br />
-  (setq gnats:alias "gcc")<br />
-  (autoload 'edit-pr "gnats"
-            "Command to edit a problem report." t)<br />
-  (autoload 'query-pr "gnats"
-            "Command to query information about problem reports." t)
-</code></blockquote>
-
-<p>(If you already have PRMS support set up in you <code>.emacs</code>
-file, remove that first, to avoid conflicts with duplicate symbols.)</p>
-
-
-<h1>Adding Reports</h1>
-
-<p>To add a new report, you should be familiar with the <a
-href="gnats.html">general instructions</a>. In addition, you might
-want to use the gccbug.el Emacs-Lisp file to aid putting forwarding
-bug reports from gcc-bugs into the gnats database.</p>
-
-<h1>Maintainer's View of Fields</h1>
-
-<p>As a GCC-specific convention, we will attach a special meaning to
-some fields. The State field should be used in the following way:</p>
-
-<dl>
-
-<dt>open</dt>
-<dd>The PR has been filed and the responsible person(s) notified.</dd>
-
-<dt>analyzed</dt>
-
-<dd>A maintainer has verified that this is indeed a bug in GCC. Every
-once in a while, old reports will need to be rechecked, to find out
-whether the bug still exists. At that time, an indication should be
-left in the report who tested the bug and when.</dd>
-
-<dt>feedback</dt>
-<dd>The submitter was asked for further information, or asked to try
-out a patch. The PR remains in that state until the submitter
-responds.</dd>
-
-<dt>suspended</dt>
-<dd>Work on the problem has been postponed.  This happens if a timely
-solution is not possible or is not cost-effective at the present time.
-The PR continues to exist, though a solution is not being actively
-sought. If the problem cannot be solved at all, it should be closed
-rather than suspended.</dd>
-
-</dl>
-
-<p>In addition, the <b>high</b> priority is reserved to maintainers in
-GCC, indicating that a certain problem must be solved before the next
-version of GCC is released.</p>
-
-<h2>Procedures and Policies</h2>
-
-<p><strong>Bugs that are in state "feedback"</strong> because they lack
-information that is necessary for reproducing the problem can be closed
-if no response was received for three months.</p>
-
-<p><strong>Regressions</strong> should be explicitly marked as such.
-The synopsis line should read</p>
-
-<blockquote>
-[&lt;branches-to-fix&gt; regression] &lt;rest-of-synopsis&gt;
-</blockquote>
-
-<p>where &lt;branches-to-fix&gt; is the list of <em>maintained</em>
-branches (separated by slashes) that need fixing. A regression should
-start with priority "<strong>high</strong>" to bring it to attention.
-It may be downgraded later if a defect is not important enough to justify
-"high priority".</p>
-
-<p><strong>Bugs in category "bootstrap"</strong> that refer to older
-releases or snapshots/CVS versions should be put into state "feedback",
-asking the reporter whether she can still reproduce the problem and to
-report her findings in any case (whether positive or negative).</p>
-
-<ul>
-<li>If the response is "works now", close the report,</li>
-<li>if the reponse is "still broken", change the state to "open", and</li>
-<li>if no response arrives, close the PR after three months.</li>
-</ul>
-
-<p><strong>Bugs in category "ice-on-illegal-code"</strong>, where gcc
-emits a sensible error message before issuing an ICE (the ICE will be
-replaced by the message "confused by earlier errors, bailing out" in
-release versions) should get "low" priority.
-It should be noted in the audit trail, that the error recovery fails.</p>
-
-</body>
-</html>
diff -rupN wwwdocs.orig/htdocs/style.mhtml wwwdocs/htdocs/style.mhtml
--- wwwdocs.orig/htdocs/style.mhtml	2003-02-20 17:49:31.000000000 -0500
+++ wwwdocs/htdocs/style.mhtml	2003-02-23 02:46:01.000000000 -0500
@@ -237,7 +237,6 @@
   <p>
   <a href="<get-var BACKPATH>bugs.html">Report a bug</a><br />
   <a href="http://gcc.gnu.org/cgi-bin/gnatsweb.pl">Bug database</a><br />
-  <a href="<get-var BACKPATH>gnatswrite.html">...write access</a><br />
   <a href="<get-var BACKPATH>bugs.html#known">Known bugs</a>
   </p>
   <hr />

Re: Target-specific bugs

[Gerald Pfeifer]

On Sun, 23 Feb 2003, Chester R. Hosey wrote:
> I'm sort of a gimp and wasn't sure how to handle having diff add/delete
> files other than -N, so that's how I handled adding bugs/tracking.html
> (and removing gnatswrite.html).
> [...]
> If I can/should submit in a slightly different format, let me know. ;-)

Perfect, thanks!

Sorry for the delay in getting back to this, but I was offline for nearly
three weeks and then caught by a huge backlog.

I now committed most of your patch with minor tweaks (like renaming
bugs/tracking.html to bugs/management.html and keeping a long there
from the main navigation).

I'll handle the rest later tonight or tomorrow.

Thanks!
Gerald

Index: style.mhtml
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.50
diff -u -3 -p -r1.50 style.mhtml
--- style.mhtml	20 Feb 2003 22:49:31 -0000	1.50
+++ style.mhtml	26 Mar 2003 21:10:33 -0000
@@ -237,7 +237,7 @@
   <p>
   <a href="<get-var BACKPATH>bugs.html">Report a bug</a><br />
   <a href="http://gcc.gnu.org/cgi-bin/gnatsweb.pl">Bug database</a><br />
-  <a href="<get-var BACKPATH>gnatswrite.html">...write access</a><br />
+  <a href="<get-var BACKPATH>bugs/management.html">...Management</a><br />
   <a href="<get-var BACKPATH>bugs.html#known">Known bugs</a>
   </p>
   <hr />
Index: gnatswrite.html
===================================================================
RCS file: gnatswrite.html
diff -N gnatswrite.html
--- gnatswrite.html	18 Dec 2002 23:22:10 -0000	1.16
+++ /dev/null	1 Jan 1970 00:00:00 -0000
@@ -1,133 +0,0 @@
-<html>
-
-<head>
-<title>Maintaining the GCC GNATS installation</title>
-</head>
-
-<body>
-<h1>Accessing the database</h1>
-
-<p>In order to manage PRs, you need an account for our GNATS database
-which is different from the authenticated access to the CVS repository
-(though the username will be the same). If you have CVS write access
-or a "senior" GCC Maintainer agrees that
-you should have a GNATS account, fill in
-<a href="http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi">this form</a>
-with "GNATS access only" in the SSH key part.</p>
-
-<p>Also, when you manage PRs, make sure mail-forwarding from
-gcc.gnu.org to your normal email account is activated; otherwise
-replies to status change notifications will bounce.</p>
-
-<p>You can access the database either via <a
-href="http://gcc.gnu.org/cgi-bin/gnatsweb.pl">gnatsweb</a>, or via
-the gnatsd running on gcc.gnu.org.</p>
-
-<h2>Using gnatsd and Emacs</h2>
-
-<p>Check out GNATS v3 from
-<code>:pserver:anoncvs@sources.redhat.com:/cvs/gnats</code> by means of
-the <code>-r gnats-v3-branch</code> option. Build and install that.</p>
-
-<p>Add the the ../share/emacs/site-lisp/ directory installed by the GNATS
-build to your <code>load-path</code> in order to pick up the gnats library.
-</p>
-
-<p>Finally, add the following entries to your <code>.emacs</code> file</p>
-
-<blockquote><code>
-  (load-library "gnats")<br />
-  (setq gnats:network-server "gcc.gnu.org")<br />
-  (setq gnats:userid "YourUserName")<br />
-  (setq gnats:password "YourGNATSPassword")<br />
-  (setq gnats:alias "gcc")<br />
-  (autoload 'edit-pr "gnats"
-            "Command to edit a problem report." t)<br />
-  (autoload 'query-pr "gnats"
-            "Command to query information about problem reports." t)
-</code></blockquote>
-
-<p>(If you already have PRMS support set up in you <code>.emacs</code>
-file, remove that first, to avoid conflicts with duplicate symbols.)</p>
-
-
-<h1>Adding Reports</h1>
-
-<p>To add a new report, you should be familiar with the <a
-href="gnats.html">general instructions</a>. In addition, you might
-want to use the gccbug.el Emacs-Lisp file to aid putting forwarding
-bug reports from gcc-bugs into the gnats database.</p>
-
-<h1>Maintainer's View of Fields</h1>
-
-<p>As a GCC-specific convention, we will attach a special meaning to
-some fields. The State field should be used in the following way:</p>
-
-<dl>
-
-<dt>open</dt>
-<dd>The PR has been filed and the responsible person(s) notified.</dd>
-
-<dt>analyzed</dt>
-
-<dd>A maintainer has verified that this is indeed a bug in GCC. Every
-once in a while, old reports will need to be rechecked, to find out
-whether the bug still exists. At that time, an indication should be
-left in the report who tested the bug and when.</dd>
-
-<dt>feedback</dt>
-<dd>The submitter was asked for further information, or asked to try
-out a patch. The PR remains in that state until the submitter
-responds.</dd>
-
-<dt>suspended</dt>
-<dd>Work on the problem has been postponed.  This happens if a timely
-solution is not possible or is not cost-effective at the present time.
-The PR continues to exist, though a solution is not being actively
-sought. If the problem cannot be solved at all, it should be closed
-rather than suspended.</dd>
-
-</dl>
-
-<p>In addition, the <b>high</b> priority is reserved to maintainers in
-GCC, indicating that a certain problem must be solved before the next
-version of GCC is released.</p>
-
-<h2>Procedures and Policies</h2>
-
-<p><strong>Bugs that are in state "feedback"</strong> because they lack
-information that is necessary for reproducing the problem can be closed
-if no response was received for three months.</p>
-
-<p><strong>Regressions</strong> should be explicitly marked as such.
-The synopsis line should read</p>
-
-<blockquote>
-[&lt;branches-to-fix&gt; regression] &lt;rest-of-synopsis&gt;
-</blockquote>
-
-<p>where &lt;branches-to-fix&gt; is the list of <em>maintained</em>
-branches (separated by slashes) that need fixing. A regression should
-start with priority "<strong>high</strong>" to bring it to attention.
-It may be downgraded later if a defect is not important enough to justify
-"high priority".</p>
-
-<p><strong>Bugs in category "bootstrap"</strong> that refer to older
-releases or snapshots/CVS versions should be put into state "feedback",
-asking the reporter whether she can still reproduce the problem and to
-report her findings in any case (whether positive or negative).</p>
-
-<ul>
-<li>If the response is "works now", close the report,</li>
-<li>if the reponse is "still broken", change the state to "open", and</li>
-<li>if no response arrives, close the PR after three months.</li>
-</ul>
-
-<p><strong>Bugs in category "ice-on-illegal-code"</strong>, where gcc
-emits a sensible error message before issuing an ICE (the ICE will be
-replaced by the message "confused by earlier errors, bailing out" in
-release versions) should get "low" priority.
-It should be noted in the audit trail, that the error recovery fails.</p>
-
-</body>
-</html>
Index: bugs/management.html
===================================================================
RCS file: bugs/management.html
diff -N bugs/management.html
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ bugs/management.html	26 Mar 2003 21:10:33 -0000
@@ -0,0 +1,119 @@
+<html>
+
+<head>
+<title>Maintaining the GCC GNATS database</title>
+</head>
+
+<body>
+<h1>Managing Bugs (GNATS and the test-suite)</h1>
+
+<p>This section contains information mostly intended for GCC
+contributors.</p>
+
+<p>If you find a bug, but you are not fixing it (yet):</p>
+<ol>
+<li>Create a (minimal) test-case.</li>
+<li>Add the test-case to our test-suite, marking it as XFAIL unless
+the bug is a regression.</li>
+<li>Add a bug report referencing the test-case to GNATS.</li>
+</ol>
+
+<p>If you want to provide additional information in the bug tracking
+system about a reported bug:</p>
+<ol>
+<li>If the bug is a segmentation fault in the compiler,
+<a href="bugs/segfault.html">provide information about its location</a>.
+</li>
+<li><a href="bugs/minimize.html">Minimize the test case</a>.</li>
+<li>Try the test case with earlier and later versions of GCC to
+determine which versions it affects and whether it is a regression.
+If it is a regression, <a href="bugs/reghunt.html">identify the
+patch</a> that introduced it.</li>
+</ol>
+
+<p>If you fix a bug for which there is already a GNATS entry:</p>
+<ol>
+<li>Remove the XFAIL on the test-case.</li>
+<li>Close the bug report in GNATS.</li>
+</ol>
+
+<p>If you find a bug, and you are fixing it right then:</p>
+<ol>
+<li>Create a (minimal) test-case.</li>
+<li>Add the test-case to our test-suite, marking it as PASS.</li>
+<li>Check in your fixes.</li>
+</ol>
+
+<h2>Maintainer's View of Fields</h2>
+
+<p>As a GCC-specific convention, we will attach a special meaning to
+some fields. The State field should be used in the following way:</p>
+
+<dl>
+
+<dt>open</dt>
+<dd>The PR has been filed and the responsible person(s) notified.</dd>
+
+<dt>analyzed</dt>
+
+<dd>A maintainer has verified that this is indeed a bug in GCC. Every
+once in a while, old reports will need to be rechecked, to find out
+whether the bug still exists. At that time, an indication should be
+left in the report who tested the bug and when.</dd>
+
+<dt>feedback</dt>
+<dd>The submitter was asked for further information, or asked to try
+out a patch. The PR remains in that state until the submitter
+responds.</dd>
+
+<dt>suspended</dt>
+<dd>Work on the problem has been postponed.  This happens if a timely
+solution is not possible or is not cost-effective at the present time.
+The PR continues to exist, though a solution is not being actively
+sought. If the problem cannot be solved at all, it should be closed
+rather than suspended.</dd>
+
+</dl>
+
+<p>In addition, the <b>high</b> priority is reserved to maintainers in
+GCC, indicating that a certain problem must be solved before the next
+version of GCC is released.</p>
+
+<h2>Procedures and Policies</h2>
+
+<p><strong>Bugs that are in state "feedback"</strong> because they lack
+information that is necessary for reproducing the problem can be closed
+if no response was received for three months.</p>
+
+<p><strong>Regressions</strong> should be explicitly marked as such.
+The synopsis line should read</p>
+
+<blockquote>
+[&lt;branches-to-fix&gt; regression] &lt;rest-of-synopsis&gt;
+</blockquote>
+
+<p>where &lt;branches-to-fix&gt; is the list of <em>maintained</em>
+branches (separated by slashes) that need fixing. A regression should
+start with priority "<strong>high</strong>" to bring it to attention.
+It may be downgraded later if a defect is not important enough to justify
+"high priority".</p>
+
+<p><strong>Bugs in category "bootstrap"</strong> that refer to older
+releases or snapshots/CVS versions should be put into state "feedback",
+asking the reporter whether she can still reproduce the problem and to
+report her findings in any case (whether positive or negative).</p>
+
+<ul>
+<li>If the response is "works now", close the report,</li>
+<li>if the reponse is "still broken", change the state to "open", and</li>
+<li>if no response arrives, close the PR after three months.</li>
+</ul>
+
+<p><strong>Bugs in category "ice-on-illegal-code"</strong>, where gcc
+emits a sensible error message before issuing an ICE (the ICE will be
+replaced by the message "confused by earlier errors, bailing out" in
+release versions) should get "low" priority.
+It should be noted in the audit trail, that the error recovery fails.</p>
+
+</body>
+</html>

Re: Target-specific bugs

[Gerald Pfeifer]

These are two follow-up patches I just committed.

Update reference to gnatswrite.html (and have it point to
bugs/management.html instead).

 and

Remove those parts that now reside in bugs/management.html.
By Chester Hosey <chosey@tr0n.com>.

Gerald

Index: cvswrite.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/cvswrite.html,v
retrieving revision 1.51
diff -u -3 -p -r1.51 cvswrite.html
--- cvswrite.html	7 Dec 2002 13:51:44 -0000	1.51
+++ cvswrite.html	26 Mar 2003 21:17:13 -0000
@@ -12,8 +12,8 @@
 <h1>Read-write CVS access</h1>

 <p>We have read/write access to the CVS repository available for all
-our significant developers. Maintainers are also encouraged to edit
-the <a href="gnatswrite.html">GNATS database</a>.</p>
+our significant developers. Maintainers are also encouraged to <a
+href="bugs/management.html">edit our bugs database</a>.</p>

 <hr />
 <h2>Contents</h2>

Index: bugs.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs.html,v
retrieving revision 1.66
diff -u -3 -p -r1.66 bugs.html
--- bugs.html	26 Mar 2003 01:51:47 -0000	1.66
+++ bugs.html	26 Mar 2003 21:17:14 -0000
@@ -24,7 +24,6 @@
  <li><a href="#pch">Detailed bug reporting instructions when using a precompiled header</a></li>
  </ul>
 </li>
-<li><a href="#manage">Managing Bugs (GNATS and the test-suite)</a></li>
 <li><a href="#known">Frequently Reported Bugs in GCC</a>
  <ul>
  <li><a href="#general">General</a></li>
@@ -275,45 +274,6 @@ use it.</p>
 <p>Please <strong>don't</strong> send us the actual precompiled
 header.  It is likely to be very large and we can't use it to
 reproduce the problem.</p>
-
-<h1><a name="manage">Managing Bugs (GNATS and the test-suite)</a></h1>
-
-<p>This section contains information mostly intended for GCC
-contributors.</p>
-
-<p>If you find a bug, but you are not fixing it (yet):</p>
-<ol>
-<li>Create a (minimal) test-case.</li>
-<li>Add the test-case to our test-suite, marking it as XFAIL unless
-the bug is a regression.</li>
-<li>Add a bug report referencing the test-case to GNATS.</li>
-</ol>
-
-<p>If you want to provide additional information in the bug tracking
-system about a reported bug:</p>
-<ol>
-<li>If the bug is a segmentation fault in the compiler,
-<a href="bugs/segfault.html">provide information about its location</a>.
-</li>
-<li><a href="bugs/minimize.html">Minimize the test case</a>.</li>
-<li>Try the test case with earlier and later versions of GCC to
-determine which versions it affects and whether it is a regression.
-If it is a regression, <a href="bugs/reghunt.html">identify the
-patch</a> that introduced it.</li>
-</ol>
-
-<p>If you fix a bug for which there is already a GNATS entry:</p>
-<ol>
-<li>Remove the XFAIL on the test-case.</li>
-<li>Close the bug report in GNATS.</li>
-</ol>
-
-<p>If you find a bug, and you are fixing it right then:</p>
-<ol>
-<li>Create a (minimal) test-case.</li>
-<li>Add the test-case to our test-suite, marking it as PASS.</li>
-<li>Check in your fixes.</li>
-</ol>

 <hr />

Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)

[Michael S. Zick]

On Saturday 22 February 2003 02:54 am, Nathanael Nerode wrote:
>
> Yeah.  I'm trying to make suggestions which will help clear the bug
> reports down to a managable quantity, though.  Bugs which can't be
> reproduced on maintained systems have no value in the bug tracking
> system, unfortunately.
>
Is it possible to split the bug-tracking into two parts; "Active Ports"
and "Inactive Ports"?

That retains all of the information, while allowing the "Inactive Ports"
branch to follow the inactive->deprecation->removed path.

Also might flag to some "silent maintainer" that his port is close
to being dropped.
Mike

Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs goingup)

[Joel Sherrill]

Nathanael Nerode wrote:
> 
> Joseph S. Myers wrote:
> > On Sat, 22 Feb 2003, Nathanael Nerode wrote:
> >
> >
> >>1. Platforms for which no 3.x build has been reported: Close all
> >>target-specific bugs immediately and possibly deprecate the platform.
> >
> >
> > We should close such bugs when support for the target is *removed* from
> > mainline, not when the target is deprecated.  (And this is something that
> > does need to be done as part of the target removal process, just as stray
> > references to the target and its problems need to be removed from
> > trouble.texi and elsewhere in the manual and sources - preferably as part
> > of the target removal rather than left for someone else to do later.)
> >
> > This may make sense for native platforms, but in general people do not
> > seem to report their cross builds at all or submit testresults for them.
> How sad...

I don't know that this is entirely true.  I have been reporting on my 
results of building about 35-40 cross targets on a GNU/Linux.  On those
with simulators I have been submitting the test results to the mailing 
list.  And periodically, I have been writing up a cross build status.
It only covers the non-OS and RTEMS targets (hence the 35-40 number) 
but that's a lot more than you are indicating.

And recently I began to Canadian cross on a GNU/Linux box cross toolsets
binaries hosted on Cygwin and Solaris.  The first batch for RTEMS is out
now but I haven't tried the Canadian cross for the non-RTEMS ones.

> > I would like to see a list of all supported platforms (which I think ought
> > to go in install.texi, host/target specific notes, even where there are no
> > specific notes for a system, just so that users can see exactly which
> > systems are supported and what their target triples are) together with the
> This would be a very, very good idea.

Janis (I think) and I had a discussion about this a while back.  The
first issue
is a format/structure that is easy to plug data for test results, hints,
etc.
into without being unwieldy.

> > list of those native systems which haven't had a 3.x build report or
> > testresults sent and so are candidates for deprecation.  (Also indicate
> > which if any of those have had any user interest at all - questions asked
> > about them, or bug reports saying they don't work.)
> >
> > Also remember that some target-specific bugs are in fact bugs in generic
> > code that just happen only to show up on certain platforms.
> Yeah.  I'm trying to make suggestions which will help clear the bug
> reports down to a managable quantity, though.  Bugs which can't be
> reproduced on maintained systems have no value in the bug tracking
> system, unfortunately.
> 
> For another thought, I strongly suggest that any bug in feedback and
> without feedback for 3 months be closed, and that this be documented
> somewhere.  (The standard I've been using is 6 months, which I think is
> overly generous.)

I think that will end up closing some that are simply being ignored
without
ever being addressed or fixed.  For example, I filed PR 3587 
on "Fri Jul 06 06:46:02 PDT 2001", it still applies to the 3.2 and 3.3
branches
(no testing on trunk), and has never gotten a bit of attention.  

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs goingup)

[Janis Johnson]

On Sun, Feb 23, 2003 at 02:52:12PM -0600, Joel Sherrill wrote:
> Nathanael Nerode wrote:
> > Joseph S. Myers wrote:
> > > On Sat, 22 Feb 2003, Nathanael Nerode wrote:
> > >
> > > This may make sense for native platforms, but in general people do not
> > > seem to report their cross builds at all or submit testresults for them.
> > How sad...
> 
> > > I would like to see a list of all supported platforms (which I think ought
> > > to go in install.texi, host/target specific notes, even where there are no
> > > specific notes for a system, just so that users can see exactly which
> > > systems are supported and what their target triples are) together with the
> > This would be a very, very good idea.
> 
> Janis (I think) and I had a discussion about this a while back.  The
> first issue
> is a format/structure that is easy to plug data for test results, hints,
> etc.
> into without being unwieldy.

A list of successful builds of cross compilers would be very useful, and
there have been several discussions about such a list.  I could help set
it up, but I don't have the time to maintain it.  Any volunteers?

Janis

Re: Target-specific bugs

[Zack Weinberg]

Nathanael Nerode <neroden@twcny.rr.com> writes:

> 1. Platforms for which no 3.x build has been reported: Close all
> target-specific bugs immediately and possibly deprecate the
> platform. These are the ones which just aren't going to get worked on.
> I would make an exception for platforms where the port maintainers are
> very active at fixing bugs, but I don't think I *need* to, since they
> probably have reported builds.  This means there won't be any bugs
> open against 'experimental' platforms, which is fine by me.

I am +1 on anything that entails removing dead targets.  Send me a
list.

zw

Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)

[Nathanael Nerode]

Joel wrote:
>I don't know that this is entirely true.  I have been reporting on my 
>results of building about 35-40 cross targets on a GNU/Linux.  On those
You rock!
...

>> For another thought, I strongly suggest that any bug in feedback and
>> without feedback for 3 months be closed, and that this be documented
>> somewhere.  (The standard I've been using is 6 months, which I think 
>is
>> overly generous.)
>
>I think that will end up closing some that are simply being ignored
>without
>ever being addressed or fixed.  For example, I filed PR 3587 
>on "Fri Jul 06 06:46:02 PDT 2001", it still applies to the 3.2 and 3.3
>branches
>(no testing on trunk), and has never gotten a bit of attention.  
Shouldn't be in feedback anymore -- feedback is for 'maintainers need 
more information to reproduce'.  And I meant 'waiting for feedback for > 3 
months'.  I would like to throw away some reports which haven't been 
tested on any current version (only RH2.96 or earlier), but if it's 
been reproduced on the 3.2 or 3.3 branches, it should certainly be open.

(Well, except for the mass of C++ old parser bugs, since they're really 
'wontfix' bugs prior to the new parser).

(Or if it's a bug against a dead target, in which case we should 
pull support for the target rather than pretending it works.  Which 
requires discussion on gcc@gcc.gnu.org first.)

Sorry nobody's actually fixed your bug.

--Nathanael