Qt Maemo Git Process

(master and 4.5 branch)
Line 14: Line 14:
represents the latest core Qt branch for 4.5
represents the latest core Qt branch for 4.5
-
===bug-*===
 
-
Representing potential bugs in Qt
 
-
These branches hold fixes to specific bugs.
 
-
The 4.5 branch will be merged into them to keep them up-to-date. If the bug is fixed upstream the branch will be deleted.
 
-
===hildon-*===
+
== Maemo master branches ==
-
===hw-*===
+
Currently we have 4.5 master branch only.
-
===widgets-*===
+
-
===maemo-*===
+
-
Representing features in various areas and branched from ?master? (I suggest this should be 4.5)
+
-
Each branches adds only one feature-area.
+
-
The ???(4.5) branch will be merged into them to keep them up-to-date. If the feature is adopted upstream the branch will be deleted.
+
-
?How are dependencies handled? eg if a maemo- feature uses a hw-feature?
+
-
===master-maemo-qt-4.5===
+
=== master-maemo-qt-45 ===
This branch is based on 4.5 and has all feature branches selected for maemo merged into it.
This branch is based on 4.5 and has all feature branches selected for maemo merged into it.
Note that this branch is fairly plain Qt and should contains no packaging data and debian/* should not exist.
Note that this branch is fairly plain Qt and should contains no packaging data and debian/* should not exist.
Line 38: Line 28:
The answer is to create a temporary local branch based on the latest 4.5 (see http://wiki.maemo.org/Mer/Build/UsingGitorious#Upstream_Updates) and merge each feature in turn into this branch. Then merge that into master-maemo-qt-4.5 (which should have no conflicts at all and, in the absence of any features/bugs is a simple fast-forward).
The answer is to create a temporary local branch based on the latest 4.5 (see http://wiki.maemo.org/Mer/Build/UsingGitorious#Upstream_Updates) and merge each feature in turn into this branch. Then merge that into master-maemo-qt-4.5 (which should have no conflicts at all and, in the absence of any features/bugs is a simple fast-forward).
-
===maemo-build-generic===
+
== Maemo build branches ==
 +
These branch should be built completely and used for regular release.
 +
 
 +
=== qt-diablo ===
 +
Diablo branch
 +
 
 +
=== qt-fremantle ===
 +
Fremantle branch, but this is not ready yet.
 +
 
 +
=== qt-mer ===
 +
Currently there is no branch.
 +
 
 +
 
 +
== Maemo build script and debian ==
 +
=== maemo-build-generic ===
This branch is based on and tracks ??(I suggest master-maemo-qt-4.5)
This branch is based on and tracks ??(I suggest master-maemo-qt-4.5)
It contains common packaging (ie debian/*) that allows Qt to build on various maemo-ish releases.
It contains common packaging (ie debian/*) that allows Qt to build on various maemo-ish releases.
Line 44: Line 48:
It simply merges master-maemo-qt-4.5
It simply merges master-maemo-qt-4.5
-
 
+
=== maemo-build-diablo ===
-
===maemo-build-diablo/qt-diablo===
+
Branched from maemo-build-generic and modified with packaging/configuration specifically used for diablo
Branched from maemo-build-generic and modified with packaging/configuration specifically used for diablo
Note that maemo-build-diablo is not merged back
Note that maemo-build-diablo is not merged back
-
===maemo-build-fremantle/qt-fremantle===
+
=== maemo-build-fremantle ===
Branched from maemo-build-generic and modified with packaging/configuration specifically used for fremantle
Branched from maemo-build-generic and modified with packaging/configuration specifically used for fremantle
-
===maemo-build-mer/qt-mer===
+
=== maemo-build-mer ===
-
Branched from maemo-build-generic and modified with packaging/configuration specifically used for Mer
+
Branched from maemo-build-generic and modified with packaging/configuration specifically used for Mer  
-
I don't see a need for both qt-diablo and maemo-build-diablo but :)
+
=== maemo-qt-scripts ===
 +
 
 +
== Maemo fixes ==
 +
=== bug-* ===
 +
Representing potential bugs in Qt
 +
These branches hold fixes to specific bugs.
 +
The 4.5 branch will be merged into them to keep them up-to-date. If the bug is fixed upstream the branch will be deleted.
 +
 
 +
=== hildon-* ===
 +
=== hw-* ===
 +
=== widgets-* ===
 +
=== maemo-* ===
 +
Representing features in various areas and branched from ?master? (I suggest this should be 4.5)
 +
Each branches adds only one feature-area.
 +
The ???(4.5) branch will be merged into them to keep them up-to-date. If the feature is adopted upstream the branch will be deleted.
 +
?How are dependencies handled? eg if a maemo- feature uses a hw-feature?

Revision as of 22:40, 28 June 2009

The Maemo version of Qt lives here:

 http://gitorious.org/+qt-maemo-developers/qt/qt-maemo


If you have a local clone you can use gitk --all to see a visual representation of the branches, commits and merges.

lbt proposed this explanation of the branches/workflow based on the Mer gitorious workflow

Contents

origin

The branches are synced with upstream Qt changes. No Maemo changes are there at all.

master

represents the latest core Qt master branch (currently 4.6)

4.5

represents the latest core Qt branch for 4.5


Maemo master branches

Currently we have 4.5 master branch only.

master-maemo-qt-45

This branch is based on 4.5 and has all feature branches selected for maemo merged into it. Note that this branch is fairly plain Qt and should contains no packaging data and debian/* should not exist.

If an updates is made to 4.5 and 4.5 is merged into master-maemo-qt-4.5 then *all* conflicts with all feature/bug branches will be seen at once. To avoid this, 4.5 is merged into each bug/feature branch and conflicts resolved in focused feature areas. Now we need to merge the conflict-resolved features into master-maemo-qt-4.5. At this point it may seem reasonable to simply re-merge each feature branch into master-maemo-qt-4.5 however master-maemo-qt-4.5 contains all the other features from the last merge. So as soon as the first conflict-resolved feature is merged, all the conflicts from all the other features will be hit. The answer is to create a temporary local branch based on the latest 4.5 (see http://wiki.maemo.org/Mer/Build/UsingGitorious#Upstream_Updates) and merge each feature in turn into this branch. Then merge that into master-maemo-qt-4.5 (which should have no conflicts at all and, in the absence of any features/bugs is a simple fast-forward).

Maemo build branches

These branch should be built completely and used for regular release.

qt-diablo

Diablo branch

qt-fremantle

Fremantle branch, but this is not ready yet.

qt-mer

Currently there is no branch.


Maemo build script and debian

maemo-build-generic

This branch is based on and tracks ??(I suggest master-maemo-qt-4.5) It contains common packaging (ie debian/*) that allows Qt to build on various maemo-ish releases. A good rule is that no code is touched by non-merge commits to this branch It simply merges master-maemo-qt-4.5

maemo-build-diablo

Branched from maemo-build-generic and modified with packaging/configuration specifically used for diablo Note that maemo-build-diablo is not merged back

maemo-build-fremantle

Branched from maemo-build-generic and modified with packaging/configuration specifically used for fremantle

maemo-build-mer

Branched from maemo-build-generic and modified with packaging/configuration specifically used for Mer

maemo-qt-scripts

Maemo fixes

bug-*

Representing potential bugs in Qt These branches hold fixes to specific bugs. The 4.5 branch will be merged into them to keep them up-to-date. If the bug is fixed upstream the branch will be deleted.

hildon-*

hw-*

widgets-*

maemo-*

Representing features in various areas and branched from ?master? (I suggest this should be 4.5) Each branches adds only one feature-area. The ???(4.5) branch will be merged into them to keep them up-to-date. If the feature is adopted upstream the branch will be deleted. ?How are dependencies handled? eg if a maemo- feature uses a hw-feature?