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

[Sergio Ahumada]

Hi,

On 12/15/2011 10:31 PM, ext Robin Burchell wrote:
> Hi,
>
> On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell<robin+qt at viroteck.net>  wrote:
>>> Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8?
>>
>> I'd agree that would make sense to be a policy. But for it to be a
>> policy, it needs to be documented and communicated somewhere. You
>> can't expect this information to just filter out by itself, or expect
>> that it's common sense for everyone.
>>
>> I don't see this listed on http://wiki.qt-project.org/Commit_Policy.
>> Should it be?
>
> Actually, when I read this a second time looking for something
> relevant, I see the complete opposite:
>
> "11. Make sure you submit against the lowest applicable branch from
> which a release is still planned. Cherry-picks ("backports") are
> frowned upon, while forward-merging to more recent branches happens on
> a regular basis."

I think that was true for Qt 4.6 -> Qt 4.7 -> Qt 4.8

There was an automated process that used to merge changes from 4.6 into 
4.7 and from 4.7 into 4.8. After the modularization, there is no 
automated process from Qt 4.8 to Qt 5.

Actually, if we move Qt 4.x to Gerrit, the automatic integration between 
Qt 4.(x-1) and Qt 4.x should be handled differently.

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.

Cheers,
-- 
Sergio Ahumada
Mobile Phones Middleware - Quality Engineering
http://wikis.in.nokia.com/QtQualityEngineering