By default AJAX submits to system/ajax and retrieves the form from cache. So if your form depends something from the page it originally appeared on it then you need to store that in $form_state, the whole of $form_state is cached alongside of the form (only a few internal keys are not).

What I wanted, stupid me, change a select box, get my node form to rebuild on an "AJAX submit" and display some changed elements. Well, AJAX does not fire form level submit handlers (this is supposedly a good thing). But, the form only rebuilds if the "rebuild" flag gets set ($form_state['rebuild']) by a submit handler and a submit handler only -- which are not fired. Opsie! While a custom form surely can do something in #process, #after_build etc a node form really wants to be rebuilt. Seems like a stalemate.

The Drupal community helped me to get a Panasonic CF-Y5. I no longer need it so I am planning on passing it on. The tech might be a bit dated but still, it's a capable, very lightweight (1.5kg) machine with 2.5GB of RAM, a dual core first generation Intel Core Duo L2400 CPU and a 60GB HDD. The 14" screen is 1400 x 1050. I have two batteries for it, one original, one OEM. Both last couple hours, I only used the machine recently on planes so I only know the without wifi capability: the original does about 4 hrs. The bottom of the laptops is full of scratches the rest is quite good (well, it's a business rugged Panasonic so it's hardly a surprise). Drop me a line if you are a Drupal contributor and need a laptop.

Seems the community is overly happy with the git migration and it's right to be. But I would like to quietly remind everyone one part of our success is us being centralized. One part the git migration is beneficial to this because all those projects that went off to github can return home. On another part all these "sandboxes" have a danger of everyone going off into their own little corner. Oh yes, our long time core contributors will still post patches and just play nice but ... maybe not.

If you used bzr/cvs/svn checkouts and want something similar then in the repository root do:

After this (on at least on Linux and Mac OS X)

1. Contents will be pushed after every commit
2. new branches will rebase after every pull.
3. The only existing branch (master but can be something else with for example git clone --branch 6.x-1.x use the instruction on the Git instructions page of your project for this step) will rebase after every pull.

It does not abort commits if the local repo is behind remote, however. I would love to see tips on how to do that.

lut4rp gave me a link today. I understood git. In minutes. Miracles!

you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.

Half of the existing resources on Git, unfortunately, take just that approach: they walk you through which commands to run when, and expect that you should do fine if you just mimic those commands. The other half does go through all the concepts, but from what I have seen, they explain Git in a manner that assumes you already understand how Git works.

The docs is at http://www.eecs.harvard.edu/~cduan/technical/git/

Now I am going to miss some of the code sprint on Friday at the Chicago DrupalCon. I began asking about real dates of London months ago and now I am left without a choice but to ask publically: when IS DrupalCon London including core conversation, sprints, whatnot? Some of us need the dates many months ahead to be able to plan and it's extremely frustrating 'cos I am 100% these dates are known.

1. The GPL says you can charge for your code. But you can't stop anyone else from distributing your code for free. It happened with MySQL Enterprise.
2. Whether the Drupal Association wants to be a seller of apps I do not know. The payment infrastructure exists. We have code repos. It's a decision to be made. I do not know who makes that decision and how.

There was an excellent article about the growing interest of Russia and China in open source. I am shocked by the lack of reaction in our community -- we need to face the question: what we will do when (when! not if) hackers appear with interests closely alligned with those governments? It's not impossible their dayjob will be core hacking -- ie they will have the time the ordinal core hacker doesn't. We have already shown that we are willing to give up something good (namely compatibility in one direction with other phpass using systems) for the sake of one government (the USA, in this case) in this issue. How do we continue?

This document contains my list for what I would like to see done ASAP. It uses CSS/jQuery to provide sane numbering for embedded lists and won't be consistent on feed aggregators so for the list you need to read the original. I copied this to http://groups.drupal.org/node/116044 for easier editing. Disclaimer: this is just my list and not all items are agreed upon. I am not a core maintainer this is just a list of things that IMO needs to be done ASAP and I would love to see people working on them and obviously I will work on them too. We desperately need frontend folks to chime in -- I am more familiar with backend issues. As said in the previous post, get a few, important, quick, doable fixes now, think major at Chicago, code some foundations at Chicago, work until London, finish together in London.