typo

Change-Id: I41cb128767c0cba48255cca0904ae1bff1b357ac
(cherry picked from commit 6410e372cb344084ee13942bd5b9eb78b24fc50c)

diff --git a/doc/build/changelog/unreleased_14/8717.rst b/doc/build/changelog/unreleased_14/8717.rst
index 10c7ceec84c131d1beb1bacbb7ec1b2464c36287..676f2e21525b9a461c90db6e2c24838910c1ce59 100644 (file)
--- a/doc/build/changelog/unreleased_14/8717.rst
+++ b/doc/build/changelog/unreleased_14/8717.rst
@@ -5,14 +5,15 @@
     Fixed issue where the :meth:`.PoolEvents.reset` event hook would not be be
     called in all cases when a :class:`_engine.Connection` were closed and was
     in the process of returning its DBAPI connection to the connection pool.
+
     The scenario was when the :class:`_engine.Connection` had already emitted
-    ``.rollback()`` on its DBAPI connection within the process of returning the
-    connection to the pool, where it would then instruct the connection pool to
-    forego doing its own "reset" to save on the additional method call.
-    However, this prevented custom pool reset schemes from being used within
-    this hook, as such hooks by definition are doing more than just calling
-    ``.rollback()``, and need to be invoked under all circumstances This was a
-    regression that appeared in version 1.4.
+    ``.rollback()`` on its DBAPI connection within the process of returning
+    the connection to the pool, where it would then instruct the connection
+    pool to forego doing its own "reset" to save on the additional method
+    call.  However, this prevented custom pool reset schemes from being
+    used within this hook, as such hooks by definition are doing more than
+    just calling ``.rollback()``, and need to be invoked under all
+    circumstances.  This was a regression that appeared in version 1.4.
 
     For version 1.4, the :meth:`.PoolEvents.checkin` remains viable as an
     alternate event hook to use for custom "reset" implementations. Version 2.0