[wwwdocs] Shorten contribute.html a bit and convert links to https

[Gerald Pfeifer <gerald at pfeifer dot com>]

Applied.

(gcc-bugs also has changed its usage, it's not meant for direct
posting any more.)

Gerald

Index: contribute.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.84
diff -u -r1.84 contribute.html
--- contribute.html	22 Jun 2014 13:07:07 -0000	1.84
+++ contribute.html	27 Jun 2014 11:07:43 -0000
@@ -68,10 +68,9 @@
 
 <p>Submissions which do not conform to the standards will be returned
 with a request to address any such problems.  To help with the
-preparation of patches respecting these rules, one can use the script
-<a href="https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh";>
-contrib/check_GNU_style.sh</a> to detect some of the common
-mistakes. </p>
+preparation of patches you can use the script <a href=
+"https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh?view=markup";>
+contrib/check_GNU_style.sh</a>.</p>
 
 <!-- also referenced from svnwrite.html -->
 <h2><a name="testing">Testing Patches</a></h2>
@@ -79,8 +78,7 @@
 <p>All patches must be thoroughly tested.  We encourage you to test
 changes with as many host and target combinations as is practical.  In
 addition to using real hardware, you can
-<a href="simtest-howto.html">use simulators</a> to increase your test
-coverage.</p>
+<a href="simtest-howto.html">use simulators</a>.</p>
 
 <p>Much of GCC's code is used only by some targets, or used in quite
 different ways by different targets.  When choosing targets to test a
@@ -91,7 +89,7 @@
 
 <p>You will of course have tested that your change does what you
 expected it to do: fix a bug, improve an optimization, add a new
-feature.  If the test framework permits, you should automate these
+feature.  Where possible you should automate these
 tests and add them to GCC's testsuite.  You must also perform
 regression tests to ensure that your patch does not break anything
 else.  Typically, this means comparing post-patch test results to
@@ -104,9 +102,8 @@
 <p>If your change is to code that is not in a front end, or is to the
 C front end, you must perform a complete build of GCC and the runtime
 libraries included with it, on at least one target.  You must
-bootstrap all default languages, not just C.  You must also run all of the
-testsuites included with GCC and its runtime libraries.  For a normal
-native configuration, running</p>
+bootstrap all default languages, not just C, and run all testsuites.
+For a normal native configuration, running</p>
 <blockquote><pre>
 make bootstrap
 make -k check
@@ -141,9 +138,7 @@
 <p>In all cases you must test exactly the change that you intend to
 submit; it's not good enough to test an earlier variant.  The tree
 where you perform this test should not have any other changes applied
-to it, because otherwise you cannot be sure that your patch will work
-correctly on its own.  Include all your new testcases in your
-testsuite run.</p>
+to it.  Include all your new testcases in your testsuite run.</p>
 
 
 <h2><a name="docchanges">Documentation Changes</a></h2>
@@ -192,8 +187,7 @@
 For new features a description of the feature and your implementation.
 For bugs a description of what was wrong with the existing code, and a
 reference to any previous bug report (in the
-<a href="https://gcc.gnu.org/bugzilla/";>GCC bug tracker</a> or the
-<a href="http://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs archives</a>) and any
+<a href="https://gcc.gnu.org/bugzilla/";>GCC bug tracker</a>) and any
 existing testcases for the problem in the GCC testsuite.
 </dd>