In order to commemorate this important day today, I thought I’d give credit to someone who has just had an anniversary a few days ago: the Qt open repository. I put together this family album for the important moments in this 1 year and 3 days.
March 23, 2009: The repository is born
You were born in a chilly morning, with 30607 files and 3135 directories. You weighed only 150 MB and you had two branches (4.5 and master).
Your older brother, qt-history (who was 15 years, 5 months, 19 days old) was very proud of you.
May 11, 2009: You found a home and a family to take care of you
The Gitorious family welcomed you with open arms. From this day on, you had a permanent identity and address, http://qt.gitorious.org/qt/qt.
Your cousins qt-jambi and qt-creator joined you in this new family, among other distant Open Source cousins.
Your first merge request didn’t take long to come.
Jun 25, 2009: Your first public tag and release
v4.5.2 was your first public tag and release in your new home. You had taken v4.5.1 with you to Gitorious, but it wasn’t until June that the first real release came in that home.
We even made a public announcement.
Sep 1, 2009: Your first new branch
Branch 4.6 is created.
Despite appearances to the contrary, the creation of 4.6 is when Qt 4.7 development really started, because it’s when 4.6 feature-froze.
Mar 1, 2010: Second public branch
And almost exactly 6 months after the 4.6 branch was created, the 4.7 branch had its turn!
We were off by 9 hours to the 6-month mark.
Today
Today, you weigh 321 MB, and you have grown to 37261 files, in 4120 directories. You have over 400 clones on Gitorious.
Your family has grown, with the Qt Mobility project coming to live with you, and your cousins at Maemo Gitorious. The number of Merge Requests I cannot even count.
I’d say you’ve reached maturity. There are projects out there and in Gitorious doing work that we at Qt Development Frameworks could not do. That’s only been possible because of the open commits and full history.
What’s next? Well, the path to Open Source is without return. Now we have to do more.
Possibly related posts:
9 comments
Nice post ^^
Happy birthday !
Long live Qt… Very nice post!!!
where can I find qt-history ?
qt-history is not public. The reason why it exists is because we cannot make it public, so we cut it off and started anew.
First of all, happy birthday! Having the repository open was a great improvement in the way Qt is developed and I’m sure everybody involved can testify that.
Now let me take this as an opportunity for a few suggestions. I do understand that the task of handling a git repository with lots of integrations and multi-located teams is far from easy, but here are some of the issues I believe deserve some improvement:
1. Maybe it’s time to split the repository in some sub-projects (from the top of my head, I would suggest doc, examples, 3rd party and maybe top sub-projects such as qtwebkit and qtdeclarative). It’s a PITA to run git on such a huge repository. Commands such as git status, log, diff and gitk take long seconds to return something useful. I guess Qt is one of the biggest projects hosted as a single project using git (bigger than the linux kernel, for example, which has 32293/1996 files/dir right now).
2. Apparently it takes a while for your internal changes to hit the public repository. I don’t know the way it’s organized inside Nokia/TT, but you should push your repositories more frequently. For example, I should be able to see my commit in the official repository immediately after a merge request is approved/applied. Ditto for tags and branches such as the 4.7.0-tp1.
3. Lots of merge commits. I don’t know if it’s fully automated or what, but right now the top git tree shows 7 cascaded merges such as “Merge branch ’4.6′ of …”. As a matter of fact, 29% of the last 1k commits are made of such merges. This makes it difficult to follow the development trees and understand what’s being done. Maybe the teams could rebase their private repositories more frequently or the integration could be done in small steps in sub-trees.
Finally, I suggest the integration team take a look on how the linux kernel git repository is managed. Git was born there and they have a fairly mature integration process from where a lot of lessons can be taken.
Again, happy birthday, looking forward to celebrate the 2nd year
Happy birthday. Very nice article.
very nice post, indeed
obrigado Thiago!!
Ademar: If you use git on the command line, you can run “git log –no-merges” to ignore the merge commits. This _could_ also be a useful feature (enabled by default!) on gitorious. I don’t think it’s worth it to reduce the number of merge commits; we’d like to encourage rather than discourage the use of branches. One final remark: merge commits take 24 hours or more to reach the public servers. This is too bad but right now it’s how it’s got to be. When you submit a merge request, this change ends up in a staging branch where it’s tested in bulk together with several other changes. Now that we’re in post-alpha stage _lots_ of changes are going in this way, and we only merge staging branches upstream when the green lamp is lit. Plus there’s a 24 hour delay that in theory(!) makes it possible to prevent accidents from going public. So it can take days before you see your change. All subject to improvement
. And of course, I would love for this all to be more transparent.
Hi
The delay is 12 hours, not 24. But it’s something I’d like to see reduced, or completely removed.
As for the merges, that happens because of the automated testing. We work in multiple repositories and there’s an automated tool that picks up those changes and merges into the repository. There’s no way to avoid them.
And for the repository size, we’re aware. I don’t know how it will change, probably not by much, but we’ll try to do something.
Comments on this entry are closed.