[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