Done: thanks to the 18 months long work of swentel and yched (assisted by xjm, larowlan, alexpott and tim.plunkett) field_config and field_config_instance tables are dead and we are using CMI! Not a lot of tables left.

First, a briefing of already committed patches: Image toolkits, aggregator processors and parsers are now plugins. The form storage is now in key-value instead of abusing the cache system. Twig is now available during install, unlocking much of the conversion -- this needs your help. Alex Pott has been named branch maintainer which will make the whole commit process much, much faster.

I forgot to mention in the previous one, but I took back and the rewrote from the ground up the Make Cache interface and backends use the DIC issue which since got committed even after being fixed by others :) Obviously, anything using the service container is win for us. Right now I am working on the database upgrade path -- we had tests for that but not every code path had tests as we were unable to write tests for some of them (and accordingly they broke).

The entity team was busy: Nodes are using the new Entity API and Taxonomy Terms are not far behind. All the field types are also getting integrated with the new Entity API. Given that the new entity query only works with entities and fields integrating with this API, it's really great to see this happening.

CMI got a new override and context system. This, as usual, is only relevant to my goals as I am utterly dependent on the success of CMI :)

A short one because not a lot of time has passed but two commits worths a quck post: Aggregator support for entity queries has been committed and also we have an aptly named 'drivers' directory database and other drivers can live. I will work on getting drush and update.module support for the db drivers there.

The entity config query is in and the aggregation query system is ready, and it's surprising how little new code was necessary for it -- mostly a little refactor of the existing SQL implementation to make it more reusable and of course a lot of tests -- written with the help of dawehner, thanks! There are a few big issues left: split the entity controller into a CRUD controller and the real controller. Once users become EntityNG, roles need to use the existing entity reference item. Same for taxonomy terms and their hierarchy.

Installing / importing new configuration no longer writes directly the config storage but uses the full Config object which fires events on write/delete. This allowed me to start on writing a config entity query class which subscribed these events and denormalized data suitable for queries. catch then voted this one down, saying it's premature optimization. So a simpler implementation has been submitted which loads all configuration entities of a certain kind (like all Views) and then filters/sorts/etc.

Most importantly: we added static caching to the configuration management system. This paves the way of further speedup by utilizing cache_get_multiple instead of loading each object one by one. While Drupal always had the capability to override certain variables in settings.php this is now much nicer and even has its own little API, settings()->get(). The separation of these settings necessary for bootstrap versus the CMI overrides was badly needed. Also, the new Entity Query system now has relationship support (that has been a frequent request).

I have changed course and speed seemingly because now we are so beyond tresholds that feature patches can't get in. So we are in bugfix mode and I have chosen performance ones because those will help in a lot of ways: it will kill a lot of majors and criticals and also speed up testing which helps development overall. Also, the EntityQuery relationship patch relies on converting everything to the new Entity API and that can't happen if it's slow.

Finally the kernel work is complete: right after settings.php is read, the compiled service container is read and used and there is no other service container being used (while I worked a lot on the early part the previous weeks, this week was mostly the One Container To Rule Them All patch). This means MongoBundle can override everything in the service container easily.