Condensing my previous post and other happenings into a shortlist.

1. We cut out the really unused product modules immediately. This is ongoing and a consensus is forming around the imminent death of blog, dashboard, php, profile, shortcut, statistics and trigger.
2. We find maintainers or do a quick refactor for the modules listed in the previous that stay. The goal here is the stabilize bleeding patients but nothing more. This seems to be ongoing, yesterday I saw a guy on IRC who was contemplating on taking the forum module maintainer hat.
3. With the "kernel" team now free, we focus on reworking our "kernel" (don't call this a framework -- maybe later, maybe never) to something nice. This is ongoing with the Configuration Management and the Web Services initiative.
4. Meanwhile, people rally around onramp profile (nee snowman). This seems to be a rather nice idea with a proper process: list of personas, user stories, specification before coding. The works. If this comes to be, we can cut more of the current product modules. This seems to be ongoing, there are people interested in this enough to give it a good name instead of a joke. This is something we definitely need help with and there are people who do these steps day in, day out, please head over to the group and participate.

We have written some very frustrated blog posts. Time to reflect on them and outline some causes and plans to move forward.

1. Why are we so frustrated?

There have been a small number of people consistently fighting the major/critical bug queue for a long time. We got Drupal 7 released (through patching and reviewing some 8000 issues) but after that we needed to continue the bug fighting and this really got on people's nerves. For example the upgrade path has been critically broken for two years without a break.

First this is not a personal critique of anyone. These are just some of the things that seem hopeless right now

1. There is no place to have a meaningful architecture discussion which core contributors frequent. It was the developer mailing list some time ago.
2. If an issue is not a relatively straightforward bugfix, it has little chance of getting in. Sure, Dries has two kids and two companies and I can understand that -- this is not a critique of Dries. He became a bottleneck none the less.

Right now I can't feel writing anything new major -- however, one of the reasons issues get stuck because it can get tricky to write tests for them. So if your issue gets stuck in the CNW -- Needs tests state, give me a shout.

This might be an old hat to those who are used to creating Views in code, but for me this is a nice new trick. So first create a view in the UI, export it and then cut it down mercilessly. There's extremely little necessary to get a View up and running if you dont care about the display and just want the raw results. First you need

Then a field:

<?php
$handler->display->display_options['fields']['nid']['id'] = 'nid';
$handler->display->display_options['fields']['nid']['table'] = 'node';

The last few days I wrote modulate. This Drupal 6 project has two important parts: a drush script copying various PHP snippets from the database into modulate.inc and modulate.module firing the copies and stopping eval from firing. The ultimate goal is that production could run with the php.ini setting disable_functions=eval. Right now, modulate works with custom block content, block visibility, node bodies, Views 3.x areas (header, footer, empty), default arguments and argument validators. Future plans include CCK textfields, custom panes, the Views customfield module and maybe even Rules (I could use help with that one) and of course a D7 port (help is welcome on that front as well -- it should be very easy). Oh and tests. Please write me tests :)

I took a D7 site as a small side job the last few weeks mostly to learn Views and to get a chance to write a series of blogposts about how to create interesting things with D7 and Views. This is the first but not the last by far. So we needed a portfolio/username view. This is tricky -- you don't want a User: name, instead you need to add a User: uid contextual filter (argument in D6), specify a User validator and pick Only allow string usernames.

This might be boring (and might be better at chxramblings than here) but oh well. I will talk about some things that I perceive as I live the typical (?) geek, introvert life and the consequences for usability.

If you are writing a stream wrapper for Drupal 7 be mindful of two things:

1. If your code throws a notice then up to and including 5.3.5 extremely weird bugs exist that completely break your script.
2. When reading the whole file (for example: file_get_contents), as long as stream_read returns non-empty strings, the return value of stream_eof is ignored.

.

Unless you are architecting core or interested in how that particular sausage is made, please leave in peace and don't hack core.