Added an example to the release notes for custom reverse managers.

docs/releases/1.7.txt

@@ -169,7 +169,19 @@ Using a custom manager when traversing reverse relations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It is now possible to :ref:`specify a custom manager
-<using-custom-reverse-manager>` when traversing a reverse relationship.
+<using-custom-reverse-manager>` when traversing a reverse relationship::
+
+    class Blog(models.Model):
+        pass
+
+    class Entry(models.Model):
+        blog = models.ForeignKey(Blog)
+
+        objects = models.Manager()  # Default Manager
+        entries = EntryManager()    # Custom Manager
+
+    b = Blog.objects.get(id=1)
+    b.entry_set(manager='entries').all()
 
 New system check framework
 ~~~~~~~~~~~~~~~~~~~~~~~~~~

docs/topics/db/queries.txt

@@ -1155,11 +1155,19 @@ query you can use the following syntax::
 
     class Entry(models.Model):
         #...
-        objects = models.Manager() # Default Manager
+        objects = models.Manager()  # Default Manager
-        entries = EntryManager() # Custom Manager
+        entries = EntryManager()    # Custom Manager
 
-    >>> b = Blog.objects.get(id=1)
+    b = Blog.objects.get(id=1)
-    >>> b.entry_set(manager='entries').all()
+    b.entry_set(manager='entries').all()
+
+If ``EntryManager`` performed default filtering in its ``get_queryset()``
+method, that filtering would apply to the ``all()`` call.
+
+Of course, specifying a custom reverse manager also enables you to call its
+custom methods::
+
+    b.entry_set(manager='entries').is_published()
 
 Additional methods to handle related objects
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~