(A) productive Drush sprint(s)
I was in Boston with Koumbit designers, which were attending the Design Camp. But I wasn't there for the camp (although I did drop by to say hi), but for the Drush sprint. Right after the camp, Moshe, Greg, Owen, Mark, Sam and mysqlf sat down two days straight, working almost non-stop on Drush. 12 hour days of coding, just stopping to eat a sandwich outside... while talking about Drush even more.
My objective during the sprint was to work on integrating Aegir more into Drush. Aegir has a lot of Drush extensions, in fact it's probably one of the biggest users of the Drush API. While I did contribute to the discussions regarding the implementation of drush deploy, I didn't actually do much more in that regard.
First day: Debian packaging
Thing is, it turned out that even I had been missing on a lot of good stuff that was happening in Drush. Being the Debian package maintainer, that meant that some features (e.g. the "drush topics") were totally missing from the Debian package. So a lot of my work during the first day revolved around fixing up the Debian package and uploading a new version (4.4-2, now in Debian Wheezy) which fixes a bunch of minor issues, mostly small. The package should hit squeeze-backports fairly soon and Ubuntu... eventually.
So with that out of the way, I went a bit further and worked on automatically building the Drush package, in Drush's Jenkins instance. Jenkins is a "continuous integration" system that allows for running tests each time code is committed (for example - Jenkins is very flexible and can probably cook dinner with the right plugin). So now when there's a commit to the Drush 5 branch, a test package is automatically built and uploaded to Koumbit's unstable Debian repository. (We still have to figure out how all this fits together from the user perspective though.) This work, in turn, was imported back into Aegir's Jenkins instance again to make sure uploads are complete, something which was missing from Aegir's autobuilder.
Second day: unit testing and bootstrap improvements
Not satisfied with the first 12 hours of straight out coding insanity, we started again the next day. I started working on a longstanding itch - the way unit tests are done. Thanks to Moshe's persistant efforts, Drush has a fairly good test coverage, but those should be more described as "functional" than "unit" tests, because they test drush commands (as opposed to "units", which are usually methods or functions, confusingly enough).
I wanted to test one function, not the whole thing, so some time before the sprint, I submitted a half-assed, half-working patch to refactor unit testing. It didn't work, and was pretty lame, so I spent the good time I had with the drush folks to rework it.
Turns out this needed much more than refactoring unit testing - because we needed to bootstrap Drush, we had to duplicate some code, which was not really desirable. The solution, create bootstrap.inc, a file I was always looking for when trying to figure out Drush inner workings before. This being a quite complex operation, being at the sprint was essential as the patch was big and doomed to create conflict and "forever chasing head" scenarios if we would have worked the usual way.
It turns out the patch works great and was committed to drush 5. In my tests, I found about 3x performance improvements when repeatedly testing functions, which is quite nice.
So that was my second day - I also helped the other devs in working with Jenkins and git, although I actually learned way more stuff than I taught, thanks to the presence of Sam Boyer - the brain and sweat behind drupal.org git migration.
What's next?
Really happy with the sprint, I matter-of-factly suggested we do the sprint again, when we parted ways, and lo-and-behold, Moshe is organising a new sprint for Drupalcon London! Now I hope I will finally have time to push Aegir's hacks into Drush 5. 
Sounds awesome! I really like the Debian package stuff. It makes it so much easier to convince a big IT departments to install Drush in a server environment that way. I've gone through that
On a side note I found a possible namespace conflict with Drush Deploy: http://drupal.org/node/1224138
Really glad to hear somebody enjoys the Debian package! Hard work but well worth it...
Thanks for all the positive feedback folks.