This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Target-specific bugs

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 at sources dot redhat dot 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>
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]