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.

It really frustrates me that while github nicely automated forking, there's no "update fork" button. For me, it's tedious and difficult to juggle two remotes. Instead, I added a single line to .git/config:

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.

Before this gets too much traction: We didn't add Twig to core because Symfony uses it. I know it became popular to add anything that Symfony does based on the features it provides. Now, I started the Twig movement and I don't work like that. In fact, I feel frustrated and somewhat insulted that anyone presumes I would operate like that. My No1 priority is security. It always was. It always will be. To quote the original issue:

I presume you read some Behat/Gherkin tutorials which go: "With BDD, you write human-readable stories that describe the behavior of your application." Well, WTF, how does that human readable story become code? The answer is, which I have never seen clearly written: you write it, without any help, whatsoever. Behat does not provide any assertions, any helpers, it's an extremely thin test runner. You need to write a test class, mandatory name "FeatureContext.php".

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.