According to drumm's graphs shown at Barcelona, I submit (by far) the most patches to the Drupal core. This matches my gut feelings, too. So, I guess some now expects me to write a long diatribe about how I fear Acquia will exploit and deform my work. These are probably the same naysayers who believes that Drupal does not learn from other OSS projects. Now these people should listen: you might think that you hold an Ace and a King, and you played it for the win, but you know what happens to those? They walk back to Houston. Good riddance! Everyone, hear me out: Acquia is the best thing ever happen to Drupal!

Subscriptions, rewritten from ground up is in beta. At the time of this writing, beta2. Beta1 did not install on certain MySQL versions thus I deleted that release node. Thanks to delius for the warning.

So, these guys do not observe community processes and yet they fervently patch and sometimes what they do is good. More often, it's more a hindrance than good. No plea in private email or even in public email can get them back in line. So, what can we do with friendly posts like "this issue is opened to waste testers and reviewers time and makes things more difficult"? With people who constantly put back their issues in the current version even though several high profile contributors said "wait until Drupal 7" until finally a core committer says "enough"?

Our history begins on the African savannah. Economy was based on meat. Meat was something to build an economy on: it was available in limited quantity and obtaining it required special skills. Meat, in its original form either ran away very fast or, even worse, fought back. So was the cow invented -- thus the importance of meat as the base of the economy dwindled and now the land where you could grow your cow was more important. So the land became the base of wealth and land was available in limited quantities and soon every land belong to some thus trying to obtain it again lead to conflict.

On Drupal Planet, one of the first things I saw this morning was a quote from my answers to factoryjoe's review. The author of that blog post easily skipped the fact that it was me who copied this review to drupal.org infrastructure to make discussion easier and spent considerable time to review and answer. My answers was just, asking for implementation where I saw something great and turning down others.

Everyone interested in this, first of all -- sorry. I wasted months trying to fix the old codebase. Now, there is a new approach... from the ground up. The code is blasted apart into small component modules: there is a module which queues the objects, there is an UI module so you can subscribe to things and there is a module which sends mails out of the queue on cron. This way, you can change the UI easily for something that fits your site better or you can use mailman or even SMS as the sender backend.

Konstantin Käfer in this issue have used page callback => 'drupal_json'. That's a remarkable trick. Cross that with the object loading notation of the new menu and you can get your objects in JSON with remarkable ease: $items['node/%node/json'] = array('page callback' => 'drupal_json', 'page arguments' => array(1), 'type' => MENU_CALLBACK); will get you the node in JSON format, access checked and all. Noone stops you from writing foo_object_load and using %foo_object to return anything in JSON...

So I ripped out the menu system and I thought I will be able to put it back just because I had an idea (and some code) of how the router will work essentially and how the navigation block would work. I was wrong. There was an immense amount of work to be done to complete the menu conversion and it's very likely I would not have been able to do it in any timely manner or maybe not at all. But Peter Wolanin stepped up and did a significant portion of this work, Without him there would not be even a Drupal 6 beta 1 at this point.

grep LOWER modules/*/*.{module,inc} includes/*inc

Add themes, sites/all etc as needed. The interesting trick is the {}.

Countless times I needed to bother with PostgreSQL pecularities. I have nothing against PostgreSQL in a technical manner but neither the market nor our community has the human resources to support it. Let's face it: years come and go and the various PostgreSQL maintainers became busy with something else.