We are denormalizing into a field past migration; while usually I freak out writing directly to the field tables in this case it's justified because it's a custom module (never do this in contrib) and also because we are well aware of what does not happen when you do that (pluggable field storage and hooks). With that said, we have a query that roughly looks like this:

INSERT INTO {field_data_field_denorm_data}
(entity_type, bundle, deleted, entity_id, revision_id, language, delta, field_denorm_data_target_id)
SELECT 'user', 'user', 0, field1, field1, 'und', ????????????, field2

Sticks and stones may break my bones
But words will never harm me.

Summary: if you are working on a core patch which smells like it might be security related please let me know and I will review.

Meanwhile, I am working on switching twig autoescape on -- it is now declared a beta blocker. Help is warmly appreciated, please contact me.

I got a desperate call about a site being down, this is ordinary for me (advertisment: you can contact me if it happens to you). But the error I saw was new to me. This is surprising -- I have thought I have seen it all and then some. The modules/views/includes/plugins.inc was fataling about the function views_include not existing. At first I thought opcache went south cos how on earth could an include be loaded when the module isn't?? But it wasn't opcache.

As the Simpletest sprint in Paris was exactly six years ago I feel it's a good time to remind the community how and why Simpletest was chosen especially in the light of the Simpletest hate lately. At that time we had almost no tests (compared to the massive test battery today with over 68 000 asserts) and it was paramount to allow anyone to be able to write and run tests. Drupal in 2008 was not really API driven and so we needed browser based testing.

At DrupalDevDays Szeged, skipyT, fgm and myself made tremendous progress with writing the MongoDB drivers. All the override mechanisms work as expected and things in general, work. Most importantly, we have an entity storage backend and a significant percentage of the entity storage query tests pass (it is not expected all ever would pass, for example relationships are not supported).

A version of the migration API which is adequate to migrate Drupal 6 has been submitted for core inclusion. The sandbox contains the complete Drupal 6 to 8 migration, with more complete functionality and testing coverage than the upgrade path ever had. Every migration has its own test where the test sets up a Drupal 8 as if the required migrations already ran and then runs the migration over a very small partial Drupal 6 dump. Then there is a test which loads all the Drupal 6 dumps, runs every migration and then runs all the asserts from the tests.

As you might've heard, migrate is my last core work -- once migrate is done, I am finished with core development. Meanwhile, I will not participate in any other core issue except those blocking migrate (and the entity query conversion meta). As I have been doing core work for a long time, I am sure there are a few questions. Let me quickly go over them:

Is this a sign of Drupal in crisis?

Migrate in core works. Yesterday, after our weekly call (I am so thankful for eliza411 for organizing these calls, they are absolutely invaluable) a clear roadmap have emerged and I have written a rudimentary but functional drush command to run our migrations. Then I pointed it to a Drupal 6 database... and it worked. Just like that. Today penyaskito has finished the aggregator feed migration that eliza411 and mpgeek started and also written the aggregator item migration. These also work.

So I am writing a PHPUnit mock object, added ensure calls and I wanted to also ensure that no more method calls happens than the ones I ensured. This is done by the following snippet (the actual code does more with the expects call of course):
<?php
$schema = $this->getMockBuilder('Drupal\Core\Database\Schema')
->disableOriginalConstructor()
->getMock();
$schema->expects($this->at(0))
->method('tableExists');
$schema->expects($this->at(1))
->method('createTable');
$schema->expects($this->at(2))
->method('createTable');
$schema->expects($this->exactly(3))