all the blessings in May

I was sadly too lazy to update this blog. My only excuse is because there were many good things happened last month. The context here is of course Qt Software and Qt in general.

First thing first: we just open our source code repository. It's git, and it is hosted at http://qt.gitorious.org/. You can track every single commit from the engineers inside Qt Software, fantastic to see how certain bug is fixed and to localize regression breakage. For more goodies in the repository, check out what Benjamin, an ex-troll, has written.

But the beauty does not stop here. Now we are also accepting external contributions to Qt. It means that you can help us fixing bugs and implementing features. Read and digest the Contribution Guidelines to find out how. Since the repository was opened, every cool kid and his dogs have cloned it like crazy and we even have merged some of the contributions.

The domino effect. Since now we have the infrastructure on Gitorious, the project repository for Qt/S60 was going public, too. The repository is at www.gitorious.org/+qt-s60-developers/qt/qt-s60. I can imagine that this will be valuable for all the S60 fans out there, not only for Nokia platforms, but for other S60 devices e.g. for Samsung. If you see their video, you realize now what my PictureFlow Everywhere vision all about :-)

It does not stop there. Some research projects are moving towards more openness. Check for example the really cool multi-touch support being worked on by Brad. Also, the brand-new Declarative User Interface project, a concept of making good looking, fluid user interface via a non-imperative description of the interface. Both projects can be tracked from the repositories at qt.gitorious.org/+qt-developers/qt/multitouch-and-gestures and qt.gitorious.org/qt/kinetic/trees/kinetic-declarativeui, respectively.

Two bleeding-edges frameworks slated for Qt 4.6, Animation and State Machine, were finally merged into qt/master. If you love to compile Qt on a daily basis, you can really start to use both frameworks for your upcoming cool applications.

Last but not least, do not miss the Qt Mobility project announcement. The project aims to offer good API to access mobile functionalities, both for Nokia and non-Nokia platforms. The first set of API for Service Framework was going public already. Check its repository at qt.gitorious.org/qt-mobility/serviceframework.

Along with our successful visit to Pycon Tre Italia, can you see now how last month I got adrenalin kicks on a daily basis?

I of course do not abandon Graphics Dojo corner. Expect few cool things coming out in the next few weeks. Stay tuned!

Summer of Code 2008 Mentor Summit

Group Photo - Android
Originally uploaded by Austin Ziegler

Group Photo - Main Staircase Building 43
Originally uploaded by Austin Ziegler

Squeezing the time between the busy schedule, with other three Trolls (Simon, Thiago, Olivier), I attended the Google Summer of Code 2008 Mentor Summit at Googleplex in Mountain View. On the KDE side, we also met Jason and Leo. On the second day, the mentors and the organizers had two group pictures, one in the staircase and one in front of the big Android statue. The six of us from KDE also took a nice picture with the Android background.

My general impression of the summit: it was awesome! The venue was great, the talks were interesting, the food was nice, the snacks were abundant, and of course the opportunity to try out Toto E200 - the infamous 14-button toilet - was priceless. Surely the organizers did a very good job!

What is also great from Mentor Summit is the chance to meet great people. Since at Qt Software we switched from Perforce to Git, it was nice to be able to talk and discuss matters with Shawn Pearce. He happens to work on Google Android these days, unsurprisingly Android project is of course using git. Still related to Android, there were two talks about it: the story behind and the application development. Also of a great interest is Gerrit, the Python-based code review tool used Android development. According to Shawn, Gerrit is an improved fork of Rietveld, a similar tool written by Guido von Rossum. The mystery of both names is solved if you check out this Dutch architect.

I myself was so glad to be able to have a short chat with one of my personal legends, Sam Lantinga, the man behind the fantastic libsdl. He works for Blizzard and likely you know the game he is working on, as it is called World of Warcraft. As for libsdl itself, the new adventure is SDL for iPhone (which is one of its SoC projects). When finally it is released, I can't wait to see how many SDL-based games will be then available on iPhone. Plus, if you write an SDL-based application, now you have an interesting fast-growing target market as well.

I also followed a discussion from the 12-year old Dmitri Gaskin. He is the youngest mentor, he is actually too young to participate as a student (the age cut-off is 18). If you are a fan of Google Tech Talks, surely you are aware of his jQuery talk. So we discussed about JavaScript unit test, it involved a lot of coding from his side. I am not a jQuery expert so I just gave my opinions based on my little knowledge on the JavaScript engine in WebKit. I am eager to see how the unit test framework would evolve.

At the end of the summit, many of us were exhausted. But of course, we look forward to having the next-year mentor summit!

learning git the easy way: gitcasts

Think you have problem understanding git? Want to fast-forward your git skills? Just follow Scott Chacon's excellent and newbie-friendly GitCasts, a collection of screencasts on how to use git.

SpeedCrunch and git

I have shown before how to use git to manage your code hosted in Google Code Project Hosting and how to synchronize it (automatically) with a public git repository hosted in github. SpeedCrunch, your lovely desktop calculator, is an example of all this.

Flash back first. Due to an increasing demand, some time ago we (=Johan and I) decided that we should provide public Subversion repository for SpeedCrunch. Google Code was new but quickly became the popular choice, so Johan pulled the plug and imported the then latest version of the code. This happened 840 days ago. Fast forward to today. As of now, you can also get SpeedCrunch source code from github, it is available from http://github.com/ariya/speedcrunch/. It means you need as short as:

git clone git://github.com/ariya/speedcrunch.git

and voila! You get all commits since the first time the code was imported. For fun, try git log e3cddb :-). For practical reasons, right now I only push master and 0.10 branches, which correspond to the trunk and branches/0.10 in its Google Code subversion repository. The .git directory weighs at around 5 MB.

Of course, if you decide to fix bugs and make changes, just push your SpeedCrunch repository somewhere and (if Helder, the current maintainer, has no objection), I can merge into my github repository (if necessary, I would even cherry pick your changes). Think you can do better? Go ahead, sign up for github if you haven't done so (it's free!), then you can "fork" the repository easily. Just click on the button labeled fork. When you are happy with your own tree, use the pull request button (in your github repository) to notify me and we'll see what would happen.

Note: this public git repository is by no means the official one, as the official repository is still hosted in Google Code. It is fully synchronized, though. And by using git, I hope this can spark more contributions in term of new features, bug fixes, translations, etc.

Don't you just love choices?

dancing between github and subversion repository

As the next logical step after I wrote about easily using git to work with the subversion repository in Google Code Project Hosting, here is an idea to make your git repository available and still keep it synchronized (in both directions). The use case for my previous blog post is when your partners in crime still stick with subversion but you prefer to use git. Here it is extended further: some (not all) of your contributors start to realize how beautiful git is, try to use it, can't get rid of it and finally decide it to use only git from now on. It would be a crime to ask them to sync to the subversion repository themselves, hence the following dancing. Basically it works like this. In a Unix/Windows machine, do the usual cloning of a remote subversion repository and then push it to github. Your new git fans then clone the fresh git repository. It is amazingly simple, obvious and fast to do it this way.

First of all, register at github. You don't need anything except an email address.

Next, prepare your SSH key which will be used for authentication, this can be carried out in one minute, just follow the instructions. Go back to your account page, copy your public key and paste it there in the SSH Public Keys area. Then, use ssh-agent trick to skip typing your password every single time.

Tip: if you are on a Windows box and your msysgit does not come with the ssh-keygen tool, use the famous PuTTY (known as the terminal emulation with SSH support). In the package, there is a tool called PuTTYgen (PuTTY Key Generator). Simply launch this tool. Click on Generate button and move your mouse randomly for a few second. After that, type in a secret password in the Key passphrase and Confirm passphrase fields. Click the button Save public key and name the file as id_rsa.pub. Choose menu Conversion, Export OpenSSH key and name the file as id_rsa (without any extension). After that, navigate to your user directory, this is typically C:\Document and Settings\Username. Create a new directory named .ssh, if it does not exist yet. Move both id_rsa and id_rsa.pub to this .ssh directory. Now you are set. File id_rsa.pub contains your public key, so copy and paste it into your SSH Key in the github account page.

Now here comes the fun part: create a new repository. Just fill out a few fields and it is ready. Couldn't be simpler, could it?

At this stage, go to your local git working directory (i.e. the one cloned from a subversion repository) and do the following:

git remote add origin git@github.com:joesixpack/coolproject.git
git push origin master

by substituting joesixpack and coolproject with your github login name and the freshly created git repository. Wait a couple of seconds (or minutes), then basically your git repository, which is a clone of the remote subversion repository, is successfully pushed to github. Well done!

To keep both repositories synchronized, you can run a cron job that does the following:

git checkout master
git svn rebase
git svn dcommit
git push origin master

If you have branch(es) in the subversion repository, you still can do that. Just add few more commands and substitute master with your branch(es) name.

Tip: If accidently you push your local branch to github and now you want to remove it, use:

git push repository :heads/branchname

OK. So far so good. Now of course you do not work on a single machine, e.g. you may do the above steps in a Linux server but you would like to work on your Windows laptop. At this moment, you need to prepare another SSH key or just use the same key (e.g. copy the previous id_rsa and id_rsa.pub). Then it is a no-brainer to clone your repository:

git clone git@github.com:joesixpack/coolproject.git

Note: don't be surprised with the amazing speed of doing a git clone. Essentially, you get the whole repository (which contains the full history of the project) in a short period time, probably comparable to the time needed to check out from the subversion repository (which however gives you only some part of the changes history).

Awesome. In just few minutes, you have a git repository which can be synchronized with a remote repository (e.g. in Google Code project hosting). In addition, you can push this repository to github. And still, you can clone the repository in another machine for your pleasure. Now if you want other people to clone your repository, just tell them to do:

git clone git://github.com/joesixpack/coolproject.git
cd coolproject

Once they send patches to you or push their branches, you can do the merge into your git repository and push it to github. Due to the said cron job, the subversion repository (e.g. in Google Code) will get the changes as well. Every now and then, when other contributors commit some changes to the subversion repository, the changes will be also propagated to github. Both parties are happy.

Happy gitting!

Quick Start: using git (for Windows) with Google Code Project Hosting

Ideally everyone uses git, because just as Linus once wrote: Centralized works. It is just inferior.

And like what I expressed before, the project hosting feature of Google Code is a nice choice (much better than SourceForge) for doing collaborative works on open source projects. You have a project page, a wiki, a download space, an issue tracker, integrated statistics and mailing-list features, and of course a repository. However, up to now only subversion repository is offered. Likely because of the 80% folks reason.

That is surely not the end of the world. You can try to polish your growing git skills with that subversion repository by using git-svn. The idea is that you use git and then, once a while, you place the code in the subversion repository. This has several extra advantages than doing git only. First, there is a backup done by Google to your repository. In addition, other developers that know only how to use friendly GUI tools, e.g. TortoiseSVN, can get the code easily. And if they are the project members and contribute some code (through Subversion because that is what those poor guys are using), you can still merge their changes without pain to your master working branch. Also, your code is searchable with Google Code Search and this gives more exposure and promotes code sharing and reuse.

This short instruction is mainly targeted to "average" Windows developers who wants to use work offline using git and still are not afraid to use command-line, but not for the usual hard-core Linux geeks (who can easily recall the manpage of git even if you suddenly wake them in the middle of the night). For the latter, there are many posts that already cover it. Just so that you are aware, what is written below is not a replacement for the git-svn manual. In addition, suitably adjusted, it should also work with other types of subversion repositories beside Google Code Project Hosting's one, e.g. your company internal repository.

To get git, visit the msysgit project (which is, unsurprisingly, hosted on google code). Download the latest version that also includes git-svn, e.g. Git-preview20080301.exe at the time I write this. After that, double click the .exe file to install it. You will be presented with the installation wizard, just accept the default and continue clicking the Next button a couple of times until you finish. Usually it means you'll get git on C:\Program Files\Git and also you can right-click on Windows Explorer window to start doing some git magic from that active folder.

To initialize the git repository, from Windows Explorer folder tree, right click on a folder and choose the menu item Git Bash here. A console will open, here where you have type in the following:

git svn clone -s --username=joe.sixpack https://coolproject.googlecode.com/svn git

Of course, substitute joe.sixpack and coolproject with your Google Code user name and project name. The following message will show up:

Initialized empty Git repository in .git/
Authentication realm:  Google Code Subversion Repository
Password for 'joe.sixpack':

and then just enter the generated Google Code password for the subversion repository. If everything is fine, all the revisions in the remote Subversion repository of your project are being pulled to your local git repository. This may take a while, especially if your repository has years of history.

Note: On Windows, git-svn performance is just so-so. Maybe this will be improved in the future version. If suddenly you see git-svn fails at some point with the following error message:

 Cannot commit config file!
 config svn-remote.svn.branches-maxRev 116: command returned error: 4

then just retype your last clone command as git-svn would happily continue from where it stops (i.e. no need to pull from revision 1 again).

Now what you get is a subfolder called git (the last argument in the clone command that you typed before) which is your working folder and which contains the git repository (evidenced by a subfolder .git inside it). Switch to this git folder and you are ready for the subsequent steps.

To compact your git repository, run:

git gc

In principle, you need to do this only once a while. Here it is a good idea to do it because you just imported your whole subversion repository.

Tip: Because git repository is very compact, don't bother with disk space when you do the initial step of cloning. This is usually a point that is always repeated by your nearest git evangelist. To give an example, after cloning over 1300 revisions of SpeedCrunch source code, my git repository is only around 7 MB. On the other hand, a single subversion checkout (including all the branches) is already 51 MB. Mind you, that 7 MB contains all changes that have been committed during the history of the project vs 51 MB which is associated only with few subversion revisions only (trunk and several branches).

To start using git for your brand new cool feature, usually it is best to create a new branch for that particular feature. First, check all the branches that you might have using:

git branch -a

which gives something like:

* master
  0.6
  0.7
  0.8
  0.9
  tags/0.7
  tags/0.7-beta2
  tags/0.8
  tags/0.8-alpha
  tags/0.9
  trunk

where the star sign (*) indicates the current branch. The branch called master is created for you automatically, it is basically the local git branch to track the trunk version of the remote subversion repository.

Now create a new branch, e.g. joe/feature1, from master with the command:

git checkout -b joe/feature1 master

The name joe/feature1 is arbitrary. It won't be visible to the outside world because it is your local branch. So feel free use a naming scheme that suits you.

Time to have fun! In this branch, implement the feature that you love and do some coding there. Once you are happy, just commit it (to this branch) using:

git commit -a

Continue hacking on it until you are satisfied. Make as many commits as you like. The sky is the limit.

Finally, when you think the feature is rock-solid, to merge back your changes to master, do the following:

git checkout master
git merge joe/feature1

which means switching back again to the master branch and the apply all the changes that have been done in joe/feature1 branch. Simple and lovely, isn't it?

Now, what about the poor souls that still need to check out or update the code through the subversion repository in Google Code? Well, you still can push your changes there. To synchronize the remote subversion repository with your git master you need to do:

git svn dcommit

The other way around is perfectly possible as well. If your collaborators change something in the remote subversion repository, to keep your git master up to date just use:

git svn rebase

That is all. For more advanced techniques, refer to the git-svn manual. Don't forget to polish your git skills by reading the manual and tutorials as well as (of course) doing a lot of practices.

Tip: An alternative to the very first stage of cloning is just to populate the new git repository only with some latest revisions of remote Subversion repository. Use the following commands:

git svn init -s --username=joe.sixpack https://coolproject.googlecode.com/svn
git svn fetch -r 1300:HEAD
git gc

which will just give all the changes starting from revision 1300 to the last one (HEAD). This is of course not really recommended because you won't get access to the whole history of your Subversion repository, but it is still useful if your project is very large and you do not care with all those changes made in its prehistoric time. If you use this init+fetch method instead of clone, there is no subfolder created. Your working folder (and git repository) is where you did the init and fetch. Now you can continue the usual steps of creating a local branch, implementing your feature, synchronizing, and so on.

Don't you just love git?

Linus on git (again)

(No, this isn't about the Linus' Tech Talk video on git).

The nice thing working on KDE project is because Linus likes KDE. Thus, it is not (so) surprising (he used to help with bugs, e.g. #27340) to see Linus himself writing something (read: sending some "enlightment") to kde-core-devel, again on the topic of git:

Centralized _works_. It's just *inferior*.

I'd like to see a ThinkGeek shirt with that quote.