This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
PATCH: contribute.html improvements
- To: <gcc-patches at gcc dot gnu dot org>
- Subject: PATCH: contribute.html improvements
- From: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- Date: Wed, 26 Sep 2001 14:42:09 +0200 (CEST)
This, hopefully, improves the presentation and structure on
contribute.html somewhat, so that we can add further details
such that it'll be easy to read/browse.
Installed.
Gerald
Index: contribute.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.34
diff -u -3 -p -r1.34 contribute.html
--- contribute.html 2001/09/15 14:12:39 1.34
+++ contribute.html 2001/09/26 12:24:59
@@ -43,45 +43,67 @@ on file.</p>
<h2>Submitting Patches</h2>
- <p>Every patch must have several pieces of information before we can
- properly evaluate it.
+<p>Every patch must have several pieces of information before we can
+properly evaluate it:</p>
- <ul>
- <li> A description of the bug and how your patch fixes this bug. For
- new features a description of the feature and your implementation.
- <li> If the patch adds a new command line option, the patch must
- also add documentation for that option to the GCC manual.
- Similarly, if it changes the behavior of an existing command
- line option or other documented behavior, the patch must update
- the documentation. Documentation is also required for any
- changes or additions to the parts of the front-end and back-end
- interfaces documented in the manual (such as new target macros).</li>
- <li> It is strongly recommended the patch should add testcases for
- any new features added and any bugs fixed to the testsuite, if
- not already there. (You will of course have tested any new
- features you added, so this is simply a matter of writing your
- tests in a suitable form for inclusion in the testsuite.)</li>
- <li> A ChangeLog entry as plaintext; see the various ChangeLog files
- for format and content.<br>
- Note that, unlike some other projects, we do require ChangeLogs
- also for documentation (i.e., .texi files). They are not required
- for updates to the web pages.
- <li> A list of targets where the patch survived a bootstrap of GCC. A
- bootstrap on least one host is required for any non-trivial change.
- A full GCC testsuite run is also required. With your patch, provide a
- list of hosts where the GCC testsuite was run, including an
- analysis of any regressions. Documentation changes do not
- require a bootstrap, but must pass <code>make info</code> and
- <code>make dvi</code>.</li>
- <li> The patch itself. If you are accessing the <a href="cvs.html">
- CVS repository</a> at gcc.gnu.org, use
- "<code>cvs update; cvs diff -c3p</code>"; else, use
- "<code>diff -c3p OLD NEW</code>" or
- "<code>diff -up OLD NEW</code>".
- If your version of diff does not support these options, then get
- the latest version of GNU diff.
+<dl>
- </ul>
+<dt>A description of the problem/bug and how your patch addresses it.</dt>
+<dd>
+For new features a description of the feature and your implementation.
+</dd>
+
+<dt>Documentation</dt>
+<dd>
+If the patch adds a new command line option, the patch must also add
+documentation for that option to the GCC manual. Similarly, if it
+changes the behavior of an existing command line option or other
+documented behavior, the patch must update the documentation.
+Documentation is also required for any changes or additions to the
+parts of the front-end and back-end interfaces documented in the
+manual (such as new target macros).
+</dd>
+
+<dt>Testcases</dt>
+<dd>
+It is strongly recommended the patch should add testcases for any new
+features added and any bugs fixed to the testsuite, if not already
+there. (You will of course have tested any new features you added, so
+this is simply a matter of writing your tests in a suitable form for
+inclusion in the testsuite.)
+</dd>
+
+<dt>ChangeLog</dt>
+<dd>
+A ChangeLog entry as plaintext; see the various ChangeLog files for
+format and content.<br>
+Note that, unlike some other projects, we do require ChangeLogs also for
+documentation (i.e., .texi files). They are not required for updates to
+the web pages.
+</dd>
+
+<dt>Bootstrapping and testing</dt>
+<dd>
+A list of targets where the patch survived a bootstrap of GCC. A
+bootstrap on least one host is required for any non-trivial change. A
+full GCC testsuite run is also required. With your patch, provide a
+list of hosts where the GCC testsuite was run, including an analysis
+of any regressions. Documentation changes do not require a bootstrap,
+but must pass <code>make info</code> and <code>make dvi</code>.
+</dd>
+
+<dt>The patch itself</dt>
+<dd>
+If you are accessing the <a href="cvs.html"> CVS repository</a> at
+gcc.gnu.org, use "<code>cvs update; cvs diff -c3p</code>";
+else, use "<code>diff -c3p OLD NEW</code>" or
+"<code>diff -up OLD NEW</code>". If your version of diff
+does not support these options, then get the latest version of GNU
+diff.
+</dd>
+
+</dl>
+
<p>We accept patches as plain text (preferred for the compilers
themselves), MIME attachments (preferred for the web pages),
or as uuencoded gzipped text.</p>
@@ -99,8 +121,8 @@ on file.</p>
it may be a good idea to chase it by sending a follow-up email to
<a href="mailto:gcc-patches@gcc.gnu.org";>gcc-patches@gcc.gnu.org</a>.
Patches can occasionally fall through the cracks. Please be sure to
- include in the follow-up email the URL of the entry in the mailing list
- archive of the original submission.</p>
+ include the URL of the entry in the mailing list archive of the original
+ submission.</p>
</body>
</html>