[Development] Gardening (merging of branches)

Frederik Gladhorn frederik.gladhorn at digia.com
Wed Feb 6 16:17:29 CET 2013


Hello again,

if you follow gerrit and the git repos closely you might have noticed that we 
have merged the branches in a more regular fashion lately.

With our current setup we need to continously go this path:
release -> stable -> dev

On a side note: Please only submit your patch for one branch. It will end up 
in the appropriate branches over time. We'd rather not have patches in 
multiple times as that just creates confusion.

Sergio and I with the help of Jedrzej and others have been pushing the merges 
lately. I initially thought this can be automated mostly, but about half the 
time (at least for qtbase) there is a conflict. At that point manual 
intervention is required.

The merging can be tedious (I had one case where I depended on the person 
responsible for half the conflicts to help me figure out how things should 
be), but is generally not rocket science. If possible sitting with two people 
to do it and at the same time review it was the best approach for some 
conflicts, I recommend this to anyone who has the luxury of sitting in the 
same office as another contributor.

Reviewing merges is a bit funny, they show up empty in gerrit:
https://codereview.qt-project.org/#change,46862
That means you need to check them out. Then you can do a combination of git 
show and using gitk or other tools to verify that the merge was done the right 
way.

In order to push merges you need special gerrit karma. Approvers can review 
and approve merges as usual. After talking to several people, for example 
today on IRC Sean Harmer, I think it's a good idea to let more people 
participate in the joy of creating merges.
Initially it takes some time, but once you get the hang of git and merges, it 
becomes quite doable without too much pain (apart from big conflicts every 
once in a while).

I would suggest to look at for example webkit (a suggestion that Simon 
originally made) and how they do "gardening". For a limited time (could be two 
weeks?) two approvers get the honor to look that integration works and that 
there will be regular merges. I think about weekly is not so bad, unless there 
is a special request to do it faster.
This is a nice way to learn about a few more things in how the releases come 
together and you may discover interesting new bits in Qt, code that you've 
never seen before. At least that part is fun ;)

Since it requred merge rights, I would suggest we start with some of the 
maintainers, if we want to try this approach.

Btw: we seem to face a bug in gerrit: it seems like patches that are contained 
in a merge and are at the same time on gerrit in an unreviewed stage get the 
CI to hang. So it's appreciated if patches that are around twice with the same 
change id in different branches get abandonned after one of them has been 
merged.

-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com




More information about the Development mailing list