"sporadic Zope crashes"
    http://collector.zope.org/Zope/553

This is much like the test of the same name I just added to the Zope
2.6 and 2.7 branches, but reworded to use ZODB 3.3isms.  The HEAD
bucket conflict resolution code is already correct in this case,
so no other code change here -- adding this test to ensure it stays
correct.

'test left threads behind' warnings. Tests in testZEO sometimes do
that too, but that's hard to reproduce.

to zLOG other than a few comments.

This definitely broke the log analyzers pretty bad.

This probably broke the log analyzers... :(

fiddly code trying to prevent OverflowError.

conversion (this is an --all test, so the original committer probably
didn't run it).

Introduced a trivial new module (loglevels.py) to centralize creating
the custom log levels ZODB/ZEO want to use.

processing the messages because the format might have changed a little bit.

(the tests themselves still aren't being run; we need decent
save/restore behavior from the logging package to do this properly)

logging directly

later

didn't recognize its version number.  As a result, 3.3a3 went out with
ZODB/__init__.py claiming it was version 3.3a2.  Repaired that, but by
changing what release.py looks for.

cause of the:

  TypeError: unpack() argument 2 must be string or read-only buffer, not None

failure often seen in overnight testrunner reports now, coming from the
checkConcurrentUpdatesInVersions test.  If the hypothesis is correct,
we'll see a failure of the new

        assert end is not None

instead.

returns a datetime.timedelta instead of a float.

Added test case and documentation.

thinks they live.

The old code used itertools.chain(), which didn't work as expected.
If the first of the two iterator grew after the chain had started
consuming the second iterator, the new element(s) in the first
iterator would never be consumed.

Fix this bug by eliminating the need for chaining.  Process all the
_added_during_commit objects at the end, each with its own
ObjectWriter instance.