1 files changed, 144 insertions, 0 deletions
diff --git a/gcc/README-bugs b/gcc/README-bugs
new file mode 100644
index 0000000..06e15bb
--- /dev/null
+++ b/gcc/README-bugs
@@ -0,0 +1,144 @@
+The purpose of GCC pretesting is to verify that the new GCC
+distribution, about to be released, works properly on your system *with
+no change whatever*, when installed following the precise
+recommendations that come with the distribution.
+
+Here are some guidelines on how to do pretesting so as to make it
+helpful.  All of them follow from common sense together with the
+nature of the purpose and the situation.
+
+* It is absolutely vital that you mention even the smallest change or
+departure from the standard sources and installation procedure.
+
+Otherwise, you are not testing the same program that I wrote.  Testing
+a different program is usually of no use whatever.  It can even cause
+trouble if you fail to tell me that you tested some other program
+instead of what I know as GCC.  I might think that GCC works, when in
+fact it has not been properly tried, and might have a glaring fault.
+
+* Even changing the compilation options counts as a change in the
+program.  The GCC sources specify which compilation options to use.
+Some of them are specified in makefiles, and some in machine-specific
+configuration files.
+
+You have ways to override this--but if you do, then you are not
+testing what ordinary users will do.  Therefore, when pretesting, it
+is vital to test with the default compilation options.
+
+(It is okay to test with nonstandard options as well as testing with
+the standard ones.)
+
+* The machine and system configuration files of GCC are parts of
+GCC.  So when you test GCC, you need to do it with the
+configuration files that come with GCC.
+
+If GCC does not come with configuration files for a certain machine,
+and you test it with configuration files that don't come with GCC,
+this is effectively changing GCC.  Because the crucial fact about
+the planned release is that, without changes, it doesn't work on that
+machine.
+
+To make GCC work on that machine, I would need to install new
+configuration files.  That is not out of the question, since it is
+safe--it certainly won't break any other machines that already work.
+But you will have to rush me the legal papers to give the FSF
+permission to use a large piece of text.
+
+* Look for recommendations for your system.
+
+You can find these recommendations in the Installation node of the
+manual, and in the file INSTALL.  (These two files have the same text.)
+
+These files say which configuration name to use for your machine, so
+use the ones that are recommended.  If you guess, you might guess
+wrong and encounter spurious difficulties.  What's more, if you don't
+follow the recommendations then you aren't helping to test that its
+recommendations are valid.
+
+These files may describe other things that you need to do to make GCC
+work on your machine.  If so, you should follow these recommendations
+also, for the same reason.
+
+Also look at the Trouble chapter of the manual for items that
+pertain to your machine.
+
+* Don't delay sending information.
+
+When you find a problem, please double check it if you can do so
+quickly.  But don't spend a long time double-checking.  A good rule is
+always to tell me about every problem on the same day you encounter
+it, even if that means you can't find a solution before you report the
+problem.
+
+I'd much rather hear about a problem today and a solution tomorrow
+than get both of them tomorrow at the same time.
+
+* Make each bug report self-contained.
+
+If you refer back to another message, whether from you or from someone
+else, then it will be necessary for anyone who wants to investigate
+the bug to find the other message.  This may be difficult, it is
+probably time-consuming.
+
+To help me save time, simply copy the relevant parts of any previous
+messages into your own bug report.
+
+In particular, if I ask you for more information because a bug report
+was incomplete, it is best to send me the *entire* collection of
+relevant information, all together.  If you send just the additional
+information, that makes me do extra work.  There is even a risk that
+I won't remember what question you are sending me the answer to.
+
+* Always be precise when talking about changes you have made.  Show
+things rather than describing them.  Use exact filenames (relative to
+the main directory of the distribution), not partial ones.  For
+example, say "I changed Makefile" rather than "I changed the
+makefile".  Instead of saying "I defined the MUMBLE macro", send a
+diff that shows your change.
+
+* Always use `diff -c' to make diffs.  If you don't include context,
+it may be hard for me to figure out where you propose to make the
+changes.  I might have to ignore your patch because I can't tell what
+it means.
+
+* When you write a fix, keep in mind that I can't install a change
+that would break other systems.
+
+People often suggest fixing a problem by changing machine-independent
+files such as toplev.c to do something special that a particular
+system needs.  Sometimes it is totally obvious that such changes would
+break GCC for almost all users.  I can't possibly make a change like
+that.  All I can do is send it back to you and ask you to find a fix
+that is safe to install.
+
+Sometimes people send fixes that *might* be an improvement in
+general--but it is hard to be sure of this.  I can install such
+changes some of the time, but not during pretest, when I am trying to
+get a new version to work reliably as quickly as possible.
+
+The safest changes for me to install are changes to the configuration
+files for a particular machine.  At least I know those can't create
+bugs on other machines.
+
+* Don't try changing GCC unless it fails to work if you don't change it.
+
+* Don't even suggest changes that would only make GCC cleaner.
+Every change I install could introduce a bug, so I won't install
+a change unless I see it is necessary.
+
+* If you would like to suggest changes for purposes other than fixing
+serious bugs, don't wait till pretest time.  Instead, send them just
+after I make a release.  That's the best time for me to install them.
+
+* In some cases, if you don't follow these guidelines, your
+information might still be useful, but I might have to do more work to
+make use of it.  Unfortunately, I am so far behind in my work that I
+just can't get the job done unless you help me to do it efficiently.
+
+
+				Thank you
+				   rms
+
+Local Variables:
+mode: text
+End: