[Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)

[Olivier Goffart]

On Friday 16 December 2011 12:48:32 Thiago Macieira wrote:
> On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote:
> > One idea is to have an automated process that propose the changes to
> > be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes
> > of what has been done to update the Qt5 sha1, e.g.
> > http://codereview.qt-project.org/11239), but at this stage is just an
> > idea.
> I still prefer merges, the Qt 4 way. This is something we'll need to figure
> out by the time we branch 5.0 from 5.1.

The Qt 5.0 to Qt 5.1 merging system will need adaptation compared to the way 
it worked in Qt 4 in order to work with gerrit. (the merge need to go through 
the CI, and sometimes, commit in Qt 5.0 would break tests in Qt 5.1 meaning 
they need followup commit.)  In Qt 4 it worked because the CI system was 
merging branches, and there was the qt-4.8-from-4.7 branch that as merged by 
CI.  But gerrit do not play well with branches (yet?).


But the more imediate problem is the problem to ensure that bugfixes in 4.8 
also get submited in Qt 5.
There, merging is not possible as the repository are different, one must 
cherry pick.
There are cases were a commit make no sens in Qt5 (symbian code for example)
But in most case, changes should go in Qt5
The commit should first be submitted to gerrit and get proper review there. 
Then, once they passed the CI system in Qt5, they can be cherry-picked in Qt 
4.8.  
The rationale was that gerrit is the appropriate tool for the review, so the 
commit can grow there. Then, once ready, be integrated.