Based on a discussion on IRC this is not apparent to everyone so let me write down quick my core workflow:

There is a module (which I will not link) which is a duplicate of another, providing functionality that is absolutely crucial to every high performance Drupal site. Now, aside from the dubious claims it being faster than the original (it has been proven not to be and so now there are only indirect claims of it on the project page), it have proposed to replace the original instead of cooperating and, worst of all, it made a syntax error in a stable release. Stable releases are under the security team umbrella. For me, this situation is not acceptable. When I filed an issue in protest (which, to be fair, did not mention the security angle), the security team leader have said "I think it's fine to ignore this issue". I have no avenue left to protest but to resign from the security team. Once again, it's not really the specific module that is the problem it's just a symptom. We need to tear down the walls on who can create projects as it is clearly visible that they do not help at all and at the same time we need to change the role of the team and make it very clear that most modules are not under the security team umbrella. Discussions have happened about this for years now but I feel the time has run out. I am glad I could help this last eight years.

The very first step is broken here: you fork the repository. At this very moment you are off the main community and noone knows what's going on. You hack but hack alone. Currently one can review the 'entity system' issues in one central place where discussion and code is happening (github separates issues from pull requests). This coherent, single, participatory, inclusive system is missing. We do not want people going off and working separately, making their work visible only when they think it's ready.

My entity logic mover patch got in, slimming down the storage controller classes significantly. This will make it much easier to support them in MongoDB. Two things remained (load and baseFieldDefinitions), load being postponed until the NG conversion is done and the baseFieldDefinitions move architecture foundation just got in. This is progressing remarkably well. At the forthcoming weeklong Dublin code sprint I will move the field_sql_storage module inside DatabaseStorageController ending this weird notion of fields existing somehow separately from entities.

There are a lot of great things happening! Let's first see those that are already in: the config system got back to a saner track by removing the partial import capability and only allowing import of full config trees. This removed manifests which, honestly, I never truly grokked. Also, config import and sync were converted to pluggable services earlier so if someone can figure out how to do partials better then they can do.

There are a number of Drupal 8 issues that simply make me sad. I still didn't stop contributing to Drupal nor I plan to, I just need to accept that we have some disagreements which are not getting resolved. It's frustrating and I am mostly just venting so comments are disabled. (It's frustrating enough that I went over them to tag them.)

Ps. There's a little silver lining: the config import code has been rewritten finally. Still, I will not touch CMI.

Recently a post appeared which stated Drupal became the Scientology of open source and because it appeared in a reply of a few tweets involving me and it contains my name, I need to answer it.

The biggest changes (at least from my end, as usual) since the last update are allowing plugins to have their services injected. It's perhaps not the most beautiful solution ever but it works. Again for plugins, one directory depth have been removed, it's still ridiculous but less so and the PHP-FIG (nudged by our quicksketch, thanks much) is finally moving ahead with creating a new autoloader standard which will make the directory structure a bit saner.

It seems relatively easy (ie. zero configuration) to get PHPstorm and Xdebug up and running together, so I will presume you have that going. It often happens that you want a breakpoint in a frequently called function. Just putting one will make the system stop there every time. After a right click, Edit you can add conditions to it which help. Even better, you can add a breakpoint to somewhere else, remove the suspend checkbox from it and make the first breakpoint disabled until the second is hit. This allowed me for example to break in drupal_flush_all_caches only when fired from WebTestBase::resetAll.

Another useful tip from dawehner (I had no idea!): PHP CLI works with xdebug just fine, you just need to run export XDEBUG_CONFIG="idekey=PHPSTORM" first.

When developing (with) Drupal 8, you will occasionally see the superb helpful exception from DefaultFactory: the plugin did not specify an instance class. A what did not a-do a what?? Glad you asked. For example, here's BlockManager:
<?php
public function __construct(array $namespaces) {
$this->discovery = new AnnotatedClassDiscovery('block', 'block', $namespaces);
$this->discovery = new DerivativeDiscoveryDecorator($this->discovery);
$this->discovery = new AlterDecorator($this->discovery, 'block');