[Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
sergio.ahumada at nokia.com
Fri Dec 16 11:07:03 CET 2011
On 12/15/2011 10:31 PM, ext Robin Burchell wrote:
> 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.
Mobile Phones Middleware - Quality Engineering
More information about the Development