Merge branch 'maint'

* maint:
  Fix xml warnings in old release notes

3 files changed, 19 insertions, 18 deletions

diff --git a/lib/diameter/doc/src/notes.xml b/lib/diameter/doc/src/notes.xml
index c2bbed2e5a..28d6ea4fd0 100644
--- a/lib/diameter/doc/src/notes.xml
+++ b/lib/diameter/doc/src/notes.xml
@@ -255,8 +255,8 @@ first.</p>
 	    Fix decode of Grouped AVPs containing errors.</p>
           <p>
 	    RFC 6733 says this of Failed-AVP in 7.5:</p>
-          <p>
-	    <taglist><item><p><c> In the case where the offending AVP
+
+	    <taglist><tag></tag><item><p><c> In the case where the offending AVP
 	    is embedded within a Grouped AVP, the Failed-AVP MAY
 	    contain the grouped AVP, which in turn contains the
 	    single offending AVP. The same method MAY be employed if
@@ -265,11 +265,11 @@ first.</p>
 	    the grouped AVP hierarchy up to the single offending AVP.
 	    This enables the recipient to detect the location of the
 	    offending AVP when embedded in a
-	    group.</c></p></item></taglist></p>
+	    group.</c></p></item></taglist>
           <p>
 	    It says this of DIAMETER_INVALID_AVP_LENGTH in 7.1.5:</p>
-          <p>
-	    <taglist><item><p><c> The request contained an AVP with
+
+	    <taglist><tag></tag><item><p><c> The request contained an AVP with
 	    an invalid length. A Diameter message indicating this
 	    error MUST include the offending AVPs within a Failed-AVP
 	    AVP. In cases where the erroneous AVP length value
@@ -284,7 +284,8 @@ first.</p>
 	    the minimum AVP header length, it is sufficient to
 	    include an offending AVP header that is formulated by
 	    padding the incomplete AVP header with zero up to the
-	    minimum AVP header length.</c></p></item></taglist></p>
+	    minimum AVP header length.</c></p></item></taglist>
+
           <p>
 	    The AVPs placed in the errors field of a diameter_packet
 	    record are intended to be appropriate for inclusion in a
@@ -949,8 +950,8 @@ first.</p>
 	    Be lenient with the M-bit in Grouped AVPs.</p>
           <p>
 	    RFC 6733 says this, in 4.4:</p>
-          <p>
-	    <taglist><item><p><c>Receivers of a Grouped AVP that does
+
+	    <taglist><tag></tag><item><p><c>Receivers of a Grouped AVP that does
 	    not have the 'M' (mandatory) bit set and one or more of
 	    the encapsulated AVPs within the group has the 'M'
 	    (mandatory) bit set MAY simply be ignored if the Grouped
@@ -958,14 +959,14 @@ first.</p>
 	    encapsulated AVP with its 'M' (mandatory) bit set is
 	    further encapsulated within other sub-groups, i.e., other
 	    Grouped AVPs embedded within the Grouped
-	    AVP.</c></p></item></taglist></p>
+	    AVP.</c></p></item></taglist>
           <p>
 	    The first sentence is mangled but take it to mean this:</p>
-          <p>
-	    <taglist><item><p><c>An unrecognized AVP of type Grouped
+
+	    <taglist><tag></tag><item><p><c>An unrecognized AVP of type Grouped
 	    that does not set the 'M' bit MAY be ignored even if one
 	    of its encapsulated AVPs sets the 'M'
-	    bit.</c></p></item></taglist></p>
+	    bit.</c></p></item></taglist>
           <p>
 	    This is a bit of a non-statement since if the AVP is
 	    unrecognized then its type is unknown. We therefore don't
diff --git a/lib/hipe/doc/src/notes.xml b/lib/hipe/doc/src/notes.xml
index 314fd55ba3..82f0c8ec1e 100644
--- a/lib/hipe/doc/src/notes.xml
+++ b/lib/hipe/doc/src/notes.xml
@@ -130,12 +130,12 @@
         </item>
         <item>
           <p>
-	    Various fixes and improvements to the HiPE LLVM backend.
+	    Various fixes and improvements to the HiPE LLVM backend.</p>
 	    <list> <item>Add support for LLVM 3.7 and 3.8 in the
 	    HiPE/LLVM x86_64 backend</item> <item>Reinstate support
 	    for the LLVM backend on x86 (works OK for LLVM 3.5 to 3.7
 	    -- LLVM 3.8 has a bug that prevents it from generating
-	    correct native code on x86)</item> </list></p>
+	    correct native code on x86)</item> </list>
           <p>
 	    Own Id: OTP-13626</p>
         </item>
@@ -191,7 +191,7 @@
         <item>
           <p>
 	    Fix various binary construction inconsistencies for hipe
-	    compiled code. <list> <item>Passing bad field sizes to
+	    compiled code.</p> <list> <item>Passing bad field sizes to
 	    binary constructions would throw <c>badarith</c> rather
 	    than <c>badarg</c>. Worse, in guards, when the unit size
 	    of the field was 1, the exception would leak rather than
@@ -211,7 +211,7 @@
 	    missing check for unit size match when inserting a
 	    binary. For example, a faulty expression like
 	    <c>&lt;&lt;&lt;&lt;1:7&gt;&gt;/binary&gt;&gt;</c> would
-	    succeed.</item> </list></p>
+	    succeed.</item> </list>
           <p>
 	    Own Id: OTP-13272</p>
         </item>
diff --git a/lib/reltool/doc/src/notes.xml b/lib/reltool/doc/src/notes.xml
index 2365a68feb..5b710a3267 100644
--- a/lib/reltool/doc/src/notes.xml
+++ b/lib/reltool/doc/src/notes.xml
@@ -52,13 +52,13 @@
 	    Some dependency chains would even be missed for
 	    applications that are included in a 'rel' spec in the
 	    reltool config. E.g.</p>
-          <p>
+
 	    <list> <item>Application x has y as included application,
 	    and y in turn has z as included application. Then z is
 	    not included. </item> <item>Application x has y in its
 	    'applications' tag in the .app file, and y in turn has z
 	    as included application. Then z is not included.</item>
-	    </list></p>
+	    </list>
           <p>
 	    These bugs are now corrected.</p>
           <p>