Remove rants about DocBook. It hasn't got better and isn't likely to

any time soon, but i'm seriously working on getting mandoc to cope
with what it spews, and to free porters from having to bother about it.

faq/ports/specialtopics.html

@@ -981,34 +981,11 @@ <h3>Should I check anything?</h3>
 reduce the port's build time.
 
 <p>
-In the following two cases, mandoc will almost certainly work.
-If you encounter a case where it doesn't, please report that to
-schwarze@, who will probably fix mandoc.
-
-<ul><li>
-The documentation is written using the
-<a href="http://man.openbsd.org/mdoc.7">mdoc(7)</a> language rather than the
-<a href="http://man.openbsd.org/man.7">man(7)</a> language.
-To distinguish the two, look at the beginning of the manual source code:
-.Dd is mdoc(7), .TH is man(7).
-
-<li>
-The documentation is man(7), but generated by
-<a href="http://man.openbsd.org/pod2man">pod2man(1)</a>.
-For such pages, the first line of the manual source code reads
-<br>
-<tt>.\" Automatically generated by Pod::Man...</tt>
-</ul>
+If a new port or an existing port not marked with <tt>USE_GROFF</tt>
+does not work with mandoc, please report that to schwarze@, who
+will probably fix mandoc.
 
 <p>
-Of course, most ports not matching these criteria work as well.
-However,
-
-<ul><li>
-If a port is using DocBook, there is a high probability that
-<tt>USE_GROFF</tt> is still required.
-
-<li>
 If a port is using <tt>CONFIGURE_STYLE = imake</tt>, merely removing
 <tt>USE_GROFF</tt> is insufficient, because
 <tt>/usr/X11R6/lib/X11/config/OpenBSD.cf</tt> will still attempt to call groff.
@@ -1017,7 +994,6 @@ <h3>Should I check anything?</h3>
 <tt>ComplexProgramTargetNoMan</tt> and install the manual(s) by hand, typically
 using a <tt>post-install</tt> target in the port <tt>Makefile</tt>.
 See <tt>sysutils/xbattbar</tt> for a simple example.
-</ul>
 
 <h3>Which tools do I need?</h3>
 
@@ -1051,17 +1027,6 @@ <h3>How do I report the results?</h3>
 Before sending such reports, please always tick off the following checklist:
 
 <ol><li>
-For the time being, do not report problems related to DocBook.
-We know source code generated by DocBook is extremely crappy even
-when DocBook works as intended, and on top of that, DocBook tends
-to be more buggy than average software.
-We also know that mandoc usually parses and renders DocBook output badly,
-and we know what to do to improve mandoc in this respect.
-This may change in the future, but right now, more than half of all reports
-that fail to reveal new, useful information are related to DocBook, and the
-signal-to-noise ratio in DocBook reports is too low to be worthwhile.
-
-<li>
 Attach the <a href="http://man.openbsd.org/mdoc.7">mdoc(7)</a> or
 <a href="http://man.openbsd.org/man.7">man(7)</a> source file in question
 to the mail.
@@ -1135,28 +1100,6 @@ <h3>How do I do automatic checking?</h3>
 mandoc maintainer might choose to let mandoc issue <tt>UNSUPPORTED</tt>
 messages in additional cases or to fix the formatting.
 
-<p>
-Besides, sending a report to the mandoc developers is useful if:
-
-<ul><li>
-The manual pages in question are in
-<a href="http://man.openbsd.org/mdoc.7">mdoc(7)</a> format.
-
-<li>
-The manual pages in question are generated by
-<a href="http://man.openbsd.org/pod2man">pod2man(1)</a>.
-
-<li>
-You find one or more messages "ERROR: skipping unknown macro", and the fact
-that the manual pages you are looking at use these macros is not yet reported
-in the mandoc
-<a href="http://mdocml.bsd.lv/cgi-bin/cvsweb/TODO?cvsroot=mdocml">TODO</a>
-list.
-Even if we already know that a certain roff request is still unsupported,
-learning which manuals actually use it is useful to get our priorities right
-when implementing new features.
-</ul>
-
 <p>
 If manual pages look good with groff, never patch them to get rid of mandoc
 errors.