groff before CVS: release 1.021.02

[[This repository was stitched together in December 2013 from an
incomplete set of early groff release tarballs - versions 1.02 to 1.15 -
and the CVS history since shortly before the 1.16 release by Werner Lemberg.
CVS commits before Wed Apr 11 22:45:11 2007 lacked commitids;  coalescence
of those into changesets may not be perfect.

The lift was done by Eric S. Raymond using cvs-fast-export and a pre-3.0
version of reposurgeon. Comments double-bracketed like this one were added
during the conversion to replace empty log entries.]]

1 files changed, 53 insertions, 0 deletions

diff --git a/BUG-REPORT b/BUG-REPORT
new file mode 100644
index 000000000..8448d8a95
--- /dev/null
+++ b/BUG-REPORT
@@ -0,0 +1,53 @@
+			   Groff Bug Report
+
+Please read the PROBLEMS file before sending in a bug report.
+
+Please fill in all fields, even if you think they are not relevant.
+
+Please report separate bugs separately.
+
+Send the completed form either to bug-groff@prep.ai.mit.edu or
+directly to me: jjc@jclark.uucp or jjc%jclark@mcsun.eu.net (if neither
+of those works for you, jjc@ai.mit.edu should forward.)  Messages sent
+to bug-groff can sometimes take several days to reach me.
+
+GROFF VERSION:
+[The version of groff you are using.  For example, `1.00']
+
+MACHINE:
+[The machine you are using.  For example, `Sun 4/370']
+
+OS:
+[The operating system you are using.  For example, `SunOS 4.0.3']
+
+COMPILER:
+[The compiler you are used to compile groff. For example, `g++ 1.37.1']
+
+INPUT FILES: [Include all the files necessary to reproduce the problem
+that are not part of the standard groff distribution.  This includes
+font description files, DESC files and macro files (with the exception
+of the -ms and -mm macros: I have them).  Send them as as a shell
+archive or as a uuencoded, compressed tar file.
+
+It's easier for me if you can provide an example that doesn't depend
+on any macro package, but obviously if you're reporting a problem with
+a macro package that won't be possible.  Also a short example is more
+convenient than a long one, but don't worry if you can't find a short
+example.  Don't say something like ``any file that X'': always send a
+definite example.]
+
+COMMAND LINE:
+[The command line that I should run in order to observe the bug. For
+example, `gtroff -Tps bug.tr']
+
+DESCRIPTION OF INCORRECT BEHAVIOUR:
+[What goes wrong when that command line is run?  For example, `gtroff
+gets a segmentation fault', or `The output looks bad because the bar
+over the x is too long and is too far over to the left.'  If you get
+an error message, include it here without modification: don't edit it
+to make it more readable.]
+
+SUGGESTED FIX [optional]:
+[If you can suggest a fix for the problem, include a context diff
+here.  But don't delay sending in a bug report in the hope of finding
+a fix.  Guesses about the cause of the bug are not helpful.]