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

[Olivier Goffart]

On Friday 16 December 2011 12:54:40 Shaw Andy wrote:
> On 12/16/11 1:18 PM, "Olivier Goffart" <olivier at woboq.com> wrote:
> >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.
> 
> While I agree that gerrit is the proper system to get a review now.  I
> disagree with the process being that it goes into Qt 5 and then
> backported, the fact it passed in Qt 5 is not a guarantee that the fix is
> going to be the right one in Qt 4.8 anyway as it may need to be redone and
> thus a fresh review etc needs to happen. 

True.  But in most cases only small changes will be require for the backport.
And in any case, that work need to be done anyway, as the commit must 
eventualy end in Qt 5, hence in gerrit.

> So wouldn't it be better to do
> it the other way around which to me makes more logical sense.  Do it in Qt
> 4.8 and then move it to Qt 5.

The change will eventually need to be put in Qt5's gerrit,  so better sooner 
than later.

Morever, currently, you have a good infrastructure to get review in Qt5.  And 
having a patch included in Qt5 is already a great step towards having it 
included in Qt 4.8 since the actual review is already done. 
(The only remaining reviews is the on the conflicts, if any. And "Is this 
change a candidate for a patch release?"  kind of questions)