If I would schedule Drupal 8 then I would very quickly look around the issue queue and get a list of desired not-too-big cleanups and fixes that would happen before Chicago. Code slush before the full thaw. (kudos to catch for the idea btw) Then at Chicago at the core conversations we could figure out the big things we want and work on them until and including London. End of London, soft freeze! 2012 North America DrupalCon, release. Nice and tight, about 16 months lots and lots of cleanup, UI love and not much but enough craziness.

There is little doubt that the patch of 2010 is http://drupal.org/files/issues/name-change.patch

I do not even know where to start...

• Have you ever seen such a geek announcement of a marriage?
  Congrats, Jacine! Similar stories are usually told by men -- and in way less cool fashion. :)

In Drupal 6, dependencies[] = foo. In Drupal 7, dependencies[] = foo (>=2.x, <4.17, !=3.7). Meaning, we need foo module major version to be at least 2, any version up to (but not including) 4.17 aside from 3.7 which was horribly buggy. If you need to do this with core, uses system in place of foo. Also note that you can say dependencies[] = foo (>=7.x-2.x).

Some modules need to take over access control of a router entry. Using hook_menu_alter is a good idea for this. But sometimes (especially for node paths) your module only makes decisions in some cases and wants to call the original. Here's how you do this in a way that does not hardwire anything:
<?php
function comment_allow_anonymous_menu_alter(&$items) {
// 2 is the node we need.
array_unshift($items['comment/reply/%node']['access arguments'], 2, $items['comment/reply/%node']['access callback']);

In Drupal 8, besides settings.php I would like to see a non-PHP settings file, writeable by the webserver. settings.php would contain the secrets, the database settings, site key etc but most things that are variables now would become settings, loaded from a file. This would avoid the chicken-egg problem of how to load settings that are required to get to the database? In Drupal 8 we want to have plugins (like the cache in D7 just more generic) and this would provide an excellent place to put the plugin registry.

Drupal is in the business of throwing the doors wide open so setting bear traps beneath the windows is wasted effort. In other words: I am not going to oppose any OOP in Drupal 8 as long as no more protected keywords are added and the current ones are removed.

Much to my surprise, someone decided to warm up the old debate about field storage, stating that Drupal 7 will be much less performant because of it. That Drupal 7 is a little slower than Drupal 6 is true, but that's not because of how we store fields (rather because the increased use of rendering) and it's not a terrible slowdown either (one can say it's a win when used wisely because of the render cache).

Drupal 6 modules typically defined their own tables, had their own code to maintain them and then used nodeapi to hook into the system. Or, defined node types but still maintained their own tables. In Drupal 7 instead you should just create fields, instance them on node types you want to work with. Instead of altering a form directly you can write a widget. Display your data with a formatter. Don't worry about data storage, field API handles that for you. And then there is the EntityFieldQuery class to help with finding things.

The Drupal community is remarkably not sexist and yet... Yesterday, Dries' keynote, alas, had a sex scandal slide which probably just wanted to be a (rather tactless and tasteless) joke but it had rather sexist undertones which have managed to piss off a number of women. But, my frustration is not just from the keynote but the reaction, let me quote two tweets here: "Woman on stage at #drupalcon, Dries can have his sextape in 2010." and even more importantly, from someone who retweeted it and got called out for it "Don't take it so seriously. It was a joke, right?" Now, head over to http://rocktreesky.com/reacting-sexism and you can see that three years ago (exact to day) the documentation team leader of Drupal have written exactly, word-for-word about this. It is absolutely unacceptable behaviour and not a joke to degrade women who have made DrupalCon possible for you to sex objects. As Addi noted in her linked blogpost, sexism won't stop just because we write about it, however, I hope this accident will actually make the community even more refusing about sexism and it will be unnecessary to write about it for at least another three years and we can work together on releasing an awesome Drupal 7, 8...

Let's say you have an UPDATE query which uses old values to calculate new ones. The best example for now is swapping two columns: UPDATE table SET f1 = f2, f2 = f1. There is one SQL engine as far as I am aware where this breaks: MySQL (it works on PostgreSQL, SQLite and MS SQL). On MySQL, f1 and f2 both will have the old value of f2 instead of swapping.