Hi, On 12/15/2011 10:31 PM, ext Robin Burchell wrote: > Hi, > > On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell<[email protected]> > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
