This is a timely thread, I wanted to bring up the reversion integration for more discussion.
The USE_REVERSION setting was recently added - it just puts reversion's admin class into the base admin classes for DisplayableAdmin, which powers most of the admin classes in Mezzanine.
The Mezzanine approach has always been to only include integration with dependencies like this, only if the integration was fairly minimal. I tried out the current reversion integration myself at the time, and there are a few areas (such as Mezzanine pages) where it doesn't actually work properly, and as such the reversion integration isn't applied in the admin interface for pages at least.
There are now a couple of open pull requests that add a whole bunch of code for integrating with reversion in other areas:
To be honest I don't think this code belongs in Mezzanine, and I feel like adding the USE_REVERSION setting may have been a mistake by paving the way for more code like this.
What I'd like to do instead is possibly come up with some approach of being able to define the base classes that get used across the different admin classes in a way that can be configured outside of Mezzanine. An example of this approach is the recent addition of UPLOAD_TO_HANDLERS:
That allows people to define the upload_to arg for any file field, by defining a dict setting that maps app/model/fields to upload handlers in a generic way outside of Mezzanine. Perhaps the same could be done for admin classes.
Finally, do we even need to do this? Is the same thing not achievable simply unregistering/registering your own admin classes? If so I'd be reluctant to even include configurable admin base classes.